XSS Introduction
Cross-Site Scripting (XSS) referred to as XSS, it is a code injection attack. In order to distinguish CSS and, where it is the first letter abbreviation into a X, so named XSS. Malicious attacker to insert malicious JavaScript in the web pages of code, when browsing the web surfers will trigger the malicious code, which lead to the disclosure of user data such as Cookie, SessionID, etc., and cause other types of attacks.
XSS is the essence: unfiltered malicious code, the code properly mixed with the site, the browser can not distinguish between what is credible script, resulting in the malicious script is executed. Speaking from the source, that is, code and data to be confused attack, resulting in data browser will interpret the attacker entered the code.
Case Study
For the following code
<input type="text" value="<%= getParameter("keyword") %>">
<button>搜索</button>
<div>
您搜索的关键词是：<%= getParameter("keyword") %>
</div>When constructing a link:
http://xxx/search?keyword="><script>alert('XSS');</script>When the browser requests the link, the server parses the parameters keyword, get "><script>alert('XSS');</script>after splicing yields:
<input type="text" value=""><script>alert('XSS');</script>">
<button>搜索</button>
<div>
您搜索的关键词是："><script>alert('XSS');</script>
</div>Because the parameter data and code pages causes confusion, browse the user parameters <script>alert('XSS');</script>, resolved to code execution.
Fix this problem can be escaped user input parameters.
Use functionescapeHTML()
<input type="text" value="<%= escapeHTML(getParameter("keyword")) %>">
<button>搜索</button>
<div>
您搜索的关键词是：<%= escapeHTML(getParameter("keyword")) %>
</div>escapeHTML()The escape rule is:
| character | After the escape character |
|---|---|
& |
& |
< |
< |
> |
> |
" |
" |
' |
' |
/ |
/ |
After the escape, the browser can be very good to distinguish between the code and the page data submitted by the user in.
<input type="text" value=""><script>alert('XSS');</script>">
<button>搜索</button>
<div>
您搜索的关键词是："><script>alert('XSS');</script>
</div>
- User input data for the purpose of the text is displayed
- An attacker carefully constructed using fragments of the input, resulting in confusion code and data, the user causes the browser to the code input as
- XSS attacks can be prevented by HTML transfer
Sometimes just do escaped HTML is not enough. Such as: HTML, if the inline in JSON
<script>
var initData = <%= data.toJSON() %>
</script>Then you can not use escapeHTML(), because it will destroy the JSON format.
But this time is not secure
- When included in JSON
U+2028orU+2029when these two characters can not be used as literal JavaScript, otherwise it will throw a syntax error. - When JSON contains the string
</script>, the current script tags would be closed, the string content browser parses the HTML in accordance with; at increased by a<script>label or the like can be completed injection.
So we have to lose such a scenario to escape alone.
| character | After the escape character |
|---|---|
| U + 2028 | \u2028 |
| U + 2029 | \ U2029 |
| < | \u003c |
The different scenarios require different rules escape
Avoid the library to write their own escape, consider areas that are not possible, try to use mature, common escape library
Sometimes even I have done all the escape, but still possible XSS, such as the code for the following:
<a href="<%= escapeHTML(getParameter("redirect_to")) %>">跳转...</a>Constructing a link:
http://xxx/?redirect_to=javascript:alert('XSS')In this case, the server response is:
<a href="javascript:alert('XSS')">跳转...</a>Click on athe label, to achieve a XSS.
Because that is not what we expect in the data entered by the user. Here you can take a whitelist policy filtering undesired input.
User input data do requirement limits, undesired input filter
To do blacklist consider fully, if ill-considered, can be bypassed. As the above example, if only the filter
JavaScript, it can be bypassed by using the case.
XSS attacks classification
XSS attacks can be divided into three categories, reflective, and DOM type storage type.
| Types of | Storage area | The insertion point |
|---|---|---|
| Storage-type XSS | Back-end database | HTML |
| Reflective XSS | URL | HTML |
| DOM XSS type | Back-end database / front-end storage / URL | JavaScript front-end |
Storage Area: malicious code storage location
The insertion point: who made malicious code, and insert pages
Reflective XSS
Attack steps:
- An attacker constructs a special URL, which contains the attacker's malicious code
- The attacker will construct a URL to send to the user. Users access the URL, the server will splice malicious code returned to the browser in HTML
- Parse the user's browser to perform after receiving the response, the attacker's malicious code is constructed as a code execution
- Malicious code to steal user data to the attacker or to perform a specific operation
Attacks common in function to pass parameters through the URL, such as site search, jump and so on.
POST request may also trigger XSS reflection type, but the trigger harsh conditions, is less common.
Storage-type XSS
Attack steps:
- The attacker malicious code submitted to the database target site.
- When the user opens the target site, the site server will remove the malicious code from the database, stitching returned to the browser in HTML.
- The user's browser parses performed after receiving a response, wherein mixed malicious code is also performed.
- Malicious code to steal user data and sent to the attacker's Web site, or impersonate the user's behavior, calling the target site interface to the execution of arbitrary action.
Attacks common in site functionality with a user to save data, such as forum posting, product reviews, user private letters.
Reflective XSS difference with the storage type XSS is: storage type XSS malicious code exists in the database, reflective XSS malicious code exists in the URL.
DOM XSS type
Attack steps:
- An attacker to construct a special URL, which contains malicious code.
- The user opens the URL with malicious code.
- The user's browser parses performed after receiving a response, the front end of the URL extracted JavaScript and execute malicious code.
- Malicious code to steal user data and sent to the attacker's Web site, or impersonate the user's behavior, calling the target site interface to the execution of arbitrary action.
DOM XSS type XSS in front of two kinds of differences: DOM XSS type attacks, and remove malicious code execution done by the browser, JavaScript front-end part of their own security vulnerabilities, while the other two belong to the server XSS security vulnerabilities.
XSS injection point
HTML node content
If the user to input comments
"评论“
<script>alert("XSS")</script>If you do not have any defensive measures, eventually resolves to:
<div class = "commentContent">
"评论“
<script>alert("XSS")</script>
</div>HTML attributes / parameters
Speaking as the above
<a href="<%= escapeHTML(getParameter("redirect_to")) %>">跳转...</a>When the address is entered by the user:
http://xxx/?redirect_to=javascript:alert('XSS')It would constitute XSS.
JavaScript code
If the user input variables in JavaScript, it can be carefully constructed, resulting in a string closed in advance, to achieve injection.
<script> var $a = "";alert("XSS");"";</scaript>Rich Text
Nature is a piece of rich text HTML, then it is possible XSS attack. And rich text attack defense is relatively trouble.
XSS bypasses
In order to better do a good job of XSS defense, we base before the defense of the rule, look at the common bypass posture, look at your defense rules are not likely to be bypassed.
Bypassing the case
If ill-considered in the filter, the filter only a fixed label, but the browser is not case-sensitive, so an attacker can be bypassed by changing the case.
After using the return statement to bypass the filter
The idea is to bypass the filter statement will remove keywords, but in consideration of the removal step just once, detection can be nested on the tube, such as <Scr> ript>, when a keyword filtering, just return the specified value Malicious code.
In addition to using the script tag
Not only the script tag can be achieved XSS, other labels are also possible. Such as
<img>,<a>, etc.Keywords bypassing the encoding
If the keyword is filtered defense rules, the keyword may be encoded to bypass rules, then use eval () is performed.
As will alert (1) are encoded
\u0061\u006c\u0065\u0072\u0074(1)Combinations
XSS hazard
Steal user information
The most common is to steal the user's cookie. After the theft of cookie, an attacker may be able to directly use tokens instead of a password to log in user account.
Jump malicious traffic hijacking achieve
Control of the victim machine to attack other sites
Forced Send e-mail
The ability to control corporate data, including reading, tampering, add, delete sensitive corporate data
XSS attack defense
XSS attacks on two premises:
- An attacker submits malicious code
- The browser executing malicious code
filter
Of such <script>、<img>、<a>other labels filtered.
Escape
It can be considered both, front and rear when escaping.
If only the front end of the escape, if an attacker can bypass the front-end, direct construction request, you can submit malicious code.
If the escape at the rear end, before writing user data database storage to escape, and then taken out of use.
But the back end can cause problems when the contents of output, such as
If the user input content and need to be provided to the client front end, the data can not be escaped after adaptation also requires both ends.
5<7Is escaped5<7, then the client directly garbled output willThe distal end at different locations, also requires a different coding.
Displayed in an HTML page;
Assigned to a JavaScript variable;
Escape XSS can be solved under certain circumstances, but would introduce uncertainty.
Here on the front and rear ends need to coordinate, to make sure I know exactly whether the data obtained did escape, the data I need is what.
At the same time when you want to escape the library using the appropriate escape, escape the insertion point in the full HTML template throughout.
| XSS security holes | Is there a simple escape protective effect |
|---|---|
| HTML tags text | Have |
| HTML attribute values | Have |
| CSS inline styles | no |
| 内联 JavaScript | no |
| Inline JSON | no |
| Jump Links | no |
Code data separation
Front-end for the pure rendering:
- Browser to load a static HTML, the HTML does not contain any data with business-related.
- HTML browser and then executed in JavaScript.
- JavaScript load business data by Ajax, DOM API call to update the page.
In a pure front-end rendering, the browser can know exactly what you want to set up a text ( .innerText) or attributes ( .setAttribute) or style ( .style) and so on.
Note that the front-end code stringency
To avoid DOM type XSS, in use .innerHTML, .outerHTML, document.write()the time to be especially careful not to untrusted data as HTML into the page, but should be used .textContent, .setAttribute()and so on.
If Vue / React stack technology, and does not use v-html/ dangerouslySetInnerHTMLfunction, render the front end stage is avoided innerHTML, outerHTMLthe hidden XSS.
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 the untrusted data registration to the string passed to the API these, it is prone to security risks avoided.
CSP Strategy
Content Security Policy (content security policy) is a kind of white list as a credible mechanism to limit the site may contain certain whether the source of the content.
The default configuration is not allowed inline code ( <script>block content, inline event, inline style), and prohibits execution of eval (), newFunction (), setTimeout ([string], ...) and setInterval ([string], ...).
- Prohibit loading domain codes, to prevent attack complex logic.
- Prohibited outside the domain submitted after the site was attacked, the user's data will not leak to the outside domain.
- Prohibiting inline script execution (more stringent rules, now found GitHub use).
- Prohibit the unauthorized execution of the script (of new features, Google Map for mobile use).
- Rational use of reporting can detect XSS, is conducive to fix the problem as soon as possible.
SUMMARY length control input
xss attacks often need to be able to reach a longer string, so you can expect some input may be forced to cut defense by limiting the length.
HTTP-only Cookie
JavaScript is prohibited to read some sensitive Cookie, after the completion of the attacker inject XSS can not steal this Cookie.
XSS detection
In Unleashing an Ultimate XSS Polyglot article, there is a string:
jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3eIt can detect the presence of attributes in HTML, HTML text, HTML comments, jump links, inline JavaScript string, inline CSS style sheets and other XSS vulnerabilities in a variety of contexts, can be detected eval(), setTimeout(), setInterval(), Function(), innerHTML, document.write()and other DOM type XSS vulnerabilities, and can bypass some XSS filter.
By submitting this string in the input box site or stitching it to the URL parameter, it can be detected.
Detection tool :