Note: This article was shared by meituan’s technical teamFront-end Security Series 1: How do I Prevent XSS attacks?Summary, more details please click on the website.

What is XSS

Cross-site Scripting (XSS) is a code injection attack. The attacker injects malicious scripts on the target website to run on the user’s browser. Using these malicious scripts, attackers can obtain sensitive user information such as cookies and sessionIDS, thus compromising data security.

The essence of XSS is that malicious code is unfiltered and mixed in with the site’s normal code; Browsers cannot tell which scripts are trusted, causing malicious scripts to be executed.

Because it is executed directly on the user’s terminal, malicious code can directly obtain the user’s information, or use this information to impersonate the user to launch the request defined by the attacker to the website.

Second, XSS injection method

  • In text embedded in HTML, malicious content is injected as script tags.
  • In inline JavaScript, concatenated data breaks through the original constraints (strings, variables, method names, etc.).
  • In tag attributes, malicious content includes quotes to override attribute values and inject other attributes or tags.
  • In the href, SRC and other attributes of the tag, it contains javascript: and other executable codes.
  • Inject uncontrolled code in events such as onload, onError, and onClick.
  • In the style attribute and tag, include something like background-image:url(“javascript:…”) ); (newer versions of browsers are already defensible).
  • In the style attribute and tag, contain something like expression(…) CSS expression code (newer versions of browsers are already defensible).

In short, if a developer inserts text into HTML without filtering it properly, it can easily create an injection vulnerability. Attackers can use vulnerabilities to construct malicious code instructions, and then use malicious code to harm data security.

Iii. XSS classification

According to the attack sources, XSS attacks can be classified into storage, reflection and DOM attacks.

Storage areas type | | | | the insertion point

  • | type stored XSS | | | HTML backend database
  • Reflective XSS | | | | HTML URL
  • Type | DOM XSS | back-end database front-end storage/URL | front-end JavaScript |

Store: The location where malicious code is stored.

Insertion point: Who gets the malicious code and inserts it into the web page.

3.1 Storage XSS

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 the malicious code out of the database, splices it into HTML and returns it to the browser.
  3. When the user’s browser receives the response, it parses it and executes the malicious code mixed in.
  4. Malicious code steals user data and sends it to the attacker’s website, or impersonates the user’s behavior and calls the target website interface to perform the operations specified by the attacker.

This kind of attack is common in website functions with user-saved data, such as forum posts, product reviews, and user messages.

3.2 Reflective XSS

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, splices it into HTML and returns it to the browser.
  3. When the user’s browser receives the response, it parses it and executes the malicious code mixed in.
  4. Malicious code steals user data and sends it to the attacker’s website, or impersonates the user’s behavior and calls the target website interface to perform the operations specified by the attacker.

The difference between reflective XSS and stored XSS is that the stored XSS malicious code is stored in the database, while reflective XSS malicious code is stored in the URL.

Reflective XSS vulnerabilities are common in functions that pass parameters through urls, such as website search, jump, etc.

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.

3.3 the DOM XSS

DOM XSS attack steps:

  1. The attacker constructs a special URL that contains malicious code.
  2. The user opens a URL with malicious code.
  3. When the user’s browser receives the response, it parses it and executes it. The front-end JavaScript picks up the malicious code in the URL and executes it.
  4. Malicious code steals user data and sends it to the attacker’s website, or impersonates the user’s behavior and calls the target website interface to perform the operations specified by the attacker.

DOM XSS differs from the previous two types of XSS: DOM XSS attacks, in which malicious code is extracted and executed by the browser side, are security vulnerabilities of the front-end JavaScript itself, while the other two types of XSS are security vulnerabilities of the server side.

Iv. Prevention of XSS attacks

As you can see from the previous introduction, XSS attacks have two main elements:

  1. The attacker submits malicious code.
  2. The browser executes malicious code.

For the first factor: can we filter out the malicious code that users enter during the process? The answer is no. Since input filtering is not entirely reliable, we protect against XSS by preventing browsers from executing malicious code. This section falls into two categories:

  • Prevent injection in HTML.
  • Prevents malicious code from executing while JavaScript is executing.

4.1 Pure front-end rendering

Pure front-end rendering process:

  1. The browser first loads a static HTML that does not contain any business-related data.
  2. The browser then executes the JavaScript in the HTML.
  3. JavaScript loads the business data through Ajax and calls the DOM API to update it to the page.

In a pure front-end rendering, we explicitly tell the browser whether to set a text (.innertext), an attribute (.setAttribute), a style (.style), etc. Browsers can’t easily be tricked into executing unexpected code.

However, pure front-end rendering also needs to avoid DOM-type XSS vulnerabilities (such as onload events and javascript: XXX in href, see section “Preventing DOM-type XSS attacks” below).

In many internal and management systems, pure front-end rendering is perfectly appropriate. However, for pages with high performance requirements or SEO requirements, we still face the problem of concatenated HTML.

4.2 escaped HTML

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 does provide some XSS protection, but it’s not perfect:

| XSS vulnerability if there is a protective action | | simple escape

  • Text content | | | HTML tags
  • | | | HTML attribute value
  • | CSS inline style | |
  • Inline JavaScript | | |
  • Inline JSON | | |
  • No | | | jump link

So to improve XSS safeguards, we need to use more sophisticated escape strategies.

For example, in Java projects, the commonly used escape library is org.owasp. Encoder

4.3 the Content Security Policy

Strict CSP can play the following roles in XSS prevention:

  • Prohibit loading outfield code to prevent complex attack logic.
  • Prohibit submission from the outdomain. After a website is attacked, user data will not be leaked to the outdomain.
  • Forbid inline script execution (strict rules, currently found to be used on GitHub).
  • Disable unauthorized script execution (new feature, in use with Google Map Mobile).
  • Proper use of reports can discover XSS in a timely manner, which helps to rectify problems as soon as possible.

4.4 Input length control

Untrusted input should be limited to a reasonable length. While you can’t completely prevent XSS from happening, you can make XSS attacks more difficult.

– only 4.5 HTTP cookies

Disables JavaScript from reading certain sensitive cookies, which attackers cannot steal after completing XSS injection.

4.6 authentication code

Prevent scripts from posing as users to submit dangerous operations.

V. Detection of XSS

  1. Manually detect XSS vulnerabilities using the generic XSS attack string.
  2. Use scanning tools to automatically detect XSS vulnerabilities.

In addition to manual detection, you can also use automated scanning tools to find XSS vulnerabilities, such as Arachni**, Mozilla HTTP Observatory**, W3AF **, and others.

conclusion

Although it is difficult to completely avoid XSS by technical means, we can summarize the following principles to reduce vulnerability:

  • Leveraging the template engineEnable the HTML escape function of the template engine. For example, in EJS, use as much as possible<%= data %>Rather than<%- data %>; In dot.js, use as much as possible{{! data }Rather than{{= data }; In FreeMarker, make sure the engine version is higher than 2.3.24 and the correct one is selectedfreemarker.core.OutputFormat.
  • Avoid inline eventsTry not to useonLoad="onload('{{data}}')",onClick="go('{{action}}')"This concatenation of inline events. It passes in JavaScript.addEventlistener()Event binding is more secure.
  • Avoid concatenated HTMLIt is dangerous to use spliced HTML in the front end. If the framework allows, use itcreateElement,setAttributeAnd so on. Or use a mature rendering framework such as Vue/React.
  • Keep your guard up when inserting DOM properties, links, etc.
  • Increasing the attack difficulty and reducing the attack consequence You can increase the attack difficulty and reduce the attack consequence by using CSP, input length configuration, and interface security measures.
  • Proactive detection and discovery can be used to find potential XSS vulnerabilities using XSS attack strings and automated scanning tools.