An overview of the

Cross-site scripting (XSS) attacks are an injection in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a Web application to send malicious code, usually in the form of browser-side scripts, to different end users. The pitfalls that allow these attacks to succeed are common and occur anywhere a Web application uses input from the user in the output it generates without validating or encoding it.

Attackers can use XSS to send malicious scripts to unsuspecting users. The end user’s browser has no way of knowing that the script should not be trusted and will execute it. Because it assumes that the script is coming from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information that the browser retains and uses with the site. These scripts can even rewrite the content of HTML pages.

Sites that use SSL (HTTPS) are no more protected than unencrypted sites. The Web application works the same way as before, except that the attack occurs on an encrypted connection. People often think that because they see a lock on their browser that means everything is secure. That’s not the case.

A classic scene

Cross-site scripting (also known as XSS) occurs when a Web application collects malicious data from a user. Data is often collected in the form of hyperlinks that contain malicious content. The user will most likely click on this link from another website, an instant message, or just reading a web board or E-mail message. Typically, an attacker encodes the malicious part of the link to the site in HEX (or some other encoding method) so that when the user clicks on the request, the request is less suspicious. After the Web application collects the data, it creates an output page for the user that contains the malicious data originally sent to it, but somehow makes it appear as valid content from the site. Many popular guest books and forum programs allow users to submit posts with embedded HTML and javascript. For example, if I log in as “John” and read a message sent by “Joe” that contains malicious javascript, “Joe” might hijack my session by reading his bulletin board posts.

Attack types

Stored XSS attack

Storage attacks are attacks that permanently store injected scripts on the target server, such as databases, message forums, visitor logs, comment fields, and so on. The victim then retrieves the malicious script information from the server when requesting storage. Storage XSS is sometimes called Persistent or Type-I XSS.

 // A comment page where you can view user comments.
 // The attacker submitted the malicious code as comments, and the server did not escape the data
 // Comment input:
 <textarea>
    <img src="empty.png" onerror ="alert('xss')">
 </textarea>
 // Then the script provided by the attacker will be executed in the browsers of all users accessing the comment page
Copy the code

Reflex XSS attack

A reflex attack is an attack that an injected script reflects off a Web server, for example in an error message, search result, or any other response that includes some or all of the input sent to the server as part of a request. Reflex attacks reach victims in other ways, such as in E-mail messages or on other web sites. When a user is tricked into clicking on a malicious link, submitting a special form, or even just browsing to a malicious site, the injected code spreads to a vulnerable site and reflects the attack back to the user’s browser. The browser then executes the code because it comes from a “trusted” server. Reflective XSS is sometimes referred to as non-persistent or type II XSS.

 // a website has a search function, which receives the search terms provided by the user through the URL parameter:
 https://xxx.com/search?query=123
 // The server responds to this URL with the search term supplied:
 <p>You are searching for: 123</p>
 // If the server does not escape data, the attacker can construct the following link to attack:
 https://xxx.com/search?query=<img src="empty.png" onerror ="alert('xss')">
 // This URL will result in the following response, with alert(' XSS ') run:
 <p>You are searching for:<img src="empty.png" onerror ="alert('xss')"></p>// If a user requests the attacker's URL, the script provided by the attacker will be executed in the user's browser.Copy the code

The DOM model XSS

  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.

Preventing DOM attacks ⛳

DOM TYPE XSS attack is actually the site’s front-end JavaScript code itself is not strict enough, the untrusted data as code execution.

Be careful when using.innerhtml,.outerhtml, and document.write(). Do not insert untrusted data into the page as HTML. Instead, use.textContent,.setAttribute(), etc.

If using the Vue/React technology stack, and do not use the v – HTML/dangerouslySetInnerHTML function, on the front end render phase avoid innerHTML, outerHTML XSS concerns.

Inline event listeners in the DOM, such as location, onClick, onError, onload, onmouseover, etc. JavaScript eval(), setTimeout(), setInterval(), etc., can all 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.

REFERENCE

  1. Vue Safety Guide
  2. Html5 security cheat sheet
  3. Cross Site Scripting (XSS)
  4. The Cross-Site Scripting (XSS) FAQ
  5. XSS attacks in React
  6. Meituan – Front-end Security Series 1: How to Prevent XSS attacks?
  7. An XSS game is at 🎮