Editor said: as an engineer of JS department, I think XSS vulnerability is the most exposed vulnerability, but not all students have a clear understanding of it. Today, we have invited @Lu Shijie to share with us the XSS vulnerability attack in his eyes, hoping to help you.

What is an XSS attack

XSS (Cross-site Scripting) is also called cross-site Scripting. XSS focuses not on cross-site Scripting, but on script execution. XSS is a computer security vulnerability that often occurs in Web applications, resulting from Web applications that do not filter user input adequately.

There are three common XSS attacks: reflection, DOM-based, and storage. Reflective and DOM-based attacks can be classified as non-persistent XSS attacks, and storage attacks as persistent XSS attacks.

1. The reflective

Reflective XSS typically involves an attacker using a specific technique (such as an email) to trick the user into visiting a URL containing malicious code. When the victim clicks on these specially designed links, the malicious code is executed directly in the browser on the victim’s host.

This is a one-off for the visitor, when we pass our malicious script to the server via the URL, and the server simply “reflects” the script back to the visitor’s browser and causes the visitor’s browser to execute the corresponding script. The triggering of reflective XSS involves the involvement of the back end. In order to avoid reflective XSS, the coordination of the back end must be required. When the back end parses the data of the front end, it first performs relevant string detection and escape processing.

This type of XSS usually appears in the search bar of a website, the user login interface and other places, and is often used to steal client Cookies or phishing.

The entire attack process is roughly as follows:

2. The DOM – -based

Client-side scripts can examine and modify page content on the fly, independent of server-side data. For example, if the client extracts data from the URL and executes it locally, the application may be vulnerable to DOM-based XSS attacks if the data entered by the user on the client contains malicious JavaScript scripts that are not properly filtered and sanitized. Special attention should be paid to the following user input sources document.URL, location.hash, location.search, document.referrer, etc.

The entire attack process is roughly as follows:

3. The storage type

The attacker uploads or stores malicious code to the vulnerability server in advance and executes the malicious code whenever the victim browses the page containing the malicious code. This means that anyone who visits the page is likely to execute the malicious script, making stored XSS even more harmful.

Stored XSS usually appears in the interaction places such as website messages, comments, and blog logs. Malicious scripts are stored in the database of the client or server.

The entire attack process is roughly as follows:

Hazards of XSS attacks

XSS can result in:

  1. Attack hijacking access;
  2. Embezzle cookies to achieve password-free login;
  3. Cooperate with CSRF attack to complete malicious request;
  4. Using JS or CSS to destroy the normal structure and style of the page;

defense

1. HTML coding of XSS defense

Application: HTML encoding when placing untrusted data in HTML tags (such as div, SPAN, etc.).

Encoding rule: Escape & < > “‘/to entity characters (or decimal, hexadecimal).

Sample code:

  function encodeForHTML(str, kwargs){
    return (' ' + str)
      .replace(/&/g.'& ')
      .replace(/</g.'< ')     // DEC=> &#60; HEX=> &#x3c; Entity=> &lt;
      .replace(/>/g.'> ')
      .replace(/"/g.'" ')
      .replace(/'/g.'' ')   // ' Not recommended, as it is not in the HTML specification
      .replace(/\//g.'/ ');
  };
Copy the code

HTML has three encoding representations: decimal, hexadecimal, and named entities. Such as the less than sign (<) can be encoded as a decimal > “<” and “hex = > <“, “named entity = > <” three ways. For single quotes (‘), hexadecimal is used because entity character encoding is not in the HTML specification.

2. HTML Attribute coding for XSS defense

Application scope: HTML Attribute encoding is performed when untrusted data is put into HTML attributes (excluding SRC, href, style, and event handling attributes)

Encoding rules: Except alphanumeric characters, use &#xHH; (or any named entity available) format to escape all characters with an ASCII value less than 256

Sample code:

  function encodeForHTMLAttibute(str, kwargs){
    let encoded = ' ';
    for(let i = 0; i < str.length; i++) {
      let ch = hex = str[i];
      if (!/[A-Za-z0-9]/.test(str[i]) && str.charCodeAt(i) < 256) {
        hex = '&#x' + ch.charCodeAt(0).toString(16) + '; ';
      }
      encoded += hex;
    }
    return encoded;
  };
Copy the code

3. JavaScript coding for XSS defense

Scope: JavaScript encoding when untrusted data is put into event handling properties, JavaScirpt values

Encoding rules: Except alphanumeric characters, escape all ASCII characters less than 256 using \xHH format

Sample code:

  function encodeForJavascript(str, kwargs) {
    let encoded = ' ';
    for(let i = 0; i < str.length; i++) {
      let cc = hex = str[i];
      if (!/[A-Za-z0-9]/.test(str[i]) && str.charCodeAt(i) < 256) {
        hex = '\\x' + cc.charCodeAt().toString(16);
      }
      encoded += hex;
    }
    return encoded;
  };
Copy the code

4. URL encoding of XSS defense

Scope: URL encoding is required when untrusted data is used as URL parameter values

Encoding rule: encodeURIComponent encoding for parameter values

Sample code:

  function encodeForURL(str, kwargs){
    return encodeURIComponent(str);
  };
Copy the code

5. CSS encoding of XSS defense

Scope: CSS encoding for untrusted data as CSS

Encoding rules: Use the \XXXXXX format to escape all characters with an ASCII value less than 256, except alphanumeric characters

Sample code:

  function encodeForCSS (attr, str, kwargs){
    let encoded = ' ';
    for (let i = 0; i < str.length; i++) {
      let ch = str.charAt(i);
      if(! ch.match(/[a-zA-Z0-9]/) {
        let hex = str.charCodeAt(i).toString(16);
        let pad = '000000'.substr((hex.length));
        encoded += '\ \' + pad + hex;
      } else{ encoded += ch; }}return encoded;
  };
Copy the code

Afterword.

User input is not trusted at any time. HTTP parameters should theoretically be validated. For example, if a field is an enumeration type, it should not have an enumeration value. The output of untrusted data should be coded accordingly. In addition, httpOnly, CSP, X-XSS-protection, Secure Cookie, and so on can also play an effective defense.

XSS vulnerabilities are sometimes difficult to find. Fortunately, React, Vue and other frameworks introduce XSS defense mechanisms from the framework level, freeing our hands to some extent. But as a developer you still need to understand the basics of XSS and avoid creating XSS vulnerabilities in detail. Framework is auxiliary, we still need to people-oriented, standardize development habits, improve the awareness of Web front-end security.

Reference documentation

  • www.qa-knowhow.com/?p=1467
  • brajeshwar.github.io/entities/
  • excess-xss.com/
  • Github.com/chrisisbeef…