This article mainly starts from XSS attack in front-end security, and discusses the definition of XSS attack, how to implement XSS attack, and the method of XSS attack defense in detail as much as possible. I hope you found this article useful. In the next article, we will discuss front-end XSRF attacks.

What is an XSS attack?

Cross-site scripting (XSS) is a type of security vulnerability typically found in web applications. XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users.

– Wikipedia

XSS is short for Cross-Site Scripting and uses X to distinguish it from CSS (Cascading style sheets). Commonly known as cross-site scripting attacks, these attacks are carried out by injecting executable scripts into the client.

If you don’t have an intuitive understanding of XSS, I recommend you to try out this XSS game website on Google. There are 6 interesting games on how to implement XSS attack, and you need to try them yourself. You can also find the corresponding reference answers online.

Once a script is injected into a site, hackers can do a lot of “bad” things with scripts, such as stealing cookies, listening to user behavior, modifying the DOM, and generating floating window ads on the page. All these will make the user’s information and behavior become insecure.

Injection mode of XSS attack:

  1. Hijack HTML file, pass<script>Tag for injection (see XSS game-Level2);
  2. In executable JS, execute malicious scripts by concatenating data (see XSS game-Level3);
  3. Add executable code to executable elements of the page, for examplejavascript:xxx(see XSS Game -Level5);
  4. Inject uncontrolled code in events such as onload, onError, and onclick.

The classification of XSS

The common types of XSS attacks are storage XSS, reflection XSS and DOM XSS. Only DOM XSS is related to the front end, and other defenses are mainly in the back end.

Type stored XSS

Here is a small example, if you are watching a live stream, the live stream can send a bullet screen, if someone sends a code, the code is to get the DOM node of the current live stream, and then hide the element. When the barrage is sent from the hacker to the server, and from the server to each user’s page, the live broadcast is “finished” on this page without security processing.

👆 This is a real case, the piece of code sent in this case is a stored XSS attack, the malicious script is stored in the back-end database, and then transmitted back to each user’s page, thus the attack occurred.

Defense against stored XSS attacks

The simplest and most straightforward defense is to escape UGC (user-generated content) for special characters such as “& < > “‘ /”, but depending on the scenario, this is not perfect. You can go further with HTML content (tags, text, content…). , CSS inline style, inline JS and JSON, including jump links to do one by one processing.

This section on preventing XSS attacks by escaping text can be found in Web Security Series 4: Defending AGAINST XSS. (As you’ll see, it’s not just technical, it’s also physical.)

Reflective XSS

This time the main character is the malicious script, but this time the malicious script is not stored in the database, but in the URL. I highly recommend taking Google XSS Game-Solving Level 5 to the next Level.

The difference between a reflective XSS attack and a stored XSS attack is the location where the malicious code is stored.

The DOM model XSS

DOM TYPE XSS attack has little relationship with the server. It does not need to interact with the server, but directly realizes the injection of malicious code through HTTP hijacking and modification of corresponding HTML files.

Defense against DOM type XSS attacks

To prevent malicious code from executing on a web page, remember that untrusted data cannot be executed as code.

It is recommended to use the DOM API. TextContent /. The setAttribute () to replace the innerHTML /. OuterHTML/document. The write (). V-html is not recommended for Vue projects.

How do I prevent XSS attacks

There are three main ways to prevent XSS attacks: escape, CSP, and HttpOnly

escape

This is a key defense against both stored XSS and reflective XSS attacks by escaping different types of text and data and preventing most XSS attacks well.

CSP

CSP is a Content Security Policy. In practice, we implement this by adding a content-Security-Policy field to the HTTP header.

Common CSP header fields are as follows:

Content-Security-Policy: default-src 'self' *.trusted.com
Copy the code

Currently available browsers support CSP fairly well:

Under strict CSP conditions, the defense against XSS attacks has the following functions:

  • Prohibit loading outfield code to prevent complex attack logic;
  • Prohibit outfield submission, user data will not be leaked after the website is attacked;
  • Disable inline script execution;
  • Prohibit unauthorized script execution.
  • You can use the CSP reporting function to troubleshoot problems.

The CSP feature also prevents data injection type attacks

HttpOnly

HttpOnly is a Cookie attribute. You can set this attribute when setting cookies. This attribute prevents cookies from being obtained by JS scripts and can only be transmitted and accessed through Http.

We need to be clear that HttpOnly does not prevent XSS attacks in nature, mainly to alleviate the role of malicious script execution, is unable to obtain the corresponding Cookie, to prevent the next attack and further leakage of user data.

type Storage area The insertion point
Type stored XSS Back-end database HTML
Reflective XSS URL HTML
The DOM model XSS Back-end database/front-end storage /URL The front-end Javascript

The above is the knowledge of XSS attack to share, I hope to help you.

References:

  • Front-end Security Series 1: How do I Prevent XSS attacks?
  • XSS game
  • Web Security series (4) : XSS defense
  • Cross-site Scripting attacks (XSS) : Why do cookies have HttpOnly attributes?
  • Content Security Policy (CSP)[MDN]
  • caniuse.com/?search=csp