What is the XSS

XSS is short for Cross-site Scripting.

XSS is an injection-script attack in which an attacker injects a malicious script into a benign, trusted website by submitting a form or Posting a comment. When other users enter the site, the script is executed without the user’s knowledge. Such scripts can steal user information, modify page content, or fake users to perform other actions, with incalculable consequences.

XSS attacks typically occur when:

  • Enter something into a Web app that contains some bad code, usually a piece of code containing an HTTP request
  • This content is included in dynamic content sent to other users, and this content has not been validated

Malicious content sent to a Web browser usually takes the form of snippets of JavaScript code, but can also include HTML, Flash, or any other type of code that the browser might execute. The number of XSS – based attacks is almost unlimited. But the way they usually work is:

  • Sending private data to an attacker that includes information such as cookies or other session information
  • The attacker tampered with the content of the page
  • Performing other malicious operations on a user’s machine under the guise of a website containing vulnerabilities

According to OWASP (Open Web Application Security Project), XSS is one of the 10 most serious Web Application Security risks in 2017.



In fact,XSS appears in every TOP10 rating…



XSS instance

Want to know how XSS causes an attack? Check out the following article, which describes an XSS vulnerability – the simplest demonstration of XSS cross-site scripting – in the CSDN blog case, an attacker used XSS to gain access to users’ private information.

Classification of XSS attacks

XSS are generally classified into two types: Stored XSS and Reflected XSS.

There is, however, another unknown type, DOM-based XSS.



Stored XSS refers to attacks that permanently store malicious scripts on target servers, such as databases, message forums, access logs, comment content, etc.

Reflective XSS is when a user clicks on a malicious link, submits a form, or enters a malicious site, the script is injected into the target site. The Web server will inject scripts, such as an error message, search results, and so on, back to the user’s browser. The browser executes this script because it thinks the response is from a trusted server. A dangerous XSS case – easy access to a logged-in user’s cookie-CSDN blog. In this case, if someone entices you to click on the link mentioned in the article above, your private information on the Web site is sent to another server.


Dom-based XSS refers to an attacker using native JavaScript code to tamper with the DOM structure of the client, resulting in user operations performing “unexpected” actions.

For dom-based XSS, see the following example

Below is the code for a website that provides a drop down box for selecting a language and recommends the default language based on the default parameter on your URL.

Select your language:

<select><script>

document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=") + + 8)"</OPTION>");

document.write("<OPTION value=2>English</OPTION>"); < / script > < / select >...Copy the code

Typically, the page’s address would look something like this:

http://www.some.site/page.html?default=FrenchCopy the code

Dom-based XSS takes advantage of the vulnerability in the DOM structure of the page and sends the following link to the victim

http://www.some.site/page.html?default=<script>alert(document.cookie)</script>Copy the code

When the victim clicks on the link, it alerts all of the user’s cookies.


XSS precaution principle

As for the prevention of XSS attacks, I have simplified the prevention methods in OWASP, if you are interested, you can go to see the details.

Rule 0 — Never insert untrusted data where JavaScript is allowed to be placed

As shown in the following code:

<script>... Never put untrusted data here... </script> is placed directly inside the script tag <! -... Never put untrusted data here... --> Put in HTML comments <div... Never put untrusted data here... =test/> As a property name < never put untrusted data here... href="/test"<style>... Never put untrusted data here... </styleCopy the code

Rule 1 — Always escape untrusted HTML code before inserting it into an element

As shown in the following code:

<body>... Escape untrusted data and put it here... </body> <div>... Escape untrusted data and put it here... </div> any other normal HTML elementsCopy the code

Common escape rules are as follows:

& --> &amp;
 < --> &lt;
 > --> &gt;
 " --> " ' --> ' / --> /Copy the code

Rule 2 — Always escape before inserting untrusted HTML code into an element’s attributes

Look at the following code:

<div attr=... Escape untrusted data and put it here... >content</div> <div attr= within an unquoted attribute value'... Escape untrusted data and put it here... '>content</div> <div attr= within the single quoted attribute value"... Escape untrusted data and put it here..."> Content </div> inside the double quoted attribute valueCopy the code

Rule 3 — Always escape JavaScript code before assigning values to untrusted data

Look at the following code:

<script>alert('... Escape untrusted data and put it here... '</script> Within a string <script>x='... Escape untrusted data and put it here... '</script> on the side of the expression <div onmouseover="x='... Escape untrusted data and put it here... '"</div> is inside the event handlerCopy the code

Note that some JavaScript functions can never safely use untrusted data as input, such as the following code:

<script>
 window.setInterval('Even if you do escape, you can still be attacked by XSS');
 </script>Copy the code


Principle 3.1 — Escape JSON values in the context of HTML and read values using the json.parse () method

Make sure the content-type of the HTTP response header is Application /json, not text/ HTML, because that could be used for XSS attacks.


A bad case:

HTTP/1.1 200
   Date: Wed, 06 Feb 2013 10:28:54 GMT
   Server: Microsoft-IIS/7.5....
   Content-Type: text/html; charset=utf-8 <-- bad
   ....
   Content-Length: 373
   Keep-Alive: timeout=5, max=100
   Connection: Keep-Alive
   {"Message":"No HTTP resource was found that matches the request URI 'dev.net.ie/api/pay/.html?HouseNumber=9&AddressLine =The+Gardens&AddressLine2=foxlodge+woods&TownName=Meath'."."MessageDetail":"No type was found that matches the controller named 'pay'."} <-- here the script tag may be executedCopy the code

A good example:

HTTP/1.1 200 Date: Wed, 06 Feb 2013 10:28:54 GMT Server: Microsoft-IIS/7.5.... Content-Type: application/json; charset=utf-8 <--good ..... .Copy the code


Principle 4 — Always escape untrusted data before inserting it into a document as a CSS property

Look at the code below

<style>selector { property : ... Escape untrusted data and put it here... ; } </style> attribute values <style>selector {property:"... Escape untrusted data and put it here..."; } </style> Attribute value <span style="property : ... Escape untrusted data and put it here..."> text < / span > attribute valuesCopy the code

It is important to note that there are some CSS property values that are not foolproof against “untrusted” data — even if escaped, these two CSS properties are:

{ background-url : "javascript:alert(1)"; }  
 { text-size: "expression(alert('XSS'))"; }   // only in IECopy the code

You should make sure that all CSS property values introduce external links that start with “HTTP”, not “javascript”.


Rule 5 – Always escape before inserting untrusted data into HTML URL arguments

Look at the code below

<a href="http://www.somesite.com?test=... Escape untrusted data and put it here...">link</a >Copy the code


Bonus rule 1 — Use the httpOnly identity for cookies

Cookies with httpOnly identification are not accessible by JavaScript, and because cookies are based on the same origin principle, they are somewhat protected against XSS attacks that exploit customer cookies.


Bonus point # 2 — Use Content Security Policy in HTTP headers

Use the HTTP header attribute value content-security-Policy to defend against XSS. The HTTP response header Content-security-Policy allows the site manager to control the user agent’s resources on a specified page. With a few exceptions, this policy will largely specify the service source as well as the script endpoint.


Bonus point # 3 — Use an automatic escape template system

Many Web application frameworks provide automatic context escape, such as AngularJS strict context escape and the Go template. Use these techniques whenever possible.


Plus rule 4 — use X-xxs-protection in HTTP headers

HTTP X-XSS-protection response header is a feature in Internet Explorer, Chrome, and Safari that stops the browser from loading the page when a cross-site scripting attack (XSS) is detected. While these protections are largely unnecessary in modern browsers, When sites implement a powerful Content-security-policy to disable inline JavaScript (‘unsafe-inline’), they can still provide protection for users of older browsers that do not yet support CSP.



conclusion

The consequences of an XSS attack are incalculable and often overlooked. In conjunction with the above points, check your Web App for any of the above vulnerabilities.

If you insist on reading the whole article, you must love the front end technology, then I think you need to pay attention to my official account – real front end, where there will be more technology sharing and front end dry goods waiting for you.


Reference article:



Top 8 Front-end security Issues (Part 1) – ThoughtWorks Insights 



Cross-site Scripting (XSS) 



XSS (Cross Site Scripting)
Prevention Cheat Sheet