I. Introduction
The leakage of 120 million user address information in February once again sounded the alarm for major companies. The importance of data security has become increasingly prominent. This has also strengthened our determination to implement normalized security testing. With the normalization of security testing in the test group, more colleagues have become interested in logic vulnerabilities. This series of articles aims to reveal the scope, principles and preventive measures of logic vulnerabilities, and gradually enhance everyone's security awareness. As the first chapter, this article selects the well-known XSS logic vulnerability for introduction.
2. Introduction to XSS vulnerabilities
1.Definition of XSS vulnerability
Cross Site Script (Cross Site Script), in order not to be confused with the abbreviation of Cascading Style Sheets (CSS), cross-site script is abbreviated as XSS. Cross-site scripting (hereinafter referred to as XSS) usually occurs on the client side. The attacker inserts malicious JavaScript code (including VBScript and ActionScript code, etc.) into the web page. When the user browses this page, these malicious codes will be executed, thus exposing the user to attack.
2. Main attack forms of XSS
- Stored cross-site scripting attack
Attackers use the functions of adding and modifying data provided by the application to store malicious data in the server. When other users browse the page displaying the data, the browser will execute the malicious script embedded in the page, thereby achieving the purpose of malicious attack. This This attack is persistent.
- Reflected cross-site scripting attack
The attacker sends a URL to the user and induces it to visit. The browser will execute the malicious script embedded in the page to achieve the purpose of malicious attack. This attack is only executed once and is non-persistent.
- DOM cross-site scripting attack
In the Html page, the data input by the user is not directly manipulated through standardized JavaScript. When the attacker inserts a piece of malicious code, the malicious script will be executed on the final display of the page, thereby achieving the purpose of malicious attack.
3.XSS vulnerability hazards
- Information theft (such as stealing user cookies, forging user identity login)
- Phishing scam
- Worm attack
3. Analysis of XSS vulnerability principles
4. Analysis of XSS vulnerability examples
1. Stored XSS
- There are actually two vulnerability locations. This is similar to iframe embedding. The original URL is test.jd.com, so it directly affects two websites.
- Vulnerability proof: Send the following data packet to insert stored XSS
2. Reflected XSS
- There is no pop-up window after entering the universal statement <script>alert()</script>. Viewing the source code shows that <> has been escaped.
- At the value of the input tag, the content we input is not strictly filtered, so we manually close the value and then execute the script "><script>alert()</script>
5. XSS vulnerability prevention opinions
1. Stored and Reflected XSS
Both stored and reflected 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:
1) Change to pure front-end rendering to separate code and data
Fully escape HTML. The browser first loads a static HTML, which does not contain any business-related data. The browser then executes the JavaScript in the HTML. JavaScript loads business data through Ajax and calls the DOM API to update it on the page. In pure front-end rendering, we will clearly tell the browser: the content to be set below is text (.innerText), attribute (.setAttribute), style (.style), etc. Browsers can no longer be easily tricked into executing unexpected code.
However, pure front-end rendering also needs to pay attention to avoid DOM-type XSS vulnerabilities (such as onload events and javascript:xxx in href, etc., please refer to the "Preventing DOM-type XSS attacks" section below). In many internal and management systems, it is very appropriate to use pure front-end rendering. But for pages with high performance requirements or SEO requirements, we still have to face the problem of splicing HTML.
2) Escape HTML
If splicing HTML is necessary, you need to use a suitable escape library to fully escape the insertion points in the HTML template.
Commonly used template engines, such as doT.js, ejs, FreeMarker, etc., usually have only one rule for HTML escaping, which is to replace & < >
" ' / These characters are escaped.
2. Prevent DOM-type XSS attacks
DOM-type XSS attacks are actually caused by the website's front-end JavaScript code itself not being rigorous enough and executing untrusted data as code.
Be especially careful when using .innerHTML, .outerHTML, and document.write(). Do not insert untrusted data into the page as HTML. Instead, try to use .textContent, .setAttribute(), etc.
If you use the Vue/React technology stack and do not use the v-html/dangerouslySetInnerHTML function, avoid the XSS risks of innerHTML and outerHTML in the front-end render stage.
Inline event listeners in the DOM, such as location, onclick, onerror, onload, onmouseover, etc., the href attribute of the a tag, JavaScript's eval(), setTimeout(), setInterval(), etc., can all run strings as code. . If untrusted data is spliced into a string and passed to these APIs, it is easy to cause security risks, so please be sure to avoid it.
3. Other XSS prevention measures
Although XSS can be prevented through careful escaping when rendering pages and executing JavaScript, relying entirely on development caution is still not enough. The following introduces some general solutions that can reduce the risks and consequences of XSS.
1）Content Security Policy
Strict CSP can play the following roles in preventing XSS:
It is forbidden to load external domain code to prevent complex attack logic.
Submissions from outside domains are prohibited. After the website is attacked, user data will not be leaked to outside domains.
Inline script execution is prohibited (the rules are strict, currently found to be used by GitHub).
Prevent unauthorized script execution (new feature, used by Google Maps mobile version).
Reasonable use of reporting can detect XSS in time and help fix the problem as soon as possible.
For details about CSP, please pay attention to subsequent articles in the front-end security series.
2) Input content length control
For untrusted input, a reasonable length should be limited. Although you can't completely prevent XSS from happening, you can make XSS attacks more difficult.
3) Other security measures
HTTP-only Cookie: Prevents JavaScript from reading certain sensitive cookies. Attackers cannot steal this cookie after completing XSS injection.
Author: JD Logistics Fan Wenjun
Source: JD Cloud Developer Community Ziyuanqishuo Tech Please indicate the source for reprinting
JetBrains releases Rust IDE: RustRover Java 21 / JDK 21 (LTS) GA With so many Java developers in China, an ecological-level application development framework .NET 8 should be born. The performance is greatly improved, and it is far ahead of .NET 7. PostgreSQL 16 is released by a former member of the Rust team I deeply regret and asked to cancel my name. I completed the removal of Nue JS on the front end yesterday. The author said that I will create a new Web ecosystem. NetEase Fuxi responded to the death of an employee who was "threatened by HR due to BUG". Ren Zhengfei: We are about to enter the fourth industrial revolution, Apple Is Huawei's teacher Vercel's new product "v0": Generate UI interface code based on text