XSS is introduced

XSS is short for Cross Site Scripting, but the way the initials are named, it should be called CSS, but it’s a Cascading Style Sheets (CSS), so it’s CALLED XSS.

XSS attacks generally refer to an attack mode in which the attacker injects malicious scripts into web pages and executes the malicious scripts when users browse web pages to control the behaviors of users’ browsers.

XSS hazards

  • Steal user cookies, obtain user privacy, and steal user accounts.
  • Hijack the user (browser) session to perform arbitrary actions, such as making illegal money transfers, forcing Posting logs, sending e-mails, and so on.
  • Mandatory pop-up AD pages, brush traffic, etc.
  • Spread cross-site scripting worms, web page hanging horses, etc.
  • Combine with other vulnerabilities, such as CSRF, to implement further attacks.
  • .

XSS classification

XSS attacks can be classified into non-persistent XSS attacks and persistent XSS attacks according to whether the attack data is saved to the server and whether the attack behavior always exists with the attack data.

XSS attacks can be classified into reflected XSS, DOM XSS, and stored XSS. Reflected XSS and DOM XSS are non-persistent XSS attacks, while stored XSS are persistent XSS attacks.

Reflected XSS

After the attacker induces the user to access a URL with malicious code, the server receives and processes the data, and then sends the data with malicious code to the browser. The browser parses the data with XSS code and executes it as a script, finally completing the XSS attack.

Because this process acts like a reflection, it is called reflective XSS.

Attack steps:

1, the attack constructs a special URL, which contains malicious code.

2. The user is induced to open the URL with malicious code, and the server side takes the malicious code out of the URL as a parameter, and then returns the data with malicious code to the user.

3. The user’s browser receives the response and parses it, and the malicious code mixed in is executed.

4. Malicious code steals user sensitive data and sends it to the attacker, or impersonates the user, and invokes the target website interface to perform operations specified by the attacker.

For example,

Here is a normal search process

1, open the home page, enter the search content

Open the home page and enter the search content

2. Start the search and see the results

Start the search and see the results

But if no results are found, the back end will return what the user entered and display it on the page.

Since there is no processing of user-input data, we construct a link like this:

https://www.kkkk1000.com/xss/Reflected/searchResult.html?kw=<script>alert("xss")</script> )

Then induce others to click on the link) to complete a reflective XSS attack.

And for such a long link, we can also camouflage camouflage, into a short url or QR code.

Short url:

i6q.cn/4TJcII

Qr code:

Maybe you think it’s just a pop-up, but what if we change the attack code to load a third-party JS file? To steal cookies with document.cookie? Anyway, if it’s a real attack, it won’t just be a popover.

DOM XSS (Dom-based XSS)

DOM XSS is formed by modifying the DOM nodes of the page.

In DOM XSS attack, the extraction and execution of malicious code are completed by the browser side, which belongs to the security vulnerability of the front end.

Attack steps:

1, the attacker constructs a special URL, which contains malicious code.

2. The user is induced to open a URL with malicious code.

3. The user browser parses and executes the response after receiving it, and the front-end JavaScript takes out 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 a user and invokes the target website interface to perform the operations specified by the attacker.

For example,

The following is a page of logistics details. There is the parameter of express number in the URL, and the data can be obtained through this parameter. https://www.kkkk1000.com/xss/dom/index.html?serialNumber=YT40359134268305 details page

As you can see in the source code, the express number displayed on the page is directly taken from the URL parameter display. So let’s construct a website like this:

https://www.kkkk1000.com/xss/dom/index.html?serialNumber=<script>alert("xss")</script> )

Then induce others to click on the link) to complete a DOM type XSS attack.

Stored XSS

The difference between stored XSS and reflected XSS is that the malicious code of stored XSS exists on the server, while the malicious code of reflected XSS exists in the URL.

In a stored XSS attack, malicious scripts are stored on the target server. When the browser requests the data, the script is passed back from the server and executed. It is one of the most dangerous types of cross-site scripting and is more subtle than either reflective XSS or DOM-type XSS because it does not need to be triggered manually by the user. Any Web program that allows users to store data is potentially vulnerable to storage XSS vulnerabilities. If a page is subjected to a storage XSS attack, all users accessing the page will be subjected to AN XSS attack.

Attack steps:

1. The attacker submits the malicious code to the server of the target website.

2. The user opens the target website, and the website server takes out the data with malicious code and returns it to the user as normal data.

3. The user’s browser receives the response and parses it, and the malicious code mixed in is executed.

4. Malicious code steals user sensitive data and sends it to the attacker, or impersonates the user, and invokes the target website interface to perform operations specified by the attacker.

For example,

This is a page for comments on articles

A review article

However, the content of the comment is unprocessed, so if we type something like:

After we use this as a comment, all users who open this post will be subjected to a stored XSS attack.

defense

Browser built-in defense (X-XSS-Protection ）

The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome, and Safari that stops browsers from loading pages when a cross-site scripting (XSS) attack is detected.

He can set four values:

X-xss-protection: 0 Disables XSS filtering. X-xss-protection: 1 Enables XSS filtering (usually the default for browsers). If a cross-site scripting attack is detected, the browser will clean up the page (remove the insecure parts). X-XSS-Protection: 1; Mode =block Enables XSS filtering. If an attack is detected, the browser does not clear the page, but prevents it from loading. X-XSS-Protection: 1; Report =< Reporting-URI > Enables XSS filtering. If a cross-site scripting attack is detected, the browser clears the page and sends a violation report using the functionality of the CSP report-URI directive.Copy the code

This browser-built defense only protects against reflective XSS by checking the correlation between the URL and elements in the DOM, but it doesn’t completely prevent reflective XSS, and not all browsers support X-XSS-Protection.

escape

In XSS attacks, the attacker mainly injects the script by constructing special characters, so it is necessary to detect the user’s input, and it needs to detect the input on both the client and the server, and then escape the user’s input data.

The main idea is to escape the special characters contained in the input, such as <, >, &, “, ‘, to prevent XSS attacks.

Here is a method for escaping:

function escapeHTML(str) { if (! str) return ''; str = str.replace(/&/g, "&"); str = str.. replace(/</g, "<"); str = str.. replace(/>/g, ">"); str = str.. replace(/"/g, """); str = str.. replace(/'/g, " "); return str; };Copy the code

filter

In rich text, we need to preserve HTML, so we can’t defend against XSS attacks by escaping. Instead, we can defend against XSS attacks by filtering, that is, by using only whitelisted HTML tags and their attributes.

A recommended component called XSS is a component that filters HTML by whitelist to prevent XSS attacks.

Content Security Policy (CSP)

Content Security Policy (CSP), the essence of the whitelist system, developers clearly tell the client, which external resources can be loaded and executed, greatly enhance the Security of web pages.

There are two ways to enable CSP. One is through the Content-security-policy field of the HTTP header.

Content-Security-Policy: script-src 'self'; 
                         object-src 'none';
                         style-src cdn.example.org third-party.org; 
                         child-src https:
Copy the code

The other is through the
tag of the web page.

<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:">
Copy the code

In the above code, CSP has done the following configuration.

  • Script: Trust only the current domain name
  • <object>Tag: do not trust any URL, that is, do not load any resources
  • Style sheet: Trust cdn.example.org and Followed party.org only
  • Page face content, such as<frame> 、 <iframe>: Must be loaded using HTTPS
  • Other resources: No limit

When enabled, external resources that do not conform to CSP will be prevented from loading.

conclusion

The nature of XSS attacks is that what is entered is executed as a program, so we cannot fully trust what the user enters and need to consider how to avoid it being executed as a program.