First, XSS cross-site scripting attacks

XSS: Cross Site Scripting (XSS) is for cross-site Scripting.

An XSS attack is when a malicious script is executed in the browser (whether across domains or in the same domain) to obtain the user’s information for operation.

These operations generally do the following things

  1. Stealing cookies
  2. Listen to user behavior, such as input account password and directly send to the hacker server
  3. Modify the DOM forgery login form
  4. Generate float window ads in the page

Typically,XSS attacks can be implemented in one of three ways: storage, reflection, and documentation. The principle is simple.

Storage type

Stored SCRIPTS are stored in a database on the server side, and then executed on the client side to achieve the effect of the attack.

The common scene is the comment area to submit a piece of code, if the front and back end did not do a good job of escaping the work, the comment content saved to the database, in the page rendering process directly executed, equivalent to the execution of a position logic JS code, is very horrible.

reflective

Malicious scripts as part of a network request. So let’s say I type in a browser

http:< span style = "box-sizing: border-box; color: RGB (74, 74, 74); font-size: 14px! Important; word-break: break-word! Important;
Copy the code

The browser parses the content as part of the HTML, finds out it’s a script, executes it, and gets attacked.

It is called reflective because the malicious script is parsed by passing through the server as a parameter to the network request and then reflected into the HTML document. Unlike storage: the server does not store these malicious scripts.

The document type

The document TYPE XsS attack does not pass through the server, but acts as a middleman, hijacking the network packet during the data transmission and modifying the HTML document inside.

Such hijackings can include wifi route hijacking, or local malware.

Precautions for XSS

Understand the principles of the three XSS attacks, and find a common point: all malicious scripts can be executed directly in the browser, so to prevent it, is to avoid the execution of the script code.

In order to accomplish this, it is necessary to do one faith and two exploits. A belief: Don’t trust any user input!

Transcoding or filtering of user input should be carried out on both the front-end and the server

< script> </ script>Copy the code

After transcoding, it becomes

&]t; script> alert('You're screwed.')</ script>
Copy the code

Such code cannot be executed during HTML parsing. Of course, you can also use keyword filtering to delete script tags.

Using the CSP

CSP is the content security policy in the browser. The core idea of CSP is that the server decides which resources to load in the browser. Specifically, CSP can accomplish the following functions:

  1. Limit resource loading in other domains
  2. Prohibit submitting data to other fields
  3. Provide a reporting mechanism to help us detect XSS attacks in a timely manner

Using the Httponly

Many XSS attack scripts are used to steal cookies, and set the Cookie Httponly attribute, JavaScript can not read the value of the Cookie, this is also a good defense against XSS attacks.

Conclusion:

An XSS attack is when a malicious script is executed in a browser and the user’s information is taken and acted upon. Mainly divided into storage type, reflection type and document type. Prevention measures include: a belief: don’t trust user input, transcode or filter input to make it unenforceable. Two uses: using CSP, using the Cookie Httponly attribute.