Disclaimer: This article is not my original creation. Because I am limited, but I want to read some articles that are not too deep and have a certain breadth. So after browsing some blogs, I compiled this article for reference by students who have the same needs as me.
If there is any infringement, please contact me and delete it immediately. A link to extract the article is attached at the end of the article. Students who want to learn more can learn more.
table of Contents
2. What is the impact of XSS injection (the nature of XSS attacks)?
Four, XSS injection classification
5. What are the methods of XSS injection?
2. Prevent storage and reflection XSS attacks
3. Prevent DOM-type XSS attacks
Seven, some ways to bypass the XSS filter:
5. Transcode label attribute values
6. Base64 encryption and decryption
1. What is XSS injection?
Cross-Site Scripting (cross-site scripting) is abbreviated as XSS, which is a code injection attack. The attacker injects malicious scripts on the target website to make it run on the user's browser. Using these malicious scripts, an attacker can obtain sensitive user information such as Cookie, SessionID, etc., thereby endangering data security. In order to distinguish it from CSS, the first letter of the attack is changed to X, so it is called XSS.
2. What is the impact of XSS injection (the nature of XSS attacks)?
- The malicious code is unfiltered and mixed with the normal code of the website; the browser cannot distinguish which scripts are trustworthy, causing the malicious script to be executed.
- Because it is executed directly on the user's terminal, the malicious code can directly obtain the user's information , or use this information to impersonate the user to initiate an attacker-defined request to the website .
- In some cases, due to input limitations, the injected malicious script is relatively short. However, more complex attack strategies can be completed by introducing external scripts and executing them by the browser.
三、PoC(Proof of Concept)
We can use a simple piece of code to verify and detect the existence of vulnerabilities . Such code is called PoC (Proof of Concept). The PoC to verify the existence of XSS vulnerabilities is as follows:
- <script>alert(/xss/)</script>
- <script>confirm('xss')</script>
- <script>prompt('xss')</script>
Four, XSS injection classification
According to the source of the attack, XSS attacks can be divided into three types: storage type, reflection type and DOM type.
| Types of | Storage area* | Insertion point* |
|---|---|---|
| Stored XSS | Backend database | HTML |
| Reflective XSS | URL | HTML |
| DOM type XSS | Back-end database/front-end storage/URL | Front-end JavaScript |
- Storage area: the location where the malicious code is stored.
- Insertion point: Who gets the malicious code and inserts it on the webpage.
1. Stored XSS
Steps to attack stored XSS :
- The attacker submits the malicious code to the database of the target website .
- When the user opens the target website , the website server fetches the malicious code from the database, splices it in HTML and returns it to the browser .
- After receiving the response, the user's browser parses and executes it , and the malicious code mixed in it is also executed.
- The malicious code steals user data and sends it to the attacker's website , or pretends to be a user, calling the target website interface to perform the operation specified by the attacker.
Such attacks are common in:
Website functions with user saved data , such as forum posting, product reviews, user private messages, etc.
2. Reflective XSS
XSS reflection type of attack steps :
- The attacker constructs a special URL that contains malicious code.
- When a user opens a URL with malicious code , the website server will take the malicious code out of the URL , splice it in HTML and return it to the browser .
-
The user browser parses and executes the response after receiving the response , and the malicious code mixed in it is also executed.
-
The malicious code steals user data and sends it to the attacker's website , or pretends to be a user, calling the target website interface to perform the operation specified by the attacker.
Reflected XSS vulnerabilities are common in:
The function of passing parameters through URL, such as website search , jump, etc.
Since users need to actively open malicious URLs to take effect, attackers often combine multiple methods to induce users to click.
The content of POST can also trigger reflective XSS, but its trigger conditions are relatively harsh (the form submission page needs to be constructed and the user is guided to click), so it is very rare.
3. DOM type XSS
DOM XSS type of attack steps :
- The attacker constructs a special URL that contains malicious code.
- The user opens the URL with malicious code.
- The user browser parses and executes the response after receiving the response, and the front-end JavaScript takes out the malicious code in the URL and executes it .
- The malicious code steals user data and sends it to the attacker's website, or pretends to be a user, calling the target website interface to perform the operation specified by the attacker.
The difference between the three attack methods :
The malicious code of stored XSS is stored in the database , and the malicious code of reflected XSS is stored in the URL . In DOM-type XSS attacks , the removal and execution of malicious code is done by the browser , which belongs to the security vulnerabilities of the front-end JavaScript itself , while the first two belong to the security vulnerabilities of the server .
5. What are the methods of XSS injection?
- In the text embedded in HTML, malicious content is injected with script tags. [ <script>alert(/xss/)</script> ] (the blue part is the typed content, these methods can be used in combination, for example: first use "> to close the input tag, and then perform XSS through these methods injection)
- In the tag attribute, the malicious content contains quotation marks, which breaks the restriction of attribute value and injects other attributes or tags. [<input type="text " οnkeydοwn="alert(/xss/)"> ]
- In the tag href, src attribute and the like, comprising
javascript:other executable code. [<a href=" javascript:alert(/xss/)">touch me!</a> ] - Inject uncontrolled code in events such as onload, onerror, and onclick. [<img src='./smile.jpg' οnmοuseοver='alert(/xss/)' >]
- In the style attributes and tag, contains similar code (the new version of the browser can already guard against). [<div style="background-image:url( javascript:alert(/xss/) )">]
background-image:url("javascript:...");
6. Prevention of XSS attacks
XSS attacks have two main elements:
- The attacker submits malicious code.
- The browser executes malicious code.
In view of these two elements, the following four types of prevention programs can be summarized:
1. Input Filter
Input filtering can solve specific XSS problems in some cases, but it will introduce a lot of uncertainty and garbled problems. Of course, for clear input types, such as numbers, URLs, phone numbers, email addresses, etc., input filtering is still necessary.
The problems are as follows:
- The user's input content may be provided to the front end and the client at the same time, and once it passes
escapeHTML(), the content displayed on the client becomes garbled (5 < 7). -
In the front end, the encoding required for different positions is also different.
-
When
5 < 7as a mosaic HTML pages can be displayed:<div title="comment">5 < 7</div> - When
5 < 7returning by Ajax, JavaScript, and then assigned to a variable, the front end of the string is obtained after the escape character. This content cannot be directly used for the display of templates such as Vue, nor can it be used directly for content length calculation. Cannot be used for titles, alerts, etc.
-
2. Prevent storage and reflection XSS attacks
Both storage and reflective XSS are inserted into the response HTML after the malicious code is taken out on the server side. The "data" deliberately written by the attacker is embedded in the "code" and executed by the browser.
There are two common ways to prevent these two vulnerabilities:
- Change to pure front-end rendering to separate code and data.
- Fully escape the HTML.
1) Pure front-end rendering :
- The browser first loads a static HTML, which does not contain any business-related data.
- Then the browser executes the JavaScript in the HTML.
- JavaScript loads business data through Ajax and calls DOM API to update it on the page.
In pure front-end rendering, we will explicitly tell the browser:
The content to be set below is text ( .innerText), attributes ( .setAttribute), styles ( .style), etc. The browser will not be easily deceived and execute unexpected code.
But pure front-end rendering needs to be taken to avoid DOM XSS vulnerability type (such as
onloadevents andhrefinjavascript:xxx, please refer to the following "preventive type DOM XSS attack" section).In many internal and management systems, pure front-end rendering is very appropriate. But for pages with high performance requirements or SEO requirements, we still have to face the problem of splicing HTML.
2.) Escaping HTML
If splicing HTML is necessary, you need to use a suitable escape library to fully escape the insertion points in the HTML template.
Common template engine, such as doT.js, ejs, FreeMarker, etc., usually only for HTML escaping a rule, is to put & < > " ' /these characters escaped out, XSS can indeed play a protective role, but not perfect:
| XSS security vulnerabilities | Does simple escaping have a protective effect |
|---|---|
| HTML tag text content | Have |
| HTML attribute value | Have |
| CSS inline style | no |
| Inline JavaScript | no |
| Inline JSON | no |
| Jump link | no |
Therefore, to improve XSS protection measures, we must use a more complete and detailed escaping strategy. For example, in Java projects, the commonly used escape library is org.owasp.encoder.
HTML coding is very complicated, and corresponding escaping rules should be used in different contexts.
3. Prevent DOM-type XSS attacks
The DOM inline event listener, such as location, onclick, onerror, onload, onmouseoveretc., <a>a tag hrefattribute, JavaScript the eval(), setTimeout(), setInterval()and the like, can run the code as a string . If untrusted data is spliced into a string and passed to these APIs, it is easy to cause security risks, so please avoid it.
4. Other XSS preventive measures (there are many more, you can refer to the third article in the appendix)
- HttpOnly: The HttpOnly attribute is set in the cookie, then the cookie information cannot be read through the js script, which can effectively prevent XSS attacks and steal cookie content.
- secure: Tell the browser to send cookies only when the request is https, and not to send cookies when the request is http.
response.addHeader("Set-Cookie", "uid=112; Path=/; Secure; HttpOnly");
Seven, some ways to bypass the XSS filter:
1. Case conversion
The payload can be case-converted. As in the following two examples.
<Img sRc='#' Onerror ="alert(/xss/)" />
<a hREf ="javaScript:alert(/xss/)">click me</a>
2. Use quotation marks
The HTML language is not sensitive to the use of quotation marks. When our code lacks quotation marks , some browsers will automatically add or complete them , but some filter functions are "required comparison".
- <img src="#" οnerrοr="alert(/xss/)"/>
- <img src='#' οnerrοr='alert(/xss/)'/>
- <img src=# οnerrοr=alert(/xss/) />
3. [/]Replace spaces
You can use left slashes instead of spaces.
<Img/sRc='#'/Onerror='alert(/xss/)' />
4. Tab and Enter
We can add Tab (horizontal tab, note that it is not a space, space is not allowed) and carriage return in some positions to bypass keyword detection.
- <Img/sRc='#'/Onerror ='alert(/xss/)' />
- <A hREf="j avascript:alert(/xss/)">click me!</a>
- <A hREf="j (换行) avascript:alert(/xss/)">click me!</a>
5. Transcode label attribute values
- The corresponding codes are as follows:
| letter | ASCII | Decimal code | Hexadecimal encoding | |
|---|---|---|---|---|
| 1 | a | 97 | a | a |
| 2 | e | 101 | e | e |
| 3 | Tab | 9 | 	 | |
| 4 | Wrap | 10 | 
 | |
| 5 | Carriage return | 13 | 
 | |
| 6 | SOH |  | ||
| 7 | STX |  |
- We can insert 3-5 to any position.
- Insert 6-7 characters into the head position.
例如：<a href=" ja v s	 c r ipt:alert(/xss/)">click me!</a>
6. Base64 encryption and decryption
First perform base64 encryption on the XSS injected code , put the encrypted code into the atob function for decryption , and finally use eval to execute the maliciously injected code
<input type="text" name="p1" size="50" value="guangtailang" ><script>eval(atob('YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=='));</script> ">
7. Split cross-site
- <script>z='alert'</script>
- <script>z=z+'(/xss/)'</script>
- <script>eval(z)</script>
- <script>alert(/xss/)</script>
Excerpted from:
Attributes and functions of httponly in Cookie
XSS - three basic vulnerabilities (a brief talk)
Front-end Security Series (1): How to prevent XSS attacks?