[Cybersecurity] clear to you what is XSS attack

1. What is XSS attack

XSS (Cross Site Scripting) would have been abbreviated as CSS, with the abbreviation for Cascading Style Sheets (Cascading Style Sheets, CSS) to distinguish, cross-site scripting attacks abbreviated as XSS. So is cross-site scripting XSS meaning.

Nature XSS XSS (Cross Site Scripting), was the attacker to insert malicious page in the web script the code (this code can be JS script, CSS styles, or other unexpected code), when the user browses the page , script code embedded therein is executed, so as to achieve malicious user. For example, read cookie, session, tokens, or other sensitive information website site, the user phishing fraud. More classic accident are:

June 28, 2011, Sina Weibo is XSS attack, a large number of users to automatically forward microblogging private letter. Automatic user attention, a large number of users to be somehow controlled. JS code may be used because the user clicks the button in place of the transmission request, so the damage is very large.

1.1 XSS attack hazard

  • Document.cookie information by stealing a cookie

  • Structure and style using js or css destroy normal page

  • Traffic Hijack (navigate to other pages by having access to certain window.location.href)

  • dos attack: to take up too much server resources, so that legitimate users can not get a reasonable use of server response to client requests. And can be made by a process carried cookie information returned from the server 400 at the beginning of the status code, to reject a reasonable service request.

  • Using iframe, frame, XMLHttpRequest or said Flash, etc., to (attack) the identity of the user to perform some management actions, or perform some general, such as micro-blog, add friends, send private messages and other operations, and the attacker may also use iframe , frame further be CSRF attacks.

  • Control of corporate data, including reading, tampering, add, delete sensitive data capacity of enterprises.

Type 2. XSS attacks

2.1 reflective XSS attack

Reflective XSS vulnerabilities common in function to pass parameters through URL, such as site search, jump and so on. Since the initiative requires the user to open a malicious URL to take effect, the attacker will often combine various means to induce users to click. For example, the following URL:




POST content can also trigger reflective XSS, but its trigger conditions are harsh (constructed form submission page, and guides the user clicks), it is very rare.

Reflective XSS attack step

1. The assailant construct a special URL, which contains malicious code.
    2. When a user opens a malicious code URL, the website server will remove the malicious code from the URL, stitching returned to the browser in HTML.
    3. After the user’s browser receives the response parsing performed, in which the mixed malicious code will be executed.
    4. malicious code to steal user data and sent to the attacker’s Web site, or posing as user behavior, call the target site interface to the execution of arbitrary action.


Note: Chrome and Safari can detect xss attack on the url, the Web page blocking out, but not other browsers, such as IE and Firefox.

Defense reflective XSS attack

  1. Check the input
                Request parameters to check, once suspicious of special characters reject the request. Note that the user can bypass check the browser request directly by Postman and other tools, it is best to check the front and rear ends have done.

  2. Re-displaying the output escape
                Can be seen from the above description, the reflection-type XSS attack to attack, if desired, be displayed on the front page. So is encoded XSS attack defense escape is very effective measures against the potential threat of characters before the output data. For example, in the following manner:

  //对查询参数进行编码,避免反射型 XSS攻击

2.2 Storage XSS attack

Malicious scripts are permanently stored on the target server. When the browser requests data, the script is passed back from the server and executed, with greater impact than reflected and DOM XSS. The reason for storage-type XSS attacks is still not good data filtering: front-end submission data to server side, not good filtering; server side when data is pressed, before storage, front-end request to data from server side, no filtering output.

The more common scenario is that a hacker wrote a malicious JavaScript code contains blog posts, after the article was published, all users access to the blog, will execute this malicious js code in their browser.

Storage-type XSS attack step

1. The assailant malicious code is submitted to the database target site.
    2. 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.
    3. The user’s browser parses performed after receiving a response, wherein mixed malicious code is also performed.
    4. malicious code to steal user data and sent to the attacker’s Web site, or posing as user behavior, withered with the target site interfaces the execution of arbitrary action.
    This attack is common in site functionality with a user to save data, such as forum posting, product reviews, user private letters.

Storage-type XSS attack prevention
    Prevention storage type XSS attacks are also considered from both the input and output.

    Server receives the data, before being stored in the database, and the filter dangerous escape character;

    A front end server receives the data passed to it, before the display page, to escape / filter;

Whether attacking or reflective memory type, the attacker always need to find two points, namely “entry point” and “output point”, only that both conditions are met, XSS attack to take effect. “Entry point” for web pages to inject attack code needed, and place “output point” is the attack code is executed.

2.3 DOM XSS type

DOM XSS type attacks, in fact, front-end javascript code is not precise enough, the untrusted content into the page when using .innerHTML, .outerHTML, .appendChild, document.write () API, etc. to be especially careful not to untrusted inserted into the data as an HTML page, to make use .innerText, .textContent, .setAttribut () and the like.

DOM XSS attack type step

1. attacker construct specific data, which contains malicious code.
    2. The user’s browser to perform a malicious code
    3. maliciously steal user data sent to the attacker’s Web site, or posing as user behavior, call the target site interface to the execution of arbitrary action.

DOM XSS type attacks, and remove malicious code execution done by the browser, which belongs to the front javascript own security vulnerabilities.

2.4 brief summary

3. Some other preventive strategies

  • HTTP-only Cookie: Prohibition JavaScript to read some sensitive Cookie, after the completion of XSS injection attacker can not steal this Cookie property: prevent script posing as a user submits a dangerous operation

  • In the server using HTTP header Content-Security-Policy to specify policy, or set meta standard answer at the front. The following configuration example only allow loading resources under the same domain:

Content-Security-Policy:default-src 'self'`请输入代码`

    Of course, you can use security scanning tool to detect thread.

For now, the main means to deal with XSS attacks or encoding and filtering are two kinds of coding for the special symbol “<,>, &, ‘,” “to html escape, while the filter is to block specific tags properties, events, and if you do not want to stringent safety and limit the flexibility of the product itself, so I recommend a “coding” scheme.






Leave a Reply