XSS(Cross Site SCripting)

  • Cross-site scripting attacks are code injection attacks. Attackers inject malicious scripts on target websites and make them run in users’ browsers to steal users’ sensitive information or use these information to attack websites as users
  • According to the attack source, XSS attacks can be classified into three types: reflection, storage, and DOM.

reflective

  • The malicious script itself is sent as a request parameter to a site page where there is a vulnerability (usually a search box), and then the script reflects (appears) on a newly rendered (or partially refreshed) page and executes.
  • Vulnerabilities are common in functions that pass parameters through urls, such as search. Attacker to construct a url with malicious code, when the user opens with the url of the malicious code, site server will be taken out from malicious code in the url and splicing in the HTML returned to the browser, the user’s browser parsed malicious code will be executed, the malicious code to steal user data and sent to the attacker’s web site, or pretend to be the user’s behavior, Invoke the target web site interface to perform the operation.
  • Because users need to take the initiative to open malicious URL to take effect, attackers often combine a variety of means to induce users to click.
  • Reflective XSS can also be triggered by the contents of a POST, but the trigger condition is more stringent (the form submission page needs to be constructed and the user is directed to click), so it is very rare.

Attack steps of reflective XSS:

  • 1. The attacker constructs a special URL that contains malicious code
  • 2. When a user opens a URL with malicious code, the web server takes the malicious code out of the URL and splices it into HTML to return it to the browser
  • 3. The user’s browser parses and executes the response, and the malicious code mixed in the response is also executed.
  • 4. Malicious code steals user data and sends it to the attacker’s website, or impersonates the user and calls the target website interface to perform the operations specified by the attacker.

Storage type

  • Stored (or HTML-injected/persistent) XSS attacks do not require the user to click on a special link, the attacker only needs to submit the attack code to other places on a website that other users are likely to visit, such as user comments, message boards, etc. The attack code is automatically executed when the user visits.
  • The difference between stored vulnerability and reflective vulnerability is that stored XSS malicious code exists in the database, while reflective XSS malicious code exists in the URL.

Storage XSS attack steps

  • 1. The attacker submits malicious code to the database of the target website
  • 2. When the user opens the target website, the website server takes out the malicious code from the database, splices it into HTML and returns it to the browser
  • 3. The user’s browser parses and executes the response, and the malicious code mixed in the response is also executed.
  • 4. Malicious code steals user data and sends it to the attacker’s website, or impersonates the user and calls the target website interface to perform the operations specified by the attacker

This attack is common on sites with user-saved data, such as forum posts, product reviews, and private messages.

The DOM model

  • Dom-type XSS attacks are essentially the result of sloppy front-end javaScript code that inserts untrusted content into the page. Be careful when using apis like.innerhtml,.outerhtml, appendChild, document.write() to insert untrusted data into the page as HTML. Use.innertext instead. .textContent, setAttribute(), etc.

DOM XSS attack steps:

  • 1. The attacker constructs special data, which contains malicious code
  • 2. The user browser executes malicious codes
  • 3. Malicious code steals user data and sends it to the attacker’s website, or impersonates the user and calls the interface of the target website to perform the operations specified by the attacker.

Universal XSS

  • Universal XSS, also called UXSS or Universal XSS, stands for Universal Cross-Site Scripting.
  • The above three TYPES of XSS attack target websites or applications that have vulnerabilities due to lax code development on the client or server side. These attacks require a vulnerability to access the page, but UXSS is a type of attack that exploits a browser or browser extension vulnerability to create conditions that generate XSS and execute code.

Holes cause

  • Web browsers are one of the most popular applications in use, and when a new vulnerability is discovered, there is a considerable amount of time for it to be exploited or reported to the authorities, and this process can be exploited in UXSS.
  • It is not only the vulnerability of the browser itself. Nowadays, all major browsers support the installation of extensions, and many browser extensions may lead to more vulnerabilities and security problems. Because UXSS attacks do not require the site page itself to be vulnerable and may access other secure, bug-free pages, UXSS is one of the most dangerous and damaging types of attacks in XSS.

Mutant XSS

  • XSS, also known as mXSS or Mutation-based cross-site-scripting. (mutation, a word from genetics known as gene mutation)

Holes cause

  • However, if the user-supplied rich text enters the innerHTML attribute through javascript code, something unexpected happens that makes this assumption invalid: the browser’s rendering engine renders harmless HTML code into potentially dangerous XSS attack code.

This attack code may then be output into the DOM by some other process in the JS code or rendered again in some other way, resulting in the execution of XSS. This is the XSS attack flow that results from unexpected changes in HTML content as it enters innerHTML. Attack process

  • Putting the concatenated content into innerHTML is a common practice in WEB application code. Many common WEB applications use the innerHTML attribute, which can lead to a potential mXSS attack. From a browser perspective, mXSS has an impact on all three major browsers (IE, CHROME and FIREFOX).

XSS defense method

  • Be careful when using.innerhtml,.outerhtml, and document.write(). Do not insert untrusted data into the page as HTML. Instead, use.textContent,.setAttribute(), etc. Inline event listeners in the DOM, such as location, onclick, onError, onload, onmouseover, etc., the href attribute of tags, JavaScript eval(), setTimeout(), setInterval(), etc. Can run strings as code. If untrusted data is concatenated into strings and passed to these apis, it is easy to create a security risk that must be avoided.
  • Input check. Check, escape, and filter user input. Create a trusted whitelist of characters and HTML tags. Filter or encode characters or tags that are not in the whitelist bar
  • Input length control. Untrusted input should be limited to a reasonable length, which can increase the difficulty of attacks, though not completely prevent them
  • If HttpOnly is set, the browser will prevent the page’s JavaScript from accessing cookies with the HttpOnly attribute to prevent malicious scripts from accessing the user’s private data through document.cookie
  • Major browsers now have built-in safeguards against XSS, such as content security policies CSP(developer.mozilla.org/zh-CN/docs/…)
  • If concatenating HTML is necessary, you need to use a suitable escape library to adequately escape the insertion points of the HTML template. Common template engines such as dot.js, EJs, FreeMarker, etc., usually have only one rule for HTML escaping, which is to escape & < > “‘ /. This provides some XSS protection, but it’s not perfect: A plug-in for front-end protection against XSS attacks is recommended: JS-XSS (juejin.cn/post/691334…)

CSRF

  • Cross-site request-forgery (CSRF) : An attacker induces the victim to access a third-party website and then sends cross-domain requests to the attacked website. Using the victim in the attacked website has obtained the registration certificate, bypassing the background user authentication, to impersonate the user to perform a certain operation on the attacked website.

Typical CSRF attack flow

  • 1. The victim logs in to site A and retains the login credentials (cookies).
  • 2. The attacker induces the victim to visit site B
  • 3. Site B sends A request to site A. By default, the browser carries site A’s Cookie.
  • 4. After receiving the request, site A verifies the request and confirms that it is the victim’s credential. Site A mistakenly believes that the request is sent by an innocent victim.
  • 5. Site A executes site B’s request on behalf of the victim

The attack is complete. The attacker impersonates the victim to complete the attack without the victim’s knowledge

defense

  • 1. Add a verification code (Poor experience)

The verification code can defend against CSRF attacks, but it is impossible for us to need the verification code for every interaction, otherwise the user experience will be very bad. However, we can add the verification code in the operation of transfer and transaction to ensure the security of our account.

  • 2. Determine the source of the request: check the Referer and Origin(not safe,Referer can be changed)

Referer can be used as an auxiliary means to determine whether the source of the request is secure, but since Referer itself is modifiable, it cannot be relied on alone. In HTTP, each asynchronous request carries two headers, which mark the domain name of the source:

Origin Header
Referer Header
Copy the code

These two headers are carried automatically in most cases when the browser makes a request, and the content cannot be customized by the front end. The server can determine the source domain of the request by resolving the domain names in the two headers. But both of these things don’t exist.

Origin does not exist in two cases: Internet Explorer 11 Same-origin policy: Internet Explorer 11 will not add an Origin header on cross-site CORS requests, and the Referer header will remain a unique identifier. The root cause is that the Same origin is defined differently in IE 11 than in other browsers. There are two main differences, see MDN same-origin_policy #IE_Exceptions 302 redirect: Origin is not included in a redirected request after a 302 redirection because Origin may be considered sensitive information from another source. In the case of 302 redirects, the URL is directed to the new server, so the browser does not want to leak Origin to the new server.Copy the code

Attackers can hide Referer in their requests. If the attacker filled out his request like this:

<img src="http://bank.example/withdraw? amount=10000&for=hacker" referrerpolicy="no-referrer">Copy the code

Copy the code and the attack initiated by this request will not carry the Referer. In addition, Referer is not or cannot be trusted in the following cases:

1. In IE6 and IE7, when window.location.href= URL is used to jump to the interface, the Referer will be lost. 2. When Windows. Open is used in IE6 and IE7, Referer will also be missing. 3. When the HTTPS page is switched to the HTTP page, the Referer of all browsers is lost. 4. When clicking Flash to reach another website, the Referer's situation is messy and not credible.Copy the code
  • 3. Use tokens (mainstream)

The CSRF attack succeeds because the server mistook the request sent by the attacker for the user’s own request. Then we can require all user requests to carry a Token that a CSRF attacker cannot obtain. The server verifies that the request carries the correct Token to distinguish the normal request from the attack request. It’s like a captcha, but the user doesn’t know it

Steps:

- The server generates a token for the user, encrypts it, and sends it to the user. - The user must carry the token when submitting a request. - The server verifies the tokenCopy the code
  • 4. Samesite Cookie properties

To address this problem at its source, Google drafted a draft to improve the HTTP protocol by adding a Samesite attribute to the set-cookie response header, which indicates that the Cookie is a “same-site Cookie.” A same-site Cookie can only be used as a first-party Cookie, not a third-party Cookie. Samesite has two property values: Strict and Lax. It is simple to deploy and can effectively defend against CSRF attacks, but compatibility problems exist

Samesite=Strict

Samesite=Strict is known as Strict mode, indicating that the Cookie cannot be used as a third-party Cookie under any circumstances and is capable of preventing all CSRF attacks. At this point, we launch any request to site A under site B, and the Cookie of site A will not be included in the Cookie request header.

Refer to the link

  • Juejin. Cn/post / 684490…
  • Juejin. Cn/post / 684490…
  • Juejin. Cn/post / 684490…