Overview

Cross Site Scripting (XSS)

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in Web applications. XSS enables attackers to inject client-side script into Web pages viewed by other users.

The expression “cross-site scripting” originally referred to the act of loading the attacked, third-party web application from an unrelated attack site, in a manner that executes a fragment of JavaScript prepared by the attacker in the security context of the targeted domain (a reflected or non-persistent XSS vulnerability). The definition gradually expanded to encompass other modes of code injection, including persistent and non-JavaScript vectors (including ActiveX, Java, VBScript, Flash, or even HTML scripts), causing some confusion to newcomers to the field of information security.

Untrusted Data

Untrusted data is most often data that comes from the HTTP request, in the form of URL parameters, form fields, headers, or cookies. But data that comes from databases, web services, and other sources is frequently untrusted from a security perspective. That is, untrusted data is input that can be manipulated to contain a web attack payload.

Untrusted data should always be treated as though it contains an attack. That means you should not send it anywhere without taking steps to make sure that any attacks are detected and neutralized. As applications get more and more interconnected, the likelihood of a buried attack being decoded or executed by a downstream interpreter increases rapidly

Rules to be follow to avoid XSS

Never Insert Untrusted Data Except in Allowed Locations

 

...NEVER PUT UNTRUSTED DATA HERE... directly in a script

<!--...NEVER PUT UNTRUSTED DATA HERE...--> inside an HTML comment

 in an attribute name

 in a tag name

...NEVER PUT UNTRUSTED DATA HERE... directly in CSS

 Most importantly, never accept actual JavaScript code from an untrusted source and then run it. For example, a parameter named “callback” that contains a JavaScript code snippet. No amount of escaping can fix that.

HTML Escape Before Inserting Untrusted Data into HTML Element Content

Escape the following characters with HTML entity encoding to prevent switching into any execution context, such as script, style, or event handlers. Using hex entities is recommended in the spec. In addition to the 5 characters significant in XML (&, , “, ‘), the forward slash is included as it helps to end an HTML entity.

 & --> &
  <
 > --> >
 " --> "
 ' --> '

' not recommended because its not in the HTML spec

' is in the XML and XHTML specs.

--> /     forward slash is included as it helps end an HTML entity

Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes

 

Rule is for putting untrusted data into typical attribute values like width, name, value, etc. This should not be used for complex attributes like href, src, style, or any of the event handlers like onmouseover. It is extremely important that event handler attributes should follow Rule #3 for HTML JavaScript Data Values.

 
content
     inside UNquoted attribute
 
 
'>content
   inside single quoted attribute
 
 
content
   inside double quoted attribute

Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the &#xHH; format (or a named entity if available) to prevent switching out of the attribute. The reason this rule is so broad is that developers frequently leave attributes unquoted. Properly quoted attributes can only be escaped with the corresponding quote. Unquoted attributes can be broken out of with many characters, including [space] % * + , – / ; < = > ^ and |.

JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values

Rule is concerns dynamically generated JavaScript code – both script blocks and event-handler attributes. The only safe place to put untrusted data into this code is inside a quoted “data value.” Including untrusted data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many more, so use with caution.

DO NOT use any escaping shortcut like \” because the quote character may be matched by the HTML attribute parser which runs first. These escaping shortcuts are also susceptible to “escape-the-escape” attacks where the attacker sends \” and the vulnerable code turns that into \\” which enables the quote.

HTML escape JSON values in an HTML context and read the data with JSON.parse 

If using ajax call to read json-

Ensure returned Content-Type header is application/json and not text/html

BAD http request

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+Gardensalert(1)&AddressLine2=foxlodge+woods&TownName=Meath’.”,”MessageDetail”:”No type was found

that matches the controller named ‘pay’.”} <– this script will pop!!

Good http request

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

CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML Style

It’s important that you only use untrusted data in a property value and not into other places in style data. You should stay away from putting untrusted data into complex properties like url, behavior, and custom (-moz-binding). You should also not put untrusted data into IE’s expression property value which allows JavaScript.

Please note there are some CSS contexts that can never safely use untrusted data as input – EVEN IF PROPERLY CSS ESCAPED!

You will have to ensure that URLs only start with “http” not “javascript” and that properties never start with “expression”.

{ background-url : "javascript:alert(1)"; } // and all other URLs

{ text-size: "expression(alert('XSS'))"; } // only in IE

URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values

 

Rule is for when you want to put untrusted data into HTTP GET parameter value.

Ex

 <a href="http://www.somesite.com?test=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...">link</a >

Escape ASCII charactors less than 256

Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the \HH escaping format. DO NOT use any escaping shortcuts like \” because the quote character may be matched by the HTML attribute parser which runs first.

These escaping shortcuts are also susceptible to “escape-the-escape” attacks where the attacker sends \” and the vulnerable code turns that into \\” which enables the quote.

Sanitize HTML Markup with a Library Designed for the Job

Use http://htmlpurifier.org/ for purify HTML code or also can use ctrl K+D if you are using visual Studio.

DOM based XSS Prevention

 

HTML Escape then JavaScript Escape Before Inserting Untrusted Data into HTML Subcontext within the Execution Context

 

Attributes

 

element.innerHTML = “<HTML> Tags and markup”;
element.outerHTML = “<HTML> Tags and markup”;

Methods

document.write(“<HTML> Tags and markup”);
document.writeln(“<HTML> Tags and markup”);

Guideline

To make dynamic updates to HTML in the DOM safe, we recommend

a) HTML encoding, and then

b) JavaScript encoding all untrusted input, as shown in these examples:

element.innerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
element.outerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
document.write(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);
document.writeln(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);

Note: The Encoder.encodeForHTML() and Encoder.encodeForJS() are just notional encoders. There can be various ways by which we can encode the data. For ex. .Net user can use System.Web.Security.AntiXss Namespace

JavaScript Escape Before Inserting Untrusted Data into HTML Attribute Subcontext within the Execution Context

 

The general rule is to HTML Attribute encode untrusted data (data from the database, HTTP request, user, back-end system, etc.) placed in an HTML Attribute. This is the appropriate step to take when outputting data in a rendering context, however using HTML Attribute encoding in an execution context will break the application display of data.

SAFE but BROKEN example

var x = document.createElement(“input”);
x.setAttribute(“name”, “company_name”);
// In the following line of code, companyName represents untrusted user input
// The Encoder.encodeForHTMLAttr() is unnecessary and causes double-encoding
x.setAttribute(“value”, ‘<%=Encoder.encodeForJS(Encoder.encodeForHTMLAttr(companyName))%>’); 
var form1 = document.forms[0];
form1.appendChild(x);

The problem is that if companyName had the value “Johnson & Johnson”. What would be displayed in the input text field would be “Johnson &amp; Johnson”. The appropriate encoding to use in the above case would be only JavaScript encoding to disallow an attacker from closing out the single quotes and in-lining code, or escaping to HTML and opening a new script tag.

SAFE and FUNCTIONALLY CORRECT example

var x = document.createElement(“input”);
x.setAttribute(“name”, “company_name”);
x.setAttribute(“value”, ‘<%=Encoder.encodeForJS(companyName)%>’);
var form1 = document.forms[0];
form1.appendChild(x);

It is important to note that when setting an HTML attribute which does not execute code, the value is set directly within the object attribute of the HTML element so there is no concerns with injecting up.

Be Careful when Inserting Untrusted Data into the Event Handler and JavaScript code Subcontexts within an Execution Context

Putting dynamic data within JavaScript code is especially dangerous because JavaScript encoding has different semantics for JavaScript encoded data when compared to other encodings. In many cases, JavaScript encoding does not stop attacks within an execution context. For example, a JavaScript encoded string will execute even though it is JavaScript encoded.

 

Therefore, the primary recommendation is to avoid including untrusted data in this context. If you must, the following examples describe some approaches that do and do not work.

var x = document.createElement("a");
x.href="#”;
// In the line of code below, the encoded data on the right (the second argument to setAttribute) 
// is an example of untrusted data that was properly JavaScript encoded but still executes.
x.setAttribute("onclick", "\u0061\u006c\u0065\u0072\u0074\u0028\u0032\u0032\u0029");
var y = document.createTextNode("Click To Test");
x.appendChild(y);
document.body.appendChild(x);

The setAttribute(name_string,value_string) method is dangerous because it implicitly coerces the string_value into the DOM attribute datatype of name_string. In the case above, the attribute name is an JavaScript event handler, so the attribute value is implicitly converted to JavaScript code and evaluated. In the case above, JavaScript encoding does not mitigate against DOM based XSS. Other JavaScript methods which take code as a string types will have a similar problem as outline above (setTimeout, setInterval, new Function, etc.). This is in stark contrast to JavaScript encoding in the event handler attribute of a HTML tag (HTML parser) where JavaScript encoding mitigates against XSS.

JavaScript Escape Before Inserting Untrusted Data into the CSS Attribute Subcontext within the Execution Context

Normally executing JavaScript from a CSS context required either passing javascript:attackCode() to the CSS url() method or invoking the CSS expression() method passing JavaScript code to be directly executed. From my experience, calling the expression() function from an execution context (JavaScript) has been disabled. In order to mitigate against the CSS url() method, ensure that you are URL encoding the data passed to the CSS url() method.

document.body.style.backgroundImage = "url(<%=Encoder.encodeForJS(Encoder.encodeForURL(companyName))%>)";

 

URL Escape then JavaScript Escape Before Inserting Untrusted Data into URL Attribute Subcontext within the Execution Context

 

The logic which parses URLs in both execution and rendering contexts looks to be the same. Therefore there is little change in the encoding rules for URL attributes in an execution (DOM) context. 

var x = document.createElement(“a”);
x.setAttribute(“href”, ‘<%=Encoder.encodeForJS(Encoder.encodeForURL(userRelativePath))%>’);
var y = document.createTextElement(“Click Me To Test”);
x.appendChild(y);
document.body.appendChild(x);

If you utilize fully qualified URLs then this will break the links as the colon in the protocol identifier (“http:” or “javascript:”) will be URL encoded preventing the “http” and “javascript” protocols from being invoked.

Guidelines for Developing Secure Applications Utilizing JavaScript

1. Untrusted data should only be treated as displayable text. Never treat untrusted data as code or markup within JavaScript code.

2. Always JavaScript encode and delimit untrusted data as quoted strings when entering the application (Jim Manico and Robert Hansen)

var x = “<%=encodedJavaScriptData%>”;

3. Use document.createElement(“…”), element.setAttribute(“…”,”value”), element.appendChild(…), etc. to build dynamic interfaces. Please note, element.setAttribute is only safe for a limited number of attributes. Dangerous attributes include any attribute that is a command execution context, such as onclick or onblur. Examples of safe attributes includes align, alink, alt, bgcolor, border, cellpadding, cellspacing, class, color, cols, colspan, coords, dir, face, height, hspace, ismap, lang, marginheight, marginwidth, multiple, nohref, noresize, noshade, nowrap, ref, rel, rev, rows, rowspan, scrolling, shape, span, summary, tabindex, title, usemap, valign, value, vlink, vspace, width.

4. Avoid use of HTML rendering methods:

1. element.innerHTML = “…”; 

2. element.outerHTML = “…”; 

3. document.write(…); 

4. document.writeln(…);

5. There are numerous methods which implicitly eval() data passed to it. Make sure that any untrusted data passed to these methods is delimited with string delimiters and enclosed within a closure or JavaScript encoded to N-levels based on usage, and wrapped in a custom function. Ensure to follow step 4 above to make sure that the untrusted data is not sent to dangerous methods within the custom function or handle it by adding an extra layer of encoding.

ESAPI4JS (located at https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API#tab=JavaScript and jQuery Encoder (located at https://github.com/chrisisbeef/jquery-encoder/blob/master/src/main/javascript/org/owasp/esapi/jquery/encoder.js) are two client side encoding libraries developed by Chris Schmidt.

References

https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet