OWASP - User contributions [en]

Abridged XSS Prevention Cheat Sheet

2011-11-16T06:39:39Z

Abraham Kang:

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
= Introduction =

Cross site scripting is the most common web vulnerability. It represents a serious threat because cross site scripting allows evil attacker code to run in a victim’s browser. More details about XSS can be found here: [https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29 https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29]

= XSS Prevention Overview =

{| class="wikitable"
|-
! Data Type
! Context
! Code Sample
! Defense
|-
| String
| HTML Body
| UNTRUSTED DATA
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content HTML Entity Encoding]</li></ul>
|-
| String
| HTML Attribute, quoted
| UNTRUSTED DATA">
| <ul><li>HTML Entity Encode single and double quotes</li></ul>
|-
| String
| HTML Attribute, unquoted
| UNTRUSTED DATA>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes Aggressive HTML Entity Encoding]</li></ul>
|-
| String
| GET Parameter
| <a href="/site/search?value=UNTRUSTED DATA">clickme</a>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.235_-_URL_Escape_Before_Inserting_Untrusted_Data_into_HTML_URL_Parameter_Values URL Encoding]</li></ul>
|-
| String
| Untrusted URL rendered in an HREF tag (or other HTML link contexts)
| <a href="UNTRUSTED DATA">clickme</a>
| <ul><li>URL Validation<li>reject javascript: URL’s<li>Whitelist http, https and other safe URL types<li>Attribute encoding<li>safe URL verification</ul>
|-
| String
| CSS
| <div style="width: UNTRUSTED DATA;">Selection</div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values Strict structural validation]<li>CSS Hex encoding<li>good design of CSS Features</ul>
|-
| String
| JavaScript
| <script>var currentValue='UNTRUSTED DATA';</script>
| <ul><li>Ensure JavaScript variables are quoted</li><li>JavaScript Hex Encoding</li><li>JavaScript Unicode Encoding</li></ul>
|-
| String
| JavaScript Event Handler Attribute
| <input type="button" onclick="UNTRUSTED DATA" .../>
| <ul><li>Ensure UNTRUSTED DATA is quoted</li><li>JavaScript Hex or Unicode Encoding but NO backslash encoding (\" or \' or \\) </li></ul>
|-
| HTML Text
| HTML Body
| UNTRUSTED HTML
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Use_an_HTML_Policy_engine_to_validate_or_clean_user-driven_HTML_in_an_outbound_way HTML Validation (JSoup, AntiSamy, HTML Sanitizer)]</li></ul>
|-
| String
| DOM XSS
|
| <ul><li>[[DOM based XSS Prevention Cheat Sheet]]</li></ul>
|}

= Output Encoding Types =

{| class="wikitable"
|-
! Encoding Type
! Encoding Mechanism
|-
| HTML Entity Encoding
| & --> &amp; < --> &lt; > --> &gt; " --> &quot; ' --> &#x27; ' is not recommended / --> &#x2F; forward slash is included as it helps end an HTML entity
|-
| HTML Attribute Encoding
| TODO
|-
| URL Encoding
| TODO
|-
| JavaScript HEX Encoding
| TODO
|-
| CSS Hex Encoding
| TODO
|}

= Related Articles =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Jim Manico - jim [at] owasp.org 
Jeff Williams - jeff [at] aspectsecurity.com

[[Category:Cheatsheets]]

Abridged XSS Prevention Cheat Sheet

2011-11-16T06:36:11Z

Abraham Kang:

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
= Introduction =

Cross site scripting is the most common web vulnerability. It represents a serious threat because cross site scripting allows evil attacker code to run in a victim’s browser. More details about XSS can be found here: [https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29 https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29]

= XSS Prevention Overview =

{| class="wikitable"
|-
! Data Type
! Context
! Code Sample
! Defense
|-
| String
| HTML Body
| UNTRUSTED DATA
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.231_-_HTML_Escape_Before_Inserting_Untrusted_Data_into_HTML_Element_Content HTML Entity Encoding]</li></ul>
|-
| String
| HTML Attribute, quoted
| UNTRUSTED DATA">
| <ul><li>HTML Entity Encode single and double quotes</li></ul>
|-
| String
| HTML Attribute, unquoted
| UNTRUSTED DATA>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes Aggressive HTML Entity Encoding]</li></ul>
|-
| String
| GET Parameter
| <a href="/site/search?value=UNTRUSTED DATA">clickme</a>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.235_-_URL_Escape_Before_Inserting_Untrusted_Data_into_HTML_URL_Parameter_Values URL Encoding]</li></ul>
|-
| String
| Untrusted URL rendered in an HREF tag (or other HTML link contexts)
| <a href="UNTRUSTED DATA">clickme</a>
| <ul><li>URL Validation<li>reject javascript: URL’s<li>Whitelist http, https and other safe URL types<li>Attribute encoding<li>safe URL verification</ul>
|-
| String
| CSS
| <div style="width: UNTRUSTED DATA;">Selection</div>
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values Strict structural validation]<li>CSS Hex encoding<li>good design of CSS Features</ul>
|-
| String
| JavaScript
| <script>var currentValue='UNTRUSTED DATA';</script>
| <ul><li>Ensure JavaScript variables are quoted</li><li>JavaScript Hex Encoding</li><li>JavaScript Unicode Encoding</li></ul>
|-
| String
| JavaScript Event Handler Attribute
| <input type="button" onclick="UNTRUSTED DATA" .../>
| <ul><li>Ensure JavaScript variables are quoted</li><li>JavaScript Hex or Unicode Encoding but NO backslash encoding (\" or \' or \\) </li></ul>
|-
| HTML Text
| HTML Body
| UNTRUSTED HTML
| <ul><li>[https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.236_-_Use_an_HTML_Policy_engine_to_validate_or_clean_user-driven_HTML_in_an_outbound_way HTML Validation (JSoup, AntiSamy, HTML Sanitizer)]</li></ul>
|-
| String
| DOM XSS
|
| <ul><li>[[DOM based XSS Prevention Cheat Sheet]]</li></ul>
|}

= Output Encoding Types =

{| class="wikitable"
|-
! Encoding Type
! Encoding Mechanism
|-
| HTML Entity Encoding
| & --> &amp; < --> &lt; > --> &gt; " --> &quot; ' --> &#x27; ' is not recommended / --> &#x2F; forward slash is included as it helps end an HTML entity
|-
| HTML Attribute Encoding
| TODO
|-
| URL Encoding
| TODO
|-
| JavaScript HEX Encoding
| TODO
|-
| CSS Hex Encoding
| TODO
|}

= Related Articles =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Jim Manico - jim [at] owasp.org 
Jeff Williams - jeff [at] aspectsecurity.com

[[Category:Cheatsheets]]

OWASP Connections Committee - Application 7

2011-09-29T13:14:45Z

Abraham Kang:

[[How to Join a Committee|Click here to return to 'How to Join a Committee' page]]

----
{| style="width:100%" border="0" align="center"
! colspan="2" align="center" style="background:#4058A0; color:white"|'''COMMITTEE APPLICATION FORM'''
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Applicant's Name'''
| colspan="1" style="width:85%; background:#cccccc" align="left"|Jerry Hoff
|-
| style="width:25%; background:#7B8ABD" align="center"| '''Current and past OWASP Roles'''
| colspan="1" style="width:85%; background:#cccccc" align="left"|OWASP Video Series
|-
| style="width:25%; background:#7B8ABD" align="center"| '''Committee Applying for'''
| colspan="1" style="width:85%; background:#cccccc" align="left"|OWASP Connection Committee
|}
----

----
Please be aware that for an application to be considered by the board, '''you MUST have 5 recommendations'''.
An incomplete application will not be considered for vote.
----

----
{| style="width:100%" border="0" align="center"
! colspan="8" align="center" style="background:#4058A0; color:white"|'''COMMITTEE RECOMMENDATIONS'''
|-
! align="center" style="background:white; color:white"|
! align="center" style="background:#7B8ABD; color:white"|'''Who Recommends/Name'''
! align="center" style="background:#7B8ABD; color:white"|'''Role in OWASP'''
! align="center" style="background:#7B8ABD; color:white"|'''Recommendation Content'''
|-
| style="width:3%; background:#cccccc" align="center"|'''1'''
| style="width:20%; background:#cccccc" align="center"| Simon Bennetts
| style="width:20%; background:#cccccc" align="center"| ZAP Project Lead, Manchester UK Chapter Leader
| style="width:57%; background:#cccccc" align="center"| I strongly support Jerry's candidacy for the GCC. His AppSec tutorial videos are a great way to spread the OWASP message.
|-
| style="width:3%; background:#cccccc" align="center"|'''2'''
| style="width:20%; background:#cccccc" align="center"| Ludovic Petit
| style="width:20%; background:#cccccc" align="center"| Chapter leader OWASP France, Connections Committee Member
| style="width:57%; background:#cccccc" align="center"| We need guys like Jerry. His work is both a must and serves the Owasp voice, definitely!
|-
| style="width:3%; background:#cccccc" align="center"|'''3'''
| style="width:20%; background:#cccccc" align="center"| Jack Mannino
| style="width:20%; background:#cccccc" align="center"| Mobile Security Project
| style="width:57%; background:#cccccc" align="center"| Jerry has great ideas on how to promote application security, and the drive to get it done.
|-
| style="width:3%; background:#cccccc" align="center"|'''4'''
| style="width:20%; background:#cccccc" align="center"| Chris Schmidt
| style="width:20%; background:#cccccc" align="center"| GPC / ESAPI
| style="width:57%; background:#cccccc" align="center"| Jerry has great vision and ideas on how to make AppSec visible and accessible - he would be a great addition to the GCC
|-
| style="width:3%; background:#cccccc" align="center"|'''5'''
| style="width:20%; background:#cccccc" align="center"| Sherif Koussa
| style="width:20%; background:#cccccc" align="center"| GIC / Ottawa CL / CS Project Co-Leader
| style="width:57%; background:#cccccc" align="center"| You know from the moment you start talking to Jerry, that he has the kind of vision and leadership that we need at OWASP. Most importantly, he knows how to communicate them in a way that could be easily accepted by the listener. Definitely recommended.
|-
| style="width:3%; background:#cccccc" align="center"|'''6'''
| style="width:20%; background:#cccccc" align="center"| Abraham Kang
| style="width:20%; background:#cccccc" align="center"| DOM XSS Cheat Sheet / OWASP Guide
| style="width:57%; background:#cccccc" align="center"| Jerry is not only an outstanding and knowledgeable security practitioner but also understands how to communicate to developers. His application security video series is a testament to this. Jerry is hard working and takes responsibility of the projects that he is involved with. I am sure that Jerry will be an important contributor to the Connections Committee.
|}
----

OWASP Connections Committee - Application 7

2011-09-29T13:14:19Z

Abraham Kang:

[[How to Join a Committee|Click here to return to 'How to Join a Committee' page]]

----
{| style="width:100%" border="0" align="center"
! colspan="2" align="center" style="background:#4058A0; color:white"|'''COMMITTEE APPLICATION FORM'''
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Applicant's Name'''
| colspan="1" style="width:85%; background:#cccccc" align="left"|Jerry Hoff
|-
| style="width:25%; background:#7B8ABD" align="center"| '''Current and past OWASP Roles'''
| colspan="1" style="width:85%; background:#cccccc" align="left"|OWASP Video Series
|-
| style="width:25%; background:#7B8ABD" align="center"| '''Committee Applying for'''
| colspan="1" style="width:85%; background:#cccccc" align="left"|OWASP Connection Committee
|}
----

----
Please be aware that for an application to be considered by the board, '''you MUST have 5 recommendations'''.
An incomplete application will not be considered for vote.
----

----
{| style="width:100%" border="0" align="center"
! colspan="8" align="center" style="background:#4058A0; color:white"|'''COMMITTEE RECOMMENDATIONS'''
|-
! align="center" style="background:white; color:white"|
! align="center" style="background:#7B8ABD; color:white"|'''Who Recommends/Name'''
! align="center" style="background:#7B8ABD; color:white"|'''Role in OWASP'''
! align="center" style="background:#7B8ABD; color:white"|'''Recommendation Content'''
|-
| style="width:3%; background:#cccccc" align="center"|'''1'''
| style="width:20%; background:#cccccc" align="center"| Simon Bennetts
| style="width:20%; background:#cccccc" align="center"| ZAP Project Lead, Manchester UK Chapter Leader
| style="width:57%; background:#cccccc" align="center"| I strongly support Jerry's candidacy for the GCC. His AppSec tutorial videos are a great way to spread the OWASP message.
|-
| style="width:3%; background:#cccccc" align="center"|'''2'''
| style="width:20%; background:#cccccc" align="center"| Ludovic Petit
| style="width:20%; background:#cccccc" align="center"| Chapter leader OWASP France, Connections Committee Member
| style="width:57%; background:#cccccc" align="center"| We need guys like Jerry. His work is both a must and serves the Owasp voice, definitely!
|-
| style="width:3%; background:#cccccc" align="center"|'''3'''
| style="width:20%; background:#cccccc" align="center"| Jack Mannino
| style="width:20%; background:#cccccc" align="center"| Mobile Security Project
| style="width:57%; background:#cccccc" align="center"| Jerry has great ideas on how to promote application security, and the drive to get it done.
|-
| style="width:3%; background:#cccccc" align="center"|'''4'''
| style="width:20%; background:#cccccc" align="center"| Chris Schmidt
| style="width:20%; background:#cccccc" align="center"| GPC / ESAPI
| style="width:57%; background:#cccccc" align="center"| Jerry has great vision and ideas on how to make AppSec visible and accessible - he would be a great addition to the GCC
|-
| style="width:3%; background:#cccccc" align="center"|'''5'''
| style="width:20%; background:#cccccc" align="center"| Sherif Koussa
| style="width:20%; background:#cccccc" align="center"| GIC / Ottawa CL / CS Project Co-Leader
| style="width:57%; background:#cccccc" align="center"| You know from the moment you start talking to Jerry, that he has the kind of vision and leadership that we need at OWASP. Most importantly, he knows how to communicate them in a way that could be easily accepted by the listener. Definitely recommended.
|-
| style="width:3%; background:#cccccc" align="center"|'''6'''
| style="width:20%; background:#cccccc" align="center"|
| style="width:20%; background:#cccccc" align="center"| DOM XSS Cheat Sheet / OWASP Guide
| style="width:57%; background:#cccccc" align="center"| Jerry is not only an outstanding and knowledgeable security practitioner but also understands how to communicate to developers. His application security video series is a testament to this. Jerry is hard working and takes responsibility of the projects that he is involved with. I am sure that Jerry will be an important contributor to the Connections Committee.
|}
----

DOM based XSS Prevention Cheat Sheet

2011-08-08T21:09:39Z

Abraham Kang:

= Introduction =

When looking at XSS (Cross-Site Scripting), there are three generally recognized forms of [[XSS]]. [[XSS#Stored_and_Reflected_XSS_Attacks | Reflected, Stored]], and [[DOM Based XSS]]. The [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | XSS Prevention Cheatsheet]] does an excellent job of addressing Reflected and Stored XSS. This cheatsheet addresses DOM (Document Object Model) based XSS and is an extension (and assumes comprehension of) the [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | XSS Prevention Cheatsheet]].

In order to understand DOM based XSS, one needs to see the fundamental difference between reflected and stored XSS when compared to DOM based XSS. Reflected and Stored XSS exist in a higher level rendering context and DOM based XSS is primarily found in a lower level execution context. A rendering context is associated with the parsing of HTML tags and their attributes. The HTML parser of the rendering context dictates how data is presented and laid out on the page and can be further broken down into the standard contexts of HTML, HTML attribute, URL, and CSS. The JavaScript or VBScript parser of an execution context is associated with the parsing and execution of script code. Each parser has distinct and separate semantics in the way they can possibly execute script code (XSS) which make creating consistent rules for mitigating both rendering and execution based contexts difficult. The complication is compounded by the differing meanings and treatment of encoded values within each subcontext (HTML, HTML attribute, URL, and CSS) within the execution context.

This paper refers to the HTML, HTML attribute, URL, and CSS Cheatsheet contexts as subcontexts because each of these contexts can be reached and set within a JavaScript execution context. In JavaScript code, the main context is JavaScript but since an attacker can try to attack the other 4 contexts using equivalent JavaScript DOM methods, we refer to the other contexts besides the JavaScript context as subcontexts. 

The following is an example of an attack which occurs in the JavaScript context and HTML subcontext: 

<code>
<script>
var x = ‘<%= taintedVar %>’;
var d = document.createElement(‘div’);
d.innerHTML = x;
document.body.appendChild(d);
</script>
</code>

One consistency, however, is the need to JavaScript encode in addition to the encoding required for the subcontext in the execution context. Let’s look at the individual subcontexts of the execution context in turn.

= HTML Subcontext within the Execution Context =

There are several methods and attributes which can be used to directly render HTML content within JavaScript. These methods constitute the HTML Subcontext within the Execution Context.

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

==Methods==
<code>
document.write(“<HTML> Tags and markup”);
document.writeln(“<HTML> Tags and markup”);
</code>

==Guideline==
In a pure HTML execution context (not HTML Attribute) use HTML and JavaScript encoding to mitigate against attacks.
<code>
element.innerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
element.outerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
</code>

==Methods==
<code>
document.write(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);
document.writeln(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);
</code>

= HTML Attribute Subcontext within the Execution Context =

The HTML attribute Subcontext within the Execution context is divergent from the standard encoding rules. This is because the rule to HTML attribute encode in an HTML attribute rendering context is mitigating attacks which try to exit out of the attribute to add additional attributes and/or tags which could have executable code. When you are in a DOM execution context you only need to JavaScript encode HTML attributes which do not execute code (attributes other than event handler, CSS, and URL attributes).

For example, the general rule is to HTML Attribute encode untrusted data (data from the database, http request, user, backend 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.

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

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.

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

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.

= 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.

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

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.

=CSS Attribute Subcontext within the Execution Context=

Normally executing JavaScript from a CSS context required either passing <code>javascript:attackCode()</code> 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.

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

TODO: We have not been able to get the expression() function working from DOM JavaScript code. Need some help.

=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.

<code>
var x = document.createElement("a");
x.href="#”;
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);
</code>

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. 

<code>

<a id="bb" href="#" onclick="\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0029"> Test Me</a>
</code>

An alternative to using Element.setAttribute(...) to set DOM attributes is to set the attribute directly. Directly setting event handler attributes will allow JavaScript encoding to mitigate against DOM based XSS. 

<code>
<a id="bb" href="#"> Test Me</a>
</code>
<code>
//The following does NOT work because the event handler is being set to a string. "alert(7)" is JavaScript encoded.
document.getElementById("bb").onclick = "\u0061\u006c\u0065\u0072\u0074\u0028\u0037\u0029";

//The following does NOT work because the event handler is being set to a string.
document.getElementById("bb").onmouseover = "testIt";

//The following does NOT work because of the encoded "(" and ")". "alert(77)" is JavaScript encoded.
document.getElementById("bb").onmouseover = \u0061\u006c\u0065\u0072\u0074\u0028\u0037\u0037\u0029;

//The following does NOT work because of the encoded ";". "testIt;testIt" is JavaScript encoded.
document.getElementById("bb").onmouseover = \u0074\u0065\u0073\u0074\u0049\u0074\u003b\u0074\u0065\u0073\u0074\u0049\u0074;

//The following DOES WORK because the encoded value is a valid variable name or function reference. "testIt" is JavaScript encoded
document.getElementById("bb").onmouseover = \u0074\u0065\u0073\u0074\u0049\u0074;

function testIt() {

alert("I was called.");
}

</code>

There are other places in JavaScript where JavaScript encoding is accepted as valid executable code. 

<code>
for ( var \u0062=0; \u0062 < 10; \u0062++){
\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074
.\u0077\u0072\u0069\u0074\u0065\u006c\u006e
("\u0048\u0065\u006c\u006c\u006f\u0020\u0057\u006f\u0072\u006c\u0064");
}
\u0077\u0069\u006e\u0064\u006f\u0077
.\u0065\u0076\u0061\u006c
\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074
.\u0077\u0072\u0069\u0074\u0065(111111111));
</code>

or

<code>
var s = "\u0065\u0076\u0061\u006c";
var t = "\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029";
window[s](t);
</code>

Because JavaScript is based on an international standard (ECMAScript), JavaScript encoding enables the support of international characters in programming constructs and variables in addition to alternate string representations (string escapes).

However the opposite is the case with HTML encoding. HTML tag elements are well defined and do not support alternate representations of the same tag. So HTML encoding cannot be used to allow the developer to have alternate representations of the <code><a></code> tag for example.

==HTML Encoding’s Disarming Nature==

In general, HTML encoding serves to castrate HTML tags which are placed in HTML and HTML attribute contexts.
Working example (no HTML encoding):

<code>
<a href=”…” >
</code>

Normally encoded example (Does Not Work – DNW):

<code>
&#x3c;a href=… &#x3e;
</code>

HTML encoded example to highlight a fundamental difference with JavaScript encoded values (DNW):

<code>
<&#x61; href=…>
</code>

If HTML encoding followed the same semantics as JavaScript encoding. The line above could have possibily worked to render a link. This difference makes JavaScript encoding a less viable weapon in our fight against XSS.

=Guidelines for Developing Secure Applications Utilizing JavaScript=

DOM based XSS is extremely difficult to mitigate against because of its large attack surface and lack of standardization across browsers. The guidelines below are an attempt to provide guidelines for developers when developing Web based JavaScript applications (Web 2.0) such that they can avoid XSS.

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) 
<code>
var x = “<%=encodedJavaScriptData%>”;
</code>
3. Use <code>document.createElement(“…”), element.setAttribute(“…”,”value”), element.appendChild(…)</code>, etc. to build dynamic interfaces. Avoid use of HTML rendering methods: 
#<code>element.innerHTML = “…”; </code>
#<code>element.outerHTML = “…”; </code>
#<code>document.write(…); </code>
#<code>document.writeln(…); </code> 
4. Understand the dataflow of untrusted data through your JavaScript code. If you do have to use the methods above remember to HTML and them JavaScript encode the untrusted data (Stefano Di Paola). 
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. 

Utilizing an Enclosure (as suggested by Gaz)

The example that follows illustrates using closures to avoid double JavaScript encoding.

<code>
setTimeout((function(param) { return function() {
customFunction(param);
}
})("<%=Encoder.encodeForJS(untrustedData)%>"), y);
</code>

The other alternative is using N-levels of encoding. 

N-Levels of Encoding 

If your code looked like the following, you would need to only double JavaScript encode input data.

<code>
setTimeout(“customFunction(‘<%=doubleJavaScriptEncodedData%>’, y)”);
function customFunction (firstName, lastName)
alert("Hello" + firstName + " " + lastNam);
}
</code>

The <code>doubleJavaScriptEncodedData</code> has its first layer of JavaScript encoding reversed (upon execution) in the single quotes. Then the implicit <code>eval()</code> of <code>setTimeout()</code> reverses another layer of JavaScript encoding to pass the correct value to <code>customFunction</code>. The reason why you only need to double JavaScript encode is that the <code>customFunction</code> function did not itself pass the input to another method which implicitly or explicitly called <code>eval()</code>. If "firstName" was passed to another JavaScript method which implicitly or explicitly called eval() then <code><%=doubleJavaScriptEncodedData%></code> above would need to be changed to <code><%=tripleJavaScriptEncodedData%></code>. 

An important implementation note is that if the JavaScript code tries to utilize the double or triple encoded data in string comparisons, the value may be interpreted as different values based on the number of evals() the data has passed through before being passed to the if comparison and the number of times the value was JavaScript encoded. 

If "A" is double JavaScript encoded then the following if check will return false. 

<code>
var x = "doubleJavaScriptEncodedA"; //\u005c\u0075\u0030\u0030\u0034\u0031
if (x == "A") {
alert("x is A");
} else if (x == "\u0041") {
alert("This is what pops");
}
</code>

This brings up an interesting design point. Ideally, the correct way to apply encoding and avoid the problem stated above is to server-side encode for the output context where data is introduced into the application. Then client-side encode (using a JavaScript encoding library such as ESAPI4JS) for the individual subcontext (DOM methods) which untrusted data is passed to. ESAPI4JS (located at http://bit.ly/9hRTLH) 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. 
Here are some examples of how they are used: 
<code>
var input = “<%=Encoder.encodeForJS(untrustedData)%>”; //server-side encoding
</code>
<code>
window.location = ESAPI4JS.encodeForURL(input); //URL encoding is happening in JavaScript
</code>
<code>
document.writeln(ESAPI4JS.encodeForHTML(input)); //HTML encoding is happening in JavaScript
</code>

It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers. One option is to wait till ECMAScript 5 so the JavaScript library could support immutable properties. 
Another option provided by Gaz (Gareth) was to use a specific code construct to limit mutability with anonymous clousures. 

An example follows: 

<code>
function escapeHTML(str) {
str = str + "''";
var out = "''";
for(var i=0; i<str.length; i++) {
if(str[i] === '<') {
out += '&lt;';
} else if(str[i] === '>') {
out += '&gt;';
} else if(str[i] === "'") {
out += '&#39;';
} else if(str[i] === '"') {
out += '&quot;';
} else {
out += str[i];
}
}
return out;
}
</code>

 Chris Schmidt has put together another implementation of a JavaScript encoder at http://yet-another-dev.blogspot.com/2011/02/client-side-contextual-encoding-for.html. 

6. Limit the usage of dynamic untrusted data to right side operations. And be aware of data which may be passed to the application which look like code (eg. <code>location</code>, <code>eval()</code>). (Achim) 
<code>
var x = “<%=properly encoded data for flow%>”;
</code>

If you want to change different object attributes based on user input use a level of indirection. 

Instead of: 

<code>
window[userData] = “moreUserData”;
</code>

Do the following instead: 
<code>
if (userData===”location”) {
window.location = “static/path/or/properly/url/encoded/value”;
}
</code>

7. When URL encoding in DOM be aware of character set issues as the character set in JavaScript DOM is not clearly defined (Mike Samuel). 

8. Limit access to properties objects when using object[x] accessors. (Mike Samuel). In other words use a level of indirection between untrusted input and specified object properties. 
Here is an example of the problem when using map types: 
<code>
var myMapType = {};
myMapType[<%=untrustedData%>] = “moreUntrustedData”;
</code>

Although the developer writing the code above was trying to add additional keyed elements to the <code>myMapType</code> object. This could be used by an attacker to subvert internal and external attributes of the <code>myMapType</code> object. 

9. Run your JavaScript in a ECMAScript 5 canopy or sand box to make it harder for your JavaScript API to be compromised (Gareth Heyes and John Stevens). 

10. Don’t <code>eval()</code> JSON to convert it to native JavaScript objects. Instead use <code>JSON.toJSON()</code> and <code>JSON.parse()</code> (Chris Schmidt).

= Common Problems Associated with Mitgating DOM Based XSS =
==Complex Contexts==
In many cases the context isn’t always strait forward to discern. 
<code>
<a href=”javascript:myFunction(‘<%=untrustedData%>’, 'test');”>Click Me</a>
...
<script>
Function myFunction (url,name) {
window.location = url;
}
</script>
</code>

In the above example, untrusted data started in the rendering URL context (<code>href</code> attribute of an <code><a></code> tag) then changed to a JavaScript execution context (<code>javascript:</code> protocol handler) which passed the untrusted data to an execution URL subcontext (<code>window.location</code> of myFunction). Because the data was introduced in JavaScript code and passed to a URL subcontext the appropriate server-side encoding would be the following: 

<code>
<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS( ↩
Encoder.encodeForURL(untrustedData))%>’, 'test');”>Click Me</a>
…
</code>

Or if you were using ECMAScript 5 with an immutable JavaScript client-side encoding libraries you could do the following: 

<code>

<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(untrustedData)%>’, 'test');”>Click Me</a>
...
<script>
Function myFunction (url,name) {
var encodedURL = ESAPI4JS.encodeForURL(url); //URL encoding using client-side scripts
window.location = encodedURL;
}
</script>
</code>

== Insonsistencies of Encoding Libraries ==
There are a number of open source encoding libraries out there: 

#ESAPI
#Apache Commons String Utils
#Jtidy
#Your company’s custom implementation.

Some work on a black list others ignore important characters like “<” and “>”. ESAPI is one of the few which work on a whitelist and encode all non-alpha numeric characters.
It is important to use an encoding library which understands which characters can be used to exploit vulnerabilies in their respective contexts.
But there are misconceptions abound related to proper encoding.

==Encoding Misconceptions==
Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of “text/xhtml” or the file type extension of “*.xhtml” then HML encoding may not work to mitigate against XSS. 

For example: 

<code>
<script>
&#x61;lert(1);
</script>
</code>

The HTML encoded value above is still executable. If that isn’t enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element. 

Let’s look at the sample page and script: 

<code>
<form name=”myForm” …>
<input type=”text” name=”lName” value=”<%=Encoder.encodeForHTML(last_name)%>”>
…
</form>
<script>
var x = document.myForm.lName.value; //when the value is retrieved the encoding is reversed
document.writeln(x); //any code passed into lName is now executable.
</script>
</code>

Finally there is the problem that certain methods in JavaScript which are usually safe can be unsafe in certain contexts. 

==Usually Safe Methods==

One example of an attribute which is usually safe is innerText. Some papers or guides advocate its use as an alternative to innerHTML to mitigate against XSS in innerHTML. However, depending on the tag which innerText is applied, code can be executed. 

<code>
<script>
var tag = document.createElement(“script”);
tag.innerText = “<%=untrustedData%>”; //executes code
</script>
</code>

 

= Authors and Contributing Editors =

Jim Manico - jim[at]owasp.org

Abraham Kang - abraham.kang[at]owasp.org

Gareth (Gaz) Heyes

Stefano Di Paola

[[User:Achim| Achim Hoffmann]] [mailto:achim@owasp.org| achim_@_owasp.org]

Robert (RSnake) Hansen

Mario Heiderich

John Stevens

Chris (Chris BEF) Schmidt

Mike Samuel

Jeremy Long

Edwardo (SirDarkCat) Alberto Vela Nava

Jeff Williams - jeff.williams[at]owasp.org

Erlend Oftedal

{{Cheatsheet_Navigation}}

[[Category:How To]]

[[Category:Cheatsheets]]

DOM based XSS Prevention Cheat Sheet

2011-05-06T07:04:07Z

Abraham Kang:

= Introduction =

When looking at XSS (Cross-Site Scripting), there are three generally recognized forms of [[XSS]]. [[XSS#Stored_and_Reflected_XSS_Attacks | Reflected, Stored]], and [[DOM Based XSS]]. The [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | XSS Prevention Cheatsheet]] does an excellent job of addressing Reflected and Stored XSS. This cheatsheet addresses DOM (Document Object Model) based XSS and is an extension (and assumes comprehension of) the [[XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet | XSS Prevention Cheatsheet]].

In order to understand DOM based XSS, one needs to see the fundamental difference between reflected and stored XSS when compared to DOM based XSS. Reflected and Stored XSS exist in a higher level rendering context and DOM based XSS is primarily found in a lower level execution context. A rendering context is associated with the parsing of HTML tags and their attributes. The HTML parser of the rendering context dictates how data is presented and laid out on the page and can be further broken down into the standard contexts of HTML, HTML attribute, URL, and CSS. The JavaScript or VBScript parser of an execution context is associated with the parsing and execution of script code. Each parser has distinct and separate semantics in the way they can possibly execute script code (XSS) which make creating consistent rules for mitigating both rendering and execution based contexts difficult. The complication is compounded by the differing meanings and treatment of encoded values within each subcontext (HTML, HTML attribute, URL, and CSS) within the execution context.

This paper refers to the HTML, HTML attribute, URL, and CSS Cheatsheet contexts as subcontexts because each of these contexts can be reached and set within a JavaScript execution context. In JavaScript code, the main context is JavaScript but since an attacker can try to attack the other 4 contexts using equivalent JavaScript DOM methods, we refer to the other contexts besides the JavaScript context as subcontexts. 

The following is an example of an attack which occurs in the JavaScript context and HTML subcontext: 

<code>
<script>
var x = ‘<%= htmlAndJavaScriptEncodedVar %>’;
var d = document.createElement(‘div’);
d.innerHTML = x;
document.body.appendChild(d);
</script>
</code>

One consistency, however, is the need to JavaScript encode in addition to the encoding required for the subcontext in the execution context. Let’s look at the individual subcontexts of the execution context in turn.

= HTML Subcontext within the Execution Context =

There are several methods and attributes which can be used to directly render HTML content within JavaScript. These methods constitute the HTML Subcontext within the Execution Context.

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

==Methods==
<code>
document.write(“<HTML> Tags and markup”);
document.writeln(“<HTML> Tags and markup”);
</code>

==Guideline==
In a pure HTML execution context (not HTML Attribute) use HTML and JavaScript encoding to mitigate against attacks.
<code>
element.innerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
element.outerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
</code>

==Methods==
<code>
document.write(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);
document.writeln(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);
</code>

= HTML Attribute Subcontext within the Execution Context =

The HTML attribute Subcontext within the Execution context is divergent from the standard encoding rules. This is because the rule to HTML attribute encode in an HTML attribute rendering context is mitigating attacks which try to exit out of the attribute to add additional attributes and/or tags which could have executable code. When you are in a DOM execution context you only need to JavaScript encode HTML attributes which do not execute code (attributes other than event handler, CSS, and URL attributes).

For example, the general rule is to HTML Attribute encode untrusted data (data from the database, http request, user, backend 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.

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

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.

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

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.

= 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.

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

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.

=CSS Attribute Subcontext within the Execution Context=

Normally executing JavaScript from a CSS context required either passing <code>javascript:attackCode()</code> 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.

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

TODO: We have not been able to get the expression() function working from DOM JavaScript code. Need some help.

=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.

<code>
var x = document.createElement("a");
x.href="#”;
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);
</code>

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. 

<code>

<a id="bb" href="#" onclick="\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0029"> Test Me</a>
</code>

An alternative to using Element.setAttribute(...) to set DOM attributes is to set the attribute directly. Directly setting event handler attributes will allow JavaScript encoding to mitigate against DOM based XSS. 

<code>
<a id="bb" href="#"> Test Me</a>
</code>
<code>
//The following does NOT work because the event handler is being set to a string. "alert(7)" is JavaScript encoded.
document.getElementById("bb").onclick = "\u0061\u006c\u0065\u0072\u0074\u0028\u0037\u0029";

//The following does NOT work because the event handler is being set to a string.
document.getElementById("bb").onmouseover = "testIt";

//The following does NOT work because of the encoded "(" and ")". "alert(77)" is JavaScript encoded.
document.getElementById("bb").onmouseover = \u0061\u006c\u0065\u0072\u0074\u0028\u0037\u0037\u0029;

//The following does NOT work because of the encoded ";". "testIt;testIt" is JavaScript encoded.
document.getElementById("bb").onmouseover = \u0074\u0065\u0073\u0074\u0049\u0074\u003b\u0074\u0065\u0073\u0074\u0049\u0074;

//The following DOES WORK because the encoded value is a valid variable name or function reference. "testIt" is JavaScript encoded
document.getElementById("bb").onmouseover = \u0074\u0065\u0073\u0074\u0049\u0074;

function testIt() {

alert("I was called.");
}

</code>

There are other places in JavaScript where JavaScript encoding is accepted as valid executable code. 

<code>
for ( var \u0062=0; \u0062 < 10; \u0062++){
\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074
.\u0077\u0072\u0069\u0074\u0065\u006c\u006e
("\u0048\u0065\u006c\u006c\u006f\u0020\u0057\u006f\u0072\u006c\u0064");
}
\u0077\u0069\u006e\u0064\u006f\u0077
.\u0065\u0076\u0061\u006c
\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074
.\u0077\u0072\u0069\u0074\u0065(111111111));
</code>

or

<code>
var s = "\u0065\u0076\u0061\u006c";
var t = "\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029";
window[s](t);
</code>

Because JavaScript is based on an international standard (ECMAScript), JavaScript encoding enables the support of international characters in programming constructs and variables in addition to alternate string representations (string escapes).

However the opposite is the case with HTML encoding. HTML tag elements are well defined and do not support alternate representations of the same tag. So HTML encoding cannot be used to allow the developer to have alternate representations of the <code><a></code> tag for example.

==HTML Encoding’s Disarming Nature==

In general, HTML encoding serves to castrate HTML tags which are placed in HTML and HTML attribute contexts.
Working example (no HTML encoding):

<code>
<a href=”…” >
</code>

Normally encoded example (Does Not Work – DNW):

<code>
&#x3c;a href=… &#x3e;
</code>

HTML encoded example to highlight a fundamental difference with JavaScript encoded values (DNW):

<code>
<&#x61; href=…>
</code>

If HTML encoding followed the same semantics as JavaScript encoding. The line above could have possibily worked to render a link. This difference makes JavaScript encoding a less viable weapon in our fight against XSS.

=Guidelines for Developing Secure Applications Utilizing JavaScript=

DOM based XSS is extremely difficult to mitigate against because of its large attack surface and lack of standardization across browsers. The guidelines below are an attempt to provide guidelines for developers when developing Web based JavaScript applications (Web 2.0) such that they can avoid XSS.

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) 
<code>
var x = “<%=encodedJavaScriptData%>”;
</code>
3. Use <code>document.createElement(“…”), element.setAttribute(“…”,”value”), element.appendChild(…)</code>, etc. to build dynamic interfaces. Avoid use of HTML rendering methods: 
#<code>element.innerHTML = “…”; </code>
#<code>element.outerHTML = “…”; </code>
#<code>document.write(…); </code>
#<code>document.writeln(…); </code> 
4. Understand the dataflow of untrusted data through your JavaScript code. If you do have to use the methods above remember to HTML and them JavaScript encode the untrusted data (Stefano Di Paola). 
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. 

Utilizing an Enclosure (as suggested by Gaz)

The example that follows illustrates using closures to avoid double JavaScript encoding.

<code>
setTimeout((function(param) { return function() {
customFunction(param);
}
})("<%=Encoder.encodeForJS(untrustedData)%>"), y);
</code>

The other alternative is using N-levels of encoding. 

N-Levels of Encoding 

If your code looked like the following, you would need to only double JavaScript encode input data.

<code>
setTimeout(“customFunction(‘<%=doubleJavaScriptEncodedData%>’, y)”);
function customFunction (firstName, lastName)
alert("Hello" + firstName + " " + lastNam);
}
</code>

The <code>doubleJavaScriptEncodedData</code> has its first layer of JavaScript encoding reversed (upon execution) in the single quotes. Then the implicit <code>eval()</code> of <code>setTimeout()</code> reverses another layer of JavaScript encoding to pass the correct value to <code>customFunction</code>. The reason why you only need to double JavaScript encode is that the <code>customFunction</code> function did not itself pass the input to another method which implicitly or explicitly called <code>eval()</code>. If "firstName" was passed to another JavaScript method which implicitly or explicitly called eval() then <code><%=doubleJavaScriptEncodedData%></code> above would need to be changed to <code><%=tripleJavaScriptEncodedData%></code>. 

An important implementation note is that if the JavaScript code tries to utilize the double or triple encoded data in string comparisons, the value may be interpreted as different values based on the number of evals() the data has passed through before being passed to the if comparison and the number of times the value was JavaScript encoded. 

If "A" is double JavaScript encoded then the following if check will return false. 

<code>
var x = "doubleJavaScriptEncodedA"; //\u005c\u0075\u0030\u0030\u0034\u0031
if (x == "A") {
alert("x is A");
} else if (x == "\u0041") {
alert("This is what pops");
}
</code>

This brings up an interesting design point. Ideally, the correct way to apply encoding and avoid the problem stated above is to server-side encode for the output context where data is introduced into the application. Then client-side encode (using a JavaScript encoding library such as ESAPI4JS) for the individual subcontext (DOM methods) which untrusted data is passed to. ESAPI4JS (located at http://bit.ly/9hRTLH) 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. 
Here are some examples of how they are used: 
<code>
var input = “<%=Encoder.encodeForJS(untrustedData)%>”; //server-side encoding
</code>
<code>
window.location = ESAPI4JS.encodeForURL(input); //URL encoding is happening in JavaScript
</code>
<code>
document.writeln(ESAPI4JS.encodeForHTML(input)); //HTML encoding is happening in JavaScript
</code>

It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers. One option is to wait till ECMAScript 5 so the JavaScript library could support immutable properties. 
Another option provided by Gaz (Gareth) was to use a specific code construct to limit mutability with anonymous clousures. 

An example follows: 

<code>
function escapeHTML(str) {
str = str + "''";
var out = "''";
for(var i=0; i<str.length; i++) {
if(str[i] === '<') {
out += '&lt;';
} else if(str[i] === '>') {
out += '&gt;';
} else if(str[i] === "'") {
out += '&#39;';
} else if(str[i] === '"') {
out += '&quot;';
} else {
out += str[i];
}
}
return out;
}
</code>

 Chris Schmidt has put together another implementation of a JavaScript encoder at http://yet-another-dev.blogspot.com/2011/02/client-side-contextual-encoding-for.html. 

6. Limit the usage of dynamic untrusted data to right side operations. And be aware of data which may be passed to the application which look like code (eg. <code>location</code>, <code>eval()</code>). (Achim) 
<code>
var x = “<%=properly encoded data for flow%>”;
</code>

If you want to change different object attributes based on user input use a level of indirection. 

Instead of: 

<code>
window[userData] = “moreUserData”;
</code>

Do the following instead: 
<code>
if (userData===”location”) {
window.location = “static/path/or/properly/url/encoded/value”;
}
</code>

7. When URL encoding in DOM be aware of character set issues as the character set in JavaScript DOM is not clearly defined (Mike Samuel). 

8. Limit access to properties objects when using object[x] accessors. (Mike Samuel). In other words use a level of indirection between untrusted input and specified object properties. 
Here is an example of the problem when using map types: 
<code>
var myMapType = {};
myMapType[<%=untrustedData%>] = “moreUntrustedData”;
</code>

Although the developer writing the code above was trying to add additional keyed elements to the <code>myMapType</code> object. This could be used by an attacker to subvert internal and external attributes of the <code>myMapType</code> object. 

9. Run your JavaScript in a ECMAScript 5 canopy or sand box to make it harder for your JavaScript API to be compromised (Gareth Heyes and John Stevens). 

10. Don’t <code>eval()</code> JSON to convert it to native JavaScript objects. Instead use <code>JSON.toJSON()</code> and <code>JSON.parse()</code> (Chris Schmidt).

= Common Problems Associated with Mitgating DOM Based XSS =
==Complex Contexts==
In many cases the context isn’t always strait forward to discern. 
<code>
<a href=”javascript:myFunction(‘<%=untrustedData%>’, 'test');”>Click Me</a>
...
<script>
Function myFunction (url,name) {
window.location = url;
}
</script>
</code>

In the above example, untrusted data started in the rendering URL context (<code>href</code> attribute of an <code><a></code> tag) then changed to a JavaScript execution context (<code>javascript:</code> protocol handler) which passed the untrusted data to an execution URL subcontext (<code>window.location</code> of myFunction). Because the data was introduced in JavaScript code and passed to a URL subcontext the appropriate server-side encoding would be the following: 

<code>
<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS( ↩
Encoder.encodeForURL(untrustedData))%>’, 'test');”>Click Me</a>
…
</code>

Or if you were using ECMAScript 5 with an immutable JavaScript client-side encoding libraries you could do the following: 

<code>

<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(untrustedData)%>’, 'test');”>Click Me</a>
...
<script>
Function myFunction (url,name) {
var encodedURL = ESAPI4JS.encodeForURL(url); //URL encoding using client-side scripts
window.location = encodedURL;
}
</script>
</code>

== Insonsistencies of Encoding Libraries ==
There are a number of open source encoding libraries out there: 

#ESAPI
#Apache Commons String Utils
#Jtidy
#Your company’s custom implementation.

Some work on a black list others ignore important characters like “<” and “>”. ESAPI is one of the few which work on a whitelist and encode all non-alpha numeric characters.
It is important to use an encoding library which understands which characters can be used to exploit vulnerabilies in their respective contexts.
But there are misconceptions abound related to proper encoding.

==Encoding Misconceptions==
Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of “text/xhtml” or the file type extension of “*.xhtml” then HML encoding may not work to mitigate against XSS. 

For example: 

<code>
<script>
&#x61;lert(1);
</script>
</code>

The HTML encoded value above is still executable. If that isn’t enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element. 

Let’s look at the sample page and script: 

<code>
<form name=”myForm” …>
<input type=”text” name=”lName” value=”<%=Encoder.encodeForHTML(last_name)%>”>
…
</form>
<script>
var x = document.myForm.lName.value; //when the value is retrieved the encoding is reversed
document.writeln(x); //any code passed into lName is now executable.
</script>
</code>

Finally there is the problem that certain methods in JavaScript which are usually safe can be unsafe in certain contexts. 

==Usually Safe Methods==

One example of an attribute which is usually safe is innerText. Some papers or guides advocate its use as an alternative to innerHTML to mitigate against XSS in innerHTML. However, depending on the tag which innerText is applied, code can be executed. 

<code>
<script>
var tag = document.createElement(“script”);
tag.innerText = “<%=untrustedData%>”; //executes code
</script>
</code>

 

= Authors and Contributing Editors =

Jim Manico - jim[at]owasp.org

Abraham Kang - abraham.kang[at]owasp.org

Gareth (Gaz) Heyes

Stefano Di Paola

[[User:Achim| Achim Hoffmann]] [mailto:achim@owasp.org| achim_@_owasp.org]

Robert (RSnake) Hansen

Mario Heiderich

John Stevens

Chris (Chris BEF) Schmidt

Mike Samuel

Jeremy Long

Edwardo (SirDarkCat) Alberto Vela Nava

Jeff Williams - jeff.williams[at]owasp.org

Erlend Oftedal

{{Cheatsheet_Navigation}}

[[Category:How To]]

[[Category:Cheatsheets]]

DOM based XSS Prevention Cheat Sheet

2011-03-11T07:23:16Z

Abraham Kang:

= Introduction =

When looking at XSS (Cross Site Scripting) there are three generally recognized forms of XSS. Reflected, Persisted, and DOM based XSS. The [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] has done an excellent job of addressing Reflected and Persisted XSS. This cheatsheet will address DOM (Document Object Model) based XSS and is an extension (as assumes comprehension of) the the [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] .

In order to understand DOM based XSS one needs to see the fundamental difference between reflected and persisted XSS when compared to DOM based XSS. Reflected and persisted XSS exist in a higher level rendering context and DOM based XSS is primarily found in a lower level execution context. A rendering context is associated with the parsing of HTML tags and their attributes. The HTML parser of the rendering context dictates how data is presented and laid out on the page and can be further broken down into the standard contexts of HTML, HTML attribute, URL, and CSS. The JavaScript or VBScript parser of an execution context is associated with the parsing and execution of script code. Each parser has distinct and separate semantics in the way they can possibly execute script code (XSS) which make creating consistent rules for mitigating both rendering and execution based contexts difficult. The complication is compounded by the differing meanings and treatment of encoded values within each sub context (HTML, HTML attribute, URL, and CSS) within the execution context.

This paper refers to the HTML, HTML attribute, URL, and CSS Cheatsheet contexts as subcontexts because each of these contexts can be reached and set within a JavaScript execution context. In JavaScript code the main context is JavaScript but since an attacker can try to attack the other 4 contexts using equivalent JavaScript DOM methods we refer to the other contexts besides the JavaScript context as sub contexts. 

The following example of an attack which occurs in the JavaScript context and HTML sub context: 

<code>
<script>
var x = ‘<%= htmlAndJavaScriptEncodedVar %>’;
var d = document.createElement(‘div’);
d.innerHTML = x;
document.body.appendChild(d);
</script>
</code>

One consistency, however, is the need to JavaScript encode in addition to the encoding required for the sub context in the execution context. Let’s look at the individual sub contexts of the execution context in turn.

= HTML Sub Context within the Execution Context =

There are several methods and attributes which can be used to directly render HTML content within JavaScript. These methods constitute the HTML Sub Context within the Execution Context.

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

==Methods==
<code>
document.write(“<HTML> Tags and markup”);
document.writeln(“<HTML> Tags and markup”);
</code>

==Guideline==
In a pure HTML execution context (not HTML Attribute) use HTML and JavaScript encoding to mitigate against attacks.
<code>
element.innerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
element.outerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
</code>

==Methods==
<code>
document.write(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);
document.writeln(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);
</code>

= HTML Attribute Sub Context within the Execution Context =

The HTML attribute Sub Context within the Execution context is divergent from the standard encoding rules. This is because the rule to HTML attribute encode in an HTML attribute rendering context is mitigating attacks which try to exit out of the attribute to add additional attributes and/or tags which could have executable code. When you are in a DOM execution context you only need to JavaScript encode HTML attributes which do not execute code (attributes other than event handler, CSS, and URL attributes).

For example, the general rule is to HTML Attribute encode untrusted data (data from the database, http request, user, backend 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.

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

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.

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

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.

= URL Attribute Sub Context 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.

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

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.

=CSS Attribute Sub Context within the Execution Context=

Normally executing JavaScript from a CSS context required either passing <code>javascript:attackCode()</code> 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.

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

TODO: We have not been able to get the expression() function working from DOM JavaScript code. Need some help.

=Event Handler and JavaScript code Sub Contexts 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.

<code>
var x = document.createElement("a");
x.href="#”;
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);
</code>

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. 

<code>

<a id="bb" href="#" onclick="\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0029"> Test Me</a>
</code>

An alternative to using Element.setAttribute(...) to set DOM attributes is to set the attribute directly. Directly setting event handler attributes will allow JavaScript encoding to mitigate against DOM based XSS. 

<code>
<a id="bb" href="#"> Test Me</a>
</code>
<code>
//The following does NOT work because the event handler is being set to a string. "alert(7)" is JavaScript encoded.
document.getElementById("bb").onclick = "\u0061\u006c\u0065\u0072\u0074\u0028\u0037\u0029";

//The following does NOT work because the event handler is being set to a string.
document.getElementById("bb").onmouseover = "testIt";

//The following does NOT work because of the encoded "(" and ")". "alert(77)" is JavaScript encoded.
document.getElementById("bb").onmouseover = \u0061\u006c\u0065\u0072\u0074\u0028\u0037\u0037\u0029;

//The following does NOT work because of the encoded ";". "testIt;testIt" is JavaScript encoded.
document.getElementById("bb").onmouseover = \u0074\u0065\u0073\u0074\u0049\u0074\u003b\u0074\u0065\u0073\u0074\u0049\u0074;

//The following DOES WORK because the encoded value is a valid variable name or function reference. "testIt" is JavaScript encoded
document.getElementById("bb").onmouseover = \u0074\u0065\u0073\u0074\u0049\u0074;

function testIt() {

alert("I was called.");
}

</code>

There are other places in JavaScript where JavaScript encoding is accepted as valid executable code. 

<code>
for ( var \u0062=0; \u0062 < 10; \u0062++){
\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074
.\u0077\u0072\u0069\u0074\u0065\u006c\u006e
("\u0048\u0065\u006c\u006c\u006f\u0020\u0057\u006f\u0072\u006c\u0064");
}
\u0077\u0069\u006e\u0064\u006f\u0077
.\u0065\u0076\u0061\u006c
\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074
.\u0077\u0072\u0069\u0074\u0065(111111111));
</code>

or

<code>
var s = "\u0065\u0076\u0061\u006c";
var t = "\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029";
window[s](t);
</code>

Because JavaScript is based on an international standard (ECMAScript), JavaScript encoding enables the support of international characters in programming constructs and variables in addition to alternate string representations (string escapes).

However the opposite is the case with HTML encoding. HTML tag elements are well defined and do not support alternate representations of the same tag. So HTML encoding cannot be used to allow the developer to have alternate representations of the <code><a></code> tag for example.

==HTML Encoding’s Disarming Nature==

In general, HTML encoding serves to castrate HTML tags which are placed in HTML and HTML attribute contexts.
Working example (no HTML encoding):

<code>
<a href=”…” >
</code>

Normally encoded example (Does Not Work – DNW):

<code>
&#x3c;a href=… &#x3e;
</code>

HTML encoded example to highlight a fundamental difference with JavaScript encoded values (DNW):

<code>
<&#x61; href=…>
</code>

If HTML encoding followed the same semantics as JavaScript encoding. The line above could have possibily worked to render a link. This difference makes JavaScript encoding a less viable weapon in our fight against XSS.

=Guidelines for Developing Secure Applications Utilizing JavaScript=

DOM based XSS is extremely difficult to mitigate against because of its large attack surface and lack of standardization across browsers. The guidelines below are an attempt to provide guidelines for developers when developing Web based JavaScript applications (Web 2.0) such that they can avoid XSS.

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) 
<code>
var x = “<%=encodedJavaScriptData%>”;
</code>
3. Use <code>document.createElement(“…”), element.setAttribute(“…”,”value”), element.appendChild(…)</code>, etc. to build dynamic interfaces. Avoid use of HTML rendering methods: 
#<code>element.innerHTML = “…”; </code>
#<code>element.outerHTML = “…”; </code>
#<code>document.write(…); </code>
#<code>document.writeln(…); </code> 
4. Understand the dataflow of untrusted data through your JavaScript code. If you do have to use the methods above remember to HTML and them JavaScript encode the untrusted data (Stefano Di Paola). 
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. 

Utilizing an Enclosure (as suggested by Gaz)

The example that follows illustrates using closures to avoid double JavaScript encoding.

<code>
setTimeout((function(param) { return function() {
customFunction(param);
}
})("<%=Encoder.encodeForJS(untrustedData)%>"), y);
</code>

The other alternative is using N-levels of encoding. 

N-Levels of Encoding 

If your code looked like the following, you would need to only double JavaScript encode input data.

<code>
setTimeout(“customFunction(‘<%=doubleJavaScriptEncodedData%>’, y)”);
function customFunction (firstName, lastName)
alert("Hello" + firstName + " " + lastNam);
}
</code>

The <code>doubleJavaScriptEncodedData</code> has its first layer of JavaScript encoding reversed in the single quotes. Then the implicit <code>eval()</code> of <code>setTimeout()</code> reverses another layer of JavaScript encoding to pass the correct value to <code>customFunction</code>. The reason why you only need to double JavaScript encode is that the <code>customFunction</code> function did not itself pass the input to another method which implicitly or explicitly called <code>eval()</code>. If "firstName" was passed to another JavaScript method which implicitly or explicitly called eval() then <code><%=doubleJavaScriptEncodedData%></code> above would need to be changed to <code><%=tripleJavaScriptEncodedData%></code>. 

An important implementation note is that if the JavaScript code tries to utilize the double or triple encoded data in string comparisons, the value may be interpreted as different values based on the number of evals() the data has passed through before being passed to the if comparison and the number of times the value was JavaScript encoded. 

If "A" is double JavaScript encoded then the following if check will return false. 

<code>
var x = "doubleJavaScriptEncodedA"; //\u005c\u0075\u0030\u0030\u0034\u0031
if (x == "A") {
alert("x is A");
} else if (x == "\u0041") {
alert("This is what pops");
}
</code>

This brings up an interesting design point. Ideally, the correct way to apply encoding and avoid the problem stated above is to server-side encode for the output context where data is introduced into the application. Then client-side encode (using a JavaScript encoding library such as ESAPI4JS) for the individual sub context (DOM methods) which untrusted data is passed to. ESAPI4JS (located at http://bit.ly/9hRTLH) 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. 
Here are some examples of how they are used: 
<code>
var input = “<%=Encoder.encodeForJS(untrustedData)%>”; //server-side encoding
</code>
<code>
window.location = ESAPI4JS.encodeForURL(input); //URL encoding is happening in JavaScript
</code>
<code>
document.writeln(ESAPI4JS.encodeForHTML(input)); //HTML encoding is happening in JavaScript
</code>

It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers. One option is to wait till ECMAScript 5 so the JavaScript library could support immutable properties. 
Another option provided by Gaz (Gareth) was to use a specific code construct to limit mutability with anonymous clousures. 

An example follows: 

<code>
function escapeHTML(str) {
str = str + "''";
var out = "''";
for(var i=0; i<str.length; i++) {
if(str[i] === '<') {
out += '&lt;';
} else if(str[i] === '>') {
out += '&gt;';
} else if(str[i] === "'") {
out += '&#39;';
} else if(str[i] === '"') {
out += '&quot;';
} else {
out += str[i];
}
}
return out;
}
</code>

 Chris Schmidt has put together another implementation of a JavaScript encoder at http://yet-another-dev.blogspot.com/2011/02/client-side-contextual-encoding-for.html. 

6. Limit the usage of dynamic untrusted data to right side operations. And be aware of data which may be passed to the application which look like code (eg. <code>location</code>, <code>eval()</code>). (Achim) 
<code>
var x = “<%=properly encoded data for flow%>”;
</code>

If you want to change different object attributes based on user input use a level of indirection. 

Instead of: 

<code>
window[userData] = “moreUserData”;
</code>

Do the following instead: 
<code>
if (userData===”location”) {
window.location = “static/path/or/properly/url/encoded/value”;
}
</code>

7. When URL encoding in DOM be aware of character set issues as the character set in JavaScript DOM is not clearly defined (Mike Samuel). 

8. Limit access to properties objects when using object[x] accessors. (Mike Samuel). In other words use a level of indirection between untrusted input and specified object properties. 
Here is an example of the problem when using map types: 
<code>
var myMapType = {};
myMapType[<%=untrustedData%>] = “moreUntrustedData”;
</code>

Although the developer writing the code above was trying to add additional keyed elements to the <code>myMapType</code> object. This could be used by an attacker to subvert internal and external attributes of the <code>myMapType</code> object. 

9. Run your JavaScript in a ECMAScript 5 canopy or sand box to make it harder for your JavaScript API to be compromised (Gareth Heyes and John Stevens). 

10. Don’t <code>eval()</code> JSON to convert it to native JavaScript objects. Instead use <code>JSON.toJSON()</code> and <code>JSON.parse()</code> (Chris Schmidt).

= Common Problems Associated with Mitgating DOM Based XSS =
==Complex Contexts==
In many cases the context isn’t always strait forward to discern. 
<code>
<a href=”javascript:myFunction(‘<%=untrustedData%>’, 'test');”>Click Me</a>
...
<script>
Function myFunction (url,name) {
window.location = url;
}
</script>
</code>

In the above example, untrusted data started in the rendering URL context (<code>href</code> attribute of an <code><a></code> tag) then changed to a JavaScript execution context (<code>javascript:</code> protocol handler) which passed the untrusted data to an execution URL sub context (<code>window.location</code> of myFunction). Because the data was introduced in JavaScript code and passed to a URL sub context the appropriate server-side encoding would be the following: 

<code>
<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS( ↩
Encoder.encodeForURL(untrustedData))%>’, 'test');”>Click Me</a>
…
</code>

Or if you were using ECMAScript 5 with an immutable JavaScript client-side encoding libraries you could do the following: 

<code>

<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(untrustedData)%>’, 'test');”>Click Me</a>
...
<script>
Function myFunction (url,name) {
var encodedURL = ESAPI4JS.encodeForURL(url); //URL encoding using client-side scripts
window.location = encodedURL;
}
</script>
</code>

== Insonsistencies of Encoding Libraries ==
There are a number of open source encoding libraries out there: 

#ESAPI
#Apache Commons String Utils
#Jtidy
#Your company’s custom implementation.

Some work on a black list others ignore important characters like “<” and “>”. ESAPI is one of the few which work on a whitelist and encode all non-alpha numeric characters.
It is important to use an encoding library which understands which characters can be used to exploit vulnerabilies in their respective contexts.
But there are misconceptions abound related to proper encoding.
==Encoding Misconceptions==
Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of “text/xhtml” or the file type extension of “*.xhtml” then HML encoding may not work to mitigate against XSS. 

For example: 

<code>
<script>
&#x61;lert(1);
</script>
</code>

The HTML encoded value above is still executable. If that isn’t enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element. 

Let’s look at the sample page and script: 

<code>
<form name=”myForm” …>
<input type=”text” name=”lName” value=”<%=Encoder.encodeForHTML(last_name)%>”>
…
</form>
<script>
var x = document.myForm.lName.value; //when the value is retrived the encoding is reversed
document.writeln(x); //any code passed into lName is now executable.
</script>
</code>

Finally there is the problem that certain methods in JavaScript which are usually safe can be unsafe in certain contexts. 

==Usually Safe Methods==

One example of an attribute which is usually safe is innerText. Some papers or guides advocate its use as an alternative to innerHTML to mitigate against XSS in innerHTML. However, depending on the tag which innerText is applied, code can be executed. 

<code>
<script>
var tag = document.createElement(“script”);
tag.innerText = “<%=untrustedData%>”; //executes code
</script>
</code>

 

= Authors and Contributing Editors =

Jim Manico - jim[at]owasp.org

Abraham Kang - abraham.kang[at]owasp.org

Gareth (Gaz) Heyes

Stefano Di Paola

[[User:Achim| Achim Hoffmann]] [mailto:achim@owasp.org| achim_@_owasp.org]

Robert (RSnake) Hansen

Mario Heiderich

John Stevens

Chris (Chris BEF) Schmidt

Mike Samuel

Jeremy Long

Edwardo (SirDarkCat) Alberto Vela Nava

Jeff Williams - jeff.williams[at]owasp.org

Erlend Oftedal

{{Cheatsheet_Navigation}}

[[Category:How To]]

[[Category:Cheatsheets]]

DOM based XSS Prevention Cheat Sheet

2011-02-24T02:15:13Z

Abraham Kang:

= Introduction =

When looking at XSS (Cross Site Scripting) there are three generally recognized forms of XSS. Reflected, Persisted, and DOM based XSS. The [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] has done an excellent job of addressing Reflected and Persisted XSS. This cheatsheet will address DOM (Document Object Model) based XSS and is an extension (as assumes comprehension of) the the [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] .

In order to understand DOM based XSS one needs to see the fundamental difference between reflected and persisted XSS when compared to DOM based XSS. Reflected and persisted XSS exist in a higher level rendering context and DOM based XSS is primarily found in a lower level execution context. A rendering context is associated with the parsing of HTML tags and their attributes. The HTML parser of the rendering context dictates how data is presented and laid out on the page and can be further broken down into the standard contexts of HTML, HTML attribute, URL, and CSS. The JavaScript or VBScript parser of an execution context is associated with the parsing and execution of script code. Each parser has distinct and separate semantics in the way they can possibly execute script code (XSS) which make creating consistent rules for mitigating both rendering and execution based contexts difficult. The complication is compounded by the differing meanings and treatment of encoded values within each sub context (HTML, HTML attribute, URL, and CSS) within the execution context.

This paper refers to the HTML, HTML attribute, URL, and CSS Cheatsheet contexts as subcontexts because each of these contexts can be reached and set within a JavaScript execution context. In JavaScript code the main context is JavaScript but since an attacker can try to attack the other 4 contexts using equivalent JavaScript DOM methods we refer to the other contexts besides the JavaScript context as sub contexts. 

The following example of an attack which occurs in the JavaScript context and HTML sub context: 

<code>
<script>
var x = ‘<%= htmlAndJavaScriptEncodedVar %>’;
var d = document.createElement(‘div’);
d.innerHTML = x;
document.body.appendChild(d);
</script>
</code>

One consistency, however, is the need to JavaScript encode in addition to the encoding required for the sub context in the execution context. Let’s look at the individual sub contexts of the execution context in turn.

= HTML Sub Context within the Execution Context =

There are several methods and attributes which can be used to directly render HTML content within JavaScript. These methods constitute the HTML Sub Context within the Execution Context.

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

==Methods==
<code>
document.write(“<HTML> Tags and markup”);
document.writeln(“<HTML> Tags and markup”);
</code>

==Guideline==
In a pure HTML execution context (not HTML Attribute) use HTML and JavaScript encoding to mitigate against attacks.
<code>
element.innerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
element.outerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
</code>

==Methods==
<code>
document.write(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);
document.writeln(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);
</code>

= HTML Attribute Sub Context within the Execution Context =

The HTML attribute Sub Context within the Execution context is divergent from the standard encoding rules. This is because the rule to HTML attribute encode in an HTML attribute rendering context is mitigating attacks which try to exit out of the attribute to add additional attributes and/or tags which could have executable code. When you are in a DOM execution context you only need to JavaScript encode HTML attributes which do not execute code (attributes other than event handler, CSS, and URL attributes).

For example, the general rule is to HTML Attribute encode untrusted data (data from the database, http request, user, backend 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.

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

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.

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

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.

= URL Attribute Sub Context 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.

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

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.

=CSS Attribute Sub Context 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.

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

TODO: We have not been able to get the expression() function working from DOM JavaScript code. Need some help.

=Event Handler and JavaScript code Sub Contexts 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.

<code>
var x = document.createElement("a");
x.href="#”;
x.setAttribute("onclick", "\u0061\u006c\u0065\u0072\u0074\u0028\u0032\u0032\u0029");
var y = document.createTextNode("Click To Test");
x.appendChild(y);</code> 
document.body.appendChild(x);
</code>

JavaScript event handler methods are dangerous because they implicitly do an eval() on the data passed to the DOM attribute. There are other places in JavaScript where JavaScript encoding is accepted as valid executable code.

<code>
for ( var \u0062=0; \u0062 < 10; \u0062++){
\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074
.\u0077\u0072\u0069\u0074\u0065\u006c\u006e
("\u0048\u0065\u006c\u006c\u006f\u0020\u0057\u006f\u0072\u006c\u0064");
} </code> 
\u0077\u0069\u006e\u0064\u006f\u0077
.\u0065\u0076\u0061\u006c
\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074
.\u0077\u0072\u0069\u0074\u0065(111111111));
</code>

or

<code>
var s = "\u0065\u0076\u0061\u006c";
var t = "\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029";
window[s](t);
</code>

Because JavaScript is based on an international standard (ECMAScript), JavaScript encoding enables the support of international characters in programming constructs and variables in addition to alternate string representations (string escapes).

However the opposite is the case with HTML encoding. HTML tag elements are well defined and do not support alternate representations of the same tag. So HTML encoding cannot be used to allow the developer to have alternate representations of the <a> tag for example.

==HTML Encoding’s Disarming Nature==

In general, HTML encoding serves to castrate HTML tags which are placed in HTML and HTML attribute contexts.
Working example (no HTML encoding):

<code>
<a href=”…” >
</code>

Normally encoded example (Does Not Work – DNW):

<code>
&#x3c;a href=… &#x3e;
</code>

HTML encoded example to highlight a fundamental difference with JavaScript encoded values (DNW):

<code>
<&#x61; href=…>
</code>

If HTML encoding followed the same semantics as JavaScript encoding. The line above could have possibily worked to render a link. This difference makes JavaScript encoding a less viable weapon in our fight against XSS.

=Guidelines for Developing Secure Applications Utilizing JavaScript=

DOM based XSS is extremely difficult to mitigate against because of its large attack surface and lack of standardization across browsers. The guidelines below are an attempt to provide guidelines for developers when developing Web based JavaScript applications (Web 2.0) such that they can avoid XSS.

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) 
<code>
var x = “<%=encodedJavaScriptData%>”;
</code>
3. Use <code>document.createElement(“…”), element.setAttribute(“…”,”value”), element.appendChild(…)</code>, etc. to build dynamic interfaces. Avoid use of HTML rendering methods: 
#<code>element.innerHTML = “…”; </code>
#<code>element.outerHTML = “…”; </code>
#<code>document.write(…); </code>
#<code>document.writeln(…); </code> 
4. Understand the dataflow of untrusted data through your JavaScript code. If you do have to use the methods above remember to HTML and them JavaScript encode the untrusted data (Stefano Di Paola). 
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. 

Utilizing an Enclosure (as suggested by Gaz)

The example that follows illustrates using closures to avoid double JavaScript encoding.

<code>
setTimeout((function(param) { return function() {
customFunction(param);
}
})("<%=Encoder.encodeForJS(untrustedData)%>"), y);
</code>

The other alternative is using N-levels of encoding. 

N-Levels of Encoding 

If your code looked like the following, you would need to only double JavaScript encode input data.

<code>
setTimeout(“customFunction(‘<%=doubleJavaScriptEncodedData%>’, y)”);
function customFunction (firstName, lastName)
alert("Hello" + firstName + " " + lastNam);
}
</code>

The <code>doubleJavaScriptEncodedData</code> has its first layer of JavaScript encoding reversed in the single quotes. Then the implicit <code>eval()</code> of <code>setTimeout()</code> reverses another layer of JavaScript encoding to pass the correct value to <code>customFunction</code>. The reason why you only need to double JavaScript encode is that the <code>customFunction</code> function did not itself pass the input to another method which implicitly or explicitly called <code>eval()</code>. If "firstName" was passed to another JavaScript method which implicitly or explicitly called eval() then <code><%=doubleJavaScriptEncodedData%></code> above would need to be changed to <code><%=tripleJavaScriptEncodedData%></code>. 

An important implementation note is that if the JavaScript code tries to utilize the double or triple encoded data in string comparisons, the value may be interpreted as different values based on the number of evals() the data has passed through before being passed to the if comparison and the number of times the value was JavaScript encoded. 

If "A" is double JavaScript encoded then the following if check will return false. 

<code>
var x = "doubleJavaScriptEncodedA"; //\u005c\u0075\u0030\u0030\u0034\u0031
if (x == "A") {
alert("x is A");
} else if (x == "\u0041") {
alert("This is what pops");
}
</code>

This brings up an interesting design point. Ideally, the correct way to apply encoding and avoid the problem stated above is to server-side encode for the output context where data is introduced into the application. Then client-side encode (using a JavaScript encoding library such as ESAPI4JS) for the individual sub context (DOM methods) which untrusted data is passed to. ESAPI4JS (located at http://bit.ly/9hRTLH) 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. 
Here are some examples of how they are used: 
<code>
var input = “<%=Encoder.encodeForJS(untrustedData)%>”; //Server side encoding
</code>
<code>
window.location = ESAPI4JS.encodeForURL(input); //URL encoding is happening in JavaScript
</code>
<code>
document.writeln(ESAPI4JS.encodeForHTML(input)); //HTML encoding is happening in JavaScript
</code>

It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers. One option is to wait till ECMAScript 5 so the JavaScript library could support immutable properties. 
Another option provided by Gaz (Gareth) was to use a specific code construct to limit mutability with anonymous clousures. 

An example follows: 

<code>
function escapeHTML(str) {
str = str + "''";
var out = "''";
for(var i=0; i<str.length; i++) {
if(str[i] === '<') {
out += '&lt;';
} else if(str[i] === '>') {
out += '&gt;';
} else if(str[i] === "'") {
out += '&#39;';
} else if(str[i] === '"') {
out += '&quot;';
} else {
out += str[i];
}
}
return out;
}
</code>

 Chris Schmidt has put together another implementation of a JavaScript encoder at http://yet-another-dev.blogspot.com/2011/02/client-side-contextual-encoding-for.html. 

6. Limit the usage of dynamic untrusted data to right side operations. And be aware of data which may be passed to the application which look like code (eg. <code>location</code>, <code>eval()</code>). (Achim) 
<code>
var x = “<%=properly encoded data for flow%>”;
</code>

If you want to change different object attributes based on user input use a level of indirection. 

Instead of: 

<code>
window[userData] = “moreUserData”;
</code>

Do the following instead: 
<code>
if (userData===”location”) {
window.location = “static/path/or/properly/url/encoded/value”;
}
</code>

7. When URL encoding in DOM be aware of character set issues as the character set in JavaScript DOM is not clearly defined (Mike Samuel). 

8. Limit access to properties objects when using object[x] accessors. (Mike Samuel). In other words use a level of indirection between untrusted input and specified object properties. 
Here is an example of the problem when using map types: 
<code>
var myMapType = {};
myMapType[<%=untrustedData%>] = “moreUntrustedData”;
</code>

Although the developer writing the code above was trying to add additional keyed elements to the <code>myMapType</code> object. This could be used by an attacker to subvert internal and external attributes of the <code>myMapType</code> object. 

9. Run your JavaScript in a ECMAScript 5 canopy or sand box to make it harder for your JavaScript API to be compromised (Gareth Heyes and John Stevens). 

10. Don’t <code>eval()</code> JSON to convert it to native JavaScript objects. Instead use <code>JSON.toJSON()</code> and <code>JSON.parse()</code> (Chris Schmidt).

= Common Problems Associated with Mitgating DOM Based XSS =
==Complex Contexts==
In many cases the context isn’t always strait forward to discern. 
<code>
<a href=”javascript:myFunction(‘<%=untrustedData%>’, 'test');”>Click Me</a>
...
<script>
Function myFunction (url,name) {<
window.location = url;
}
</script>
</code>

In the above example, untrusted data started in the rendering URL context (<code>href</code> attribute of an <code><a></code> tag) then changed to a JavaScript execution context (<code>javascript:</code> protocol handler) which passed the untrusted data to an execution URL sub context (<code>window.location</code> of myFunction). Because the data was introduced in JavaScript code and passed to a URL sub context the appropriate server-side encoding would be the following: 

<code>
<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(Encoder.encodeForURL(untrustedData))%>’, 'test');”>Click Me</a>
…
</code>

Or if you were using ECMAScript 5 with an immutable JavaScript client-side encoding libraries you could do the following: 

<code>

<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(untrustedData)%>’, 'test');”>Click Me</a>
...
<script>
Function myFunction (url,name) {
var encodedURL = ESAPI4JS.encodeForURL(url); //URL encoding using client-side scripts
window.location = encodedURL;
}
</script>
</code>

== Insonsistencies of Encoding Libraries ==
There are a number of open source encoding libraries out there: 

#ESAPI
#Apache Commons String Utils
#Jtidy
#Your company’s custom implementation.

Some work on a black list others ignore important characters like “<” and “>”. ESAPI is one of the few which work on a whitelist and encode all non-alpha numeric characters.
It is important to use an encoding library which understands which characters can be used to exploit vulnerabilies in their respective contexts.
But there are misconceptions abound related to proper encoding.
==Encoding Misconceptions==
Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of “text/xhtml” or the file type extension of “*.xhtml” then HML encoding may not work to mitigate against XSS. 

For example: 

<code>
<script>
&#x61;lert(1);
</script>
</code>

The HTML encoded value above is still executable. If that isn’t enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element. 

Let’s look at the sample page and script: 

<code>
<form name=”myForm” …>
<input type=”text” name=”lName” value=”<%=Encoder.encodeForHTML(last_name)%>”>
…
</form>
<script>
var x = document.myForm.lName.value; //when the value is retrived the encoding is reversed
document.writeln(x); //any code passed into lName is now executable.
</script>
</code>

Finally there is the problem that certain methods in JavaScript which are usually safe can be unsafe in certain contexts. 

==Usually Safe Methods==

One example of an attribute which is usually safe is innerText. Some papers or guides advocate its use as an alternative to innerHTML to mitigate against XSS in innerHTML. However, depending on the tag which innerText is applied, code can be executed. 

<code>
<script>
var tag = document.createElement(“script”);
tag.innerText = “<%=untrustedData%>”; //executes code
</script>
</code>

 

= Authors and Contributing Editors =

Jim Manico - jim[at]owasp.org

Abraham Kang - abraham.kang[at]owasp.org

Gareth (Gaz) Heyes

Stefano Di Paola

Achim Hoffman

Robert (RSnake) Hansen

Mario Heiderich

John Stevens

Chris (Chris BEF) Schmidt

Mike Samuel

Jeremy Long

Edwardo (SirDarkCat) Alberto Vela Nava

Jeff Williams - jeff.williams[at]owasp.org

Erlend Oftedal

{{Cheatsheet_Navigation}}

[[Category:How To]]

[[Category:Cheatsheets]]

DOM based XSS Prevention Cheat Sheet

2011-02-24T02:14:01Z

Abraham Kang:

= Introduction =

When looking at XSS (Cross Site Scripting) there are three generally recognized forms of XSS. Reflected, Persisted, and DOM based XSS. The [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] has done an excellent job of addressing Reflected and Persisted XSS. This cheatsheet will address DOM (Document Object Model) based XSS and is an extension (as assumes comprehension of) the the [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] .

In order to understand DOM based XSS one needs to see the fundamental difference between reflected and persisted XSS when compared to DOM based XSS. Reflected and persisted XSS exist in a higher level rendering context and DOM based XSS is primarily found in a lower level execution context. A rendering context is associated with the parsing of HTML tags and their attributes. The HTML parser of the rendering context dictates how data is presented and laid out on the page and can be further broken down into the standard contexts of HTML, HTML attribute, URL, and CSS. The JavaScript or VBScript parser of an execution context is associated with the parsing and execution of script code. Each parser has distinct and separate semantics in the way they can possibly execute script code (XSS) which make creating consistent rules for mitigating both rendering and execution based contexts difficult. The complication is compounded by the differing meanings and treatment of encoded values within each sub context (HTML, HTML attribute, URL, and CSS) within the execution context.

This paper refers to the HTML, HTML attribute, URL, and CSS Cheatsheet contexts as subcontexts because each of these contexts can be reached and set within a JavaScript execution context. In JavaScript code the main context is JavaScript but since an attacker can try to attack the other 4 contexts using equivalent JavaScript DOM methods we refer to the other contexts besides the JavaScript context as sub contexts. 

The following example of an attack which occurs in the JavaScript context and HTML sub context: 

<code>
<script>
var x = ‘<%= htmlAndJavaScriptEncodedVar %>’;
var d = document.createElement(‘div’);
d.innerHTML = x;
document.body.appendChild(d);
</script>
</code>

One consistency, however, is the need to JavaScript encode in addition to the encoding required for the sub context in the execution context. Let’s look at the individual sub contexts of the execution context in turn.

= HTML Sub Context within the Execution Context =

There are several methods and attributes which can be used to directly render HTML content within JavaScript. These methods constitute the HTML Sub Context within the Execution Context.

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

==Methods==
<code>
document.write(“<HTML> Tags and markup”);
document.writeln(“<HTML> Tags and markup”);
</code>

==Guideline==
In a pure HTML execution context (not HTML Attribute) use HTML and JavaScript encoding to mitigate against attacks.
<code>
element.innerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
element.outerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
</code>

==Methods==
<code>
document.write(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);
document.writeln(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);
</code>

= HTML Attribute Sub Context within the Execution Context =

The HTML attribute Sub Context within the Execution context is divergent from the standard encoding rules. This is because the rule to HTML attribute encode in an HTML attribute rendering context is mitigating attacks which try to exit out of the attribute to add additional attributes and/or tags which could have executable code. When you are in a DOM execution context you only need to JavaScript encode HTML attributes which do not execute code (attributes other than event handler, CSS, and URL attributes).

For example, the general rule is to HTML Attribute encode untrusted data (data from the database, http request, user, backend 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.

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

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.

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

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.

= URL Attribute Sub Context 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.

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

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.

=CSS Attribute Sub Context 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.

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

TODO: We have not been able to get the expression() function working from DOM JavaScript code. Need some help.

=Event Handler and JavaScript code Sub Contexts 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.

<code>
var x = document.createElement("a");
x.href="#”;
x.setAttribute("onclick", "\u0061\u006c\u0065\u0072\u0074\u0028\u0032\u0032\u0029");
var y = document.createTextNode("Click To Test");
x.appendChild(y);</code> 
document.body.appendChild(x);
</code>

JavaScript event handler methods are dangerous because they implicitly do an eval() on the data passed to the DOM attribute. There are other places in JavaScript where JavaScript encoding is accepted as valid executable code.

<code>
for ( var \u0062=0; \u0062 < 10; \u0062++){
\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074
.\u0077\u0072\u0069\u0074\u0065\u006c\u006e
("\u0048\u0065\u006c\u006c\u006f\u0020\u0057\u006f\u0072\u006c\u0064");
} </code> 
\u0077\u0069\u006e\u0064\u006f\u0077
.\u0065\u0076\u0061\u006c
\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074
.\u0077\u0072\u0069\u0074\u0065(111111111));
</code>

or

<code>
var s = "\u0065\u0076\u0061\u006c";
var t = "\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029";
window[s](t);
</code>

Because JavaScript is based on an international standard (ECMAScript), JavaScript encoding enables the support of international characters in programming constructs and variables in addition to alternate string representations (string escapes).

However the opposite is the case with HTML encoding. HTML tag elements are well defined and do not support alternate representations of the same tag. So HTML encoding cannot be used to allow the developer to have alternate representations of the <a> tag for example.

==HTML Encoding’s Disarming Nature==

In general, HTML encoding serves to castrate HTML tags which are placed in HTML and HTML attribute contexts.
Working example (no HTML encoding):

<code>
<a href=”…” >
</code>

Normally encoded example (Does Not Work – DNW):

<code>
&#x3c;a href=… &#x3e;
</code>

HTML encoded example to highlight a fundamental difference with JavaScript encoded values (DNW):

<code>
<&#x61; href=…>
</code>

If HTML encoding followed the same semantics as JavaScript encoding. The line above could have possibily worked to render a link. This difference makes JavaScript encoding a less viable weapon in our fight against XSS.

=Guidelines for Developing Secure Applications Utilizing JavaScript=

DOM based XSS is extremely difficult to mitigate against because of its large attack surface and lack of standardization across browsers. The guidelines below are an attempt to provide guidelines for developers when developing Web based JavaScript applications (Web 2.0) such that they can avoid XSS.

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) 
<code>
var x = “<%=encodedJavaScriptData%>”;
</code>
3. Use <code>document.createElement(“…”), element.setAttribute(“…”,”value”), element.appendChild(…)</code>, etc. to build dynamic interfaces. Avoid use of HTML rendering methods: 
#<code>element.innerHTML = “…”; </code>
#<code>element.outerHTML = “…”; </code>
#<code>document.write(…); </code>
#<code>document.writeln(…); </code> 
4. Understand the dataflow of untrusted data through your JavaScript code. If you do have to use the methods above remember to HTML and them JavaScript encode the untrusted data (Stefano Di Paola). 
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. 

Utilizing an Enclosure (as suggested by Gaz)

The example that follows illustrates using closures to avoid double JavaScript encoding.

<code>
setTimeout((function(param) { return function() {
customFunction(param);
}
})("<%=Encoder.encodeForJS(untrustedData)%>"), y);
</code>

The other alternative is using N-levels of encoding. 

N-Levels of Encoding 

If your code looked like the following, you would need to only double JavaScript encode input data.

<code>
setTimeout(“customFunction(‘<%=doubleJavaScriptEncodedData%>’, y)”);
function customFunction (firstName, lastName)
alert("Hello" + firstName + " " + lastNam);
}
</code>

The <code>doubleJavaScriptEncodedData</code> has its first layer of JavaScript encoding reversed in the single quotes. Then the implicit <code>eval()</code> of <code>setTimeout()</code> reverses another layer of JavaScript encoding to pass the correct value to <code>customFunction</code>. The reason why you only need to double JavaScript encode is that the <code>customFunction</code> function did not itself pass the input to another method which implicitly or explicitly called <code>eval()</code>. If "firstName" was passed to another JavaScript method which implicitly or explicitly called eval() then <code><%=doubleJavaScriptEncodedData%></code> above would need to be changed to <code><%=tripleJavaScriptEncodedData%></code>. 

An important implementation note is that if the JavaScript code tries to utilize the double or triple encoded data in string comparisons, the value may be interpreted as different values based on the number of evals() the data has passed through before being passed to the if comparison and the number of times the value was JavaScript encoded. 

If "A" is double JavaScript encoded then the following if check will return false. 

<code>
var x = "doubleJavaScriptEncodedA"; //\u005c\u0075\u0030\u0030\u0034\u0031
if (x == "A") {
alert("x is A");
} else if (x == "\u0041") {
alert("This is what pops");
}
</code>

This brings up an interesting design point. Ideally, the correct way to apply encoding and avoid the problem stated above is to server-side encode for the output context where data is introduced into the application. Then client-side encode (using a JavaScript encoding library such as ESAPI4JS) for the individual sub context (DOM methods) which untrusted data is passed to. ESAPI4JS (located at http://bit.ly/9hRTLH) 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. 
Here are some examples of how they are used: 
<code>
var input = “<%=Encoder.encodeForJS(untrustedData)%>”; //Server side encoding
</code>
<code>
window.location = ESAPI4JS.encodeForURL(input); //URL encoding is happening in JavaScript
</code>
<code>
document.writeln(ESAPI4JS.encodeForHTML(input)); //HTML encoding is happening in JavaScript
</code>

It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers. One option is to wait till ECMAScript 5 so the JavaScript library could support immutable properties. 
Another option provided by Gaz (Gareth) was to use a specific code construct to limit mutability with anonymous clousures. 

An example follows: 

<code>
function escapeHTML(str) {
str = str + "''";
var out = "''";
for(var i=0; i<str.length; i++) {
if(str[i] === '<') {
out += '&lt;';
} else if(str[i] === '>') {
out += '&gt;';
} else if(str[i] === "'") {
out += '&#39;';
} else if(str[i] === '"') {
out += '&quot;';
} else {
out += str[i];
}
}
return out;
}
</code>

 Chris Schmidt has put together another implementation of a JavaScript encoder at http://yet-another-dev.blogspot.com/2011/02/client-side-contextual-encoding-for.html. 

6. Limit the usage of dynamic untrusted data to right side operations. And be aware of data which may be passed to the application which look like code (eg. <code>location</code>, <code>eval()</code>). (Achim) 
<code>
var x = “<%=properly encoded data for flow%>”;
</code>

If you want to change different object attributes based on user input use a level of indirection. 

Instead of: 

<code>
window[userData] = “moreUserData”;
</code>

Do the following instead: 
<code>
if (userData===”location”) {
window.location = “static/path/or/properly/url/encoded/value”;
}
</code>

7. When URL encoding in DOM be aware of character set issues as the character set in JavaScript DOM is not clearly defined (Mike Samuel). 

8. Limit access to properties objects when using object[x] accessors. (Mike Samuel). In other words use a level of indirection between untrusted input and specified object properties. 
Here is an example of the problem when using map types: 
<code>
var myMapType = {};
myMapType[<%=untrustedData%>] = “moreUntrustedData”;
</code>

Although the developer writing the code above was trying to add additional keyed elements to the <code>myMapType</code> object. This could be used by an attacker to subvert internal and external attributes of the <code>myMapType</code> object. 

9. Run your JavaScript in a ECMAScript 5 canopy or sand box to make it harder for your JavaScript API to be compromised (Gareth Heyes and John Stevens). 

10. Don’t <code>eval()</code> JSON to convert it to native JavaScript objects. Instead use <code>JSON.toJSON()</code> and <code>JSON.parse()</code> (Chris Schmidt).

= Common Problems Associated with Mitgating DOM Based XSS =
==Complex Contexts==
In many cases the context isn’t always strait forward to discern. 
<code>
<a href=”javascript:myFunction(‘<%=untrustedData%>’, 'test');”>Click Me</a>
...
<script>
Function myFunction (url,name) {<
window.location = url;
}
</script>
</code>

In the above example, untrusted data started in the rendering URL context (<code>href</code> attribute of an <code><a></code> tag) then changed to a JavaScript execution context (<code>javascript:</code> protocol handler) which passed the untrusted data to an execution URL sub context (<code>window.location</code> of myFunction). Because the data was introduced in JavaScript code and passed to a URL sub context the appropriate server-side encoding would be the following: 

<code>
<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(Encoder.encodeForURL(untrustedData))%>’, 'test');”>Click Me</a>
…
</code>

Or if you were using ECMAScript 5 with an immutable JavaScript client-side encoding libraries you could do the following: 

<code>

<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(untrustedData)%>’, 'test');”>Click Me</a>
...
<script>
Function myFunction (url,name) {
var encodedURL = ESAPI4JS.encodeForURL(url); //URL encoding using client-side scripts
window.location = encodedURL;
}
</script>
</code>

== Insonsistencies of Encoding Libraries ==
There are a number of open source encoding libraries out there: 

#ESAPI
#Apache Commons String Utils
#Jtidy
#Your company’s custom implementation.

Some work on a black list others ignore important characters like “<” and “>”. ESAPI is one of the few which work on a whitelist and encode all non-alpha numeric characters.
It is important to use an encoding library which understands which characters can be used to exploit vulnerabilies in their respective contexts.
But there are misconceptions abound related to proper encoding.
==Encoding Misconceptions==
Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of “text/xhtml” or the file type extension of “*.xhtml” then HML encoding may not work to mitigate against XSS. 

For example: 

<code>
<script>
&#x61;lert(1);
</script>
</code>

The HTML encoded value above is still executable. If that isn’t enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element. 

Let’s look at the sample page and script: 

<code>
<form name=”myForm” …>
<input type=”text” name=”lName” value=”<%=Encoder.encodeForHTML(last_name)%>”>
…
</form>
<script>
var x = document.myForm.lName.value; //when the value is retrived the encoding is reversed
document.writeln(x); //any code passed into lName is now executable.
</script>
</code>

Finally there is the problem that certain methods in JavaScript which are usually safe can be unsafe in certain contexts. 

==Usually Safe Methods==

One example of an attribute which is usually safe is innerText. Some papers or guides advocate its use as an alternative to innerHTML to mitigate against XSS in innerHTML. However, depending on the tag which innerText is applied, code can be executed. 

<code>
<script>
var tag = document.createElement(“script”);
tag.innerText = “<%=untrustedData%>”; //executes code
</script>
</code>

 

= Authors and Contributing Editors =

Jim Manico - jim[at]owasp.org

Abraham Kang - abraham.kang[at]owasp.org

Gareth (Gaz) Heyes

Stefano Di Paola

Achim Hoffman

Robert (RSnake) Hansen

Mario Heiderich

John Stevens

Chris (Chris BEF) Schmidt

Mike Samuel

Jeremy Long

Edwardo (SirDarkCat) Alberto Vela Nava

Jeff Williams - jeff.williams[at]owasp.org

{{Cheatsheet_Navigation}}

[[Category:How To]]

[[Category:Cheatsheets]]

DOM based XSS Prevention Cheat Sheet

2011-02-24T02:13:12Z

Abraham Kang:

= Introduction =

When looking at XSS (Cross Site Scripting) there are three generally recognized forms of XSS. Reflected, Persisted, and DOM based XSS. The [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] has done an excellent job of addressing Reflected and Persisted XSS. This cheatsheet will address DOM (Document Object Model) based XSS and is an extension (as assumes comprehension of) the the [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] .

In order to understand DOM based XSS one needs to see the fundamental difference between reflected and persisted XSS when compared to DOM based XSS. Reflected and persisted XSS exist in a higher level rendering context and DOM based XSS is primarily found in a lower level execution context. A rendering context is associated with the parsing of HTML tags and their attributes. The HTML parser of the rendering context dictates how data is presented and laid out on the page and can be further broken down into the standard contexts of HTML, HTML attribute, URL, and CSS. The JavaScript or VBScript parser of an execution context is associated with the parsing and execution of script code. Each parser has distinct and separate semantics in the way they can possibly execute script code (XSS) which make creating consistent rules for mitigating both rendering and execution based contexts difficult. The complication is compounded by the differing meanings and treatment of encoded values within each sub context (HTML, HTML attribute, URL, and CSS) within the execution context.

This paper refers to the HTML, HTML attribute, URL, and CSS Cheatsheet contexts as subcontexts because each of these contexts can be reached and set within a JavaScript execution context. In JavaScript code the main context is JavaScript but since an attacker can try to attack the other 4 contexts using equivalent JavaScript DOM methods we refer to the other contexts besides the JavaScript context as sub contexts. 

The following example of an attack which occurs in the JavaScript context and HTML sub context: 

<code>
<script>
var x = ‘<%= htmlAndJavaScriptEncodedVar %>’;
var d = document.createElement(‘div’);
d.innerHTML = x;
document.body.appendChild(d);
</script>
</code>

One consistency, however, is the need to JavaScript encode in addition to the encoding required for the sub context in the execution context. Let’s look at the individual sub contexts of the execution context in turn.

= HTML Sub Context within the Execution Context =

There are several methods and attributes which can be used to directly render HTML content within JavaScript. These methods constitute the HTML Sub Context within the Execution Context.

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

==Methods==
<code>
document.write(“<HTML> Tags and markup”);
document.writeln(“<HTML> Tags and markup”);
</code>

==Guideline==
In a pure HTML execution context (not HTML Attribute) use HTML and JavaScript encoding to mitigate against attacks.
<code>
element.innerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
element.outerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
</code>

==Methods==
<code>
document.write(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);
document.writeln(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);
</code>

= HTML Attribute Sub Context within the Execution Context =

The HTML attribute Sub Context within the Execution context is divergent from the standard encoding rules. This is because the rule to HTML attribute encode in an HTML attribute rendering context is mitigating attacks which try to exit out of the attribute to add additional attributes and/or tags which could have executable code. When you are in a DOM execution context you only need to JavaScript encode HTML attributes which do not execute code (attributes other than event handler, CSS, and URL attributes).

For example, the general rule is to HTML Attribute encode untrusted data (data from the database, http request, user, backend 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.

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

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.

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

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.

= URL Attribute Sub Context 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.

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

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.

=CSS Attribute Sub Context 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.

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

TODO: We have not been able to get the expression() function working from DOM JavaScript code. Need some help.

=Event Handler and JavaScript code Sub Contexts 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.

<code>
var x = document.createElement("a");
x.href="#”;
x.setAttribute("onclick", "\u0061\u006c\u0065\u0072\u0074\u0028\u0032\u0032\u0029");
var y = document.createTextNode("Click To Test");
x.appendChild(y);</code> 
document.body.appendChild(x);
</code>

JavaScript event handler methods are dangerous because they implicitly do an eval() on the data passed to the DOM attribute. There are other places in JavaScript where JavaScript encoding is accepted as valid executable code.

<code>
for ( var \u0062=0; \u0062 < 10; \u0062++){
\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074
.\u0077\u0072\u0069\u0074\u0065\u006c\u006e
("\u0048\u0065\u006c\u006c\u006f\u0020\u0057\u006f\u0072\u006c\u0064");
} </code> 
\u0077\u0069\u006e\u0064\u006f\u0077
.\u0065\u0076\u0061\u006c
\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074
.\u0077\u0072\u0069\u0074\u0065(111111111));
</code>

or

<code>
var s = "\u0065\u0076\u0061\u006c";
var t = "\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029";
window[s](t);
</code>

Because JavaScript is based on an international standard (ECMAScript), JavaScript encoding enables the support of international characters in programming constructs and variables in addition to alternate string representations (string escapes).

However the opposite is the case with HTML encoding. HTML tag elements are well defined and do not support alternate representations of the same tag. So HTML encoding cannot be used to allow the developer to have alternate representations of the <a> tag for example.

==HTML Encoding’s Disarming Nature==

In general, HTML encoding serves to castrate HTML tags which are placed in HTML and HTML attribute contexts.
Working example (no HTML encoding):

<code>
<a href=”…” >
</code>

Normally encoded example (Does Not Work – DNW):

<code>
&#x3c;a href=… &#x3e;
</code>

HTML encoded example to highlight a fundamental difference with JavaScript encoded values (DNW):

<code>
<&#x61; href=…>
</code>

If HTML encoding followed the same semantics as JavaScript encoding. The line above could have possibily worked to render a link. This difference makes JavaScript encoding a less viable weapon in our fight against XSS.

=Guidelines for Developing Secure Applications Utilizing JavaScript=

DOM based XSS is extremely difficult to mitigate against because of its large attack surface and lack of standardization across browsers. The guidelines below are an attempt to provide guidelines for developers when developing Web based JavaScript applications (Web 2.0) such that they can avoid XSS.

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) 
<code>
var x = “<%=encodedJavaScriptData%>”;
</code>
3. Use <code>document.createElement(“…”), element.setAttribute(“…”,”value”), element.appendChild(…)</code>, etc. to build dynamic interfaces. Avoid use of HTML rendering methods: 
#<code>element.innerHTML = “…”; </code>
#<code>element.outerHTML = “…”; </code>
#<code>document.write(…); </code>
#<code>document.writeln(…); </code> 
4. Understand the dataflow of untrusted data through your JavaScript code. If you do have to use the methods above remember to HTML and them JavaScript encode the untrusted data (Stefano Di Paola). 
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. 

Utilizing an Enclosure (as suggested by Gaz)

The example that follows illustrates using closures to avoid double JavaScript encoding.

<code>
setTimeout((function(param) { return function() {
customFunction(param);
}
})("<%=Encoder.encodeForJS(untrustedData)%>"), y);
</code>

The other alternative is using N-levels of encoding. 

N-Levels of Encoding 

If your code looked like the following, you would need to only double JavaScript encode input data.

<code>
setTimeout(“customFunction(‘<%=doubleJavaScriptEncodedData%>’, y)”);
function customFunction (firstName, lastName)
alert("Hello" + firstName + " " + lastNam);
}
</code>

The <code>doubleJavaScriptEncodedData</code> has its first layer of JavaScript encoding reversed in the single quotes. Then the implicit <code>eval()</code> of <code>setTimeout()</code> reverses another layer of JavaScript encoding to pass the correct value to <code>customFunction</code>. The reason why you only need to double JavaScript encode is that the <code>customFunction</code> function did not itself pass the input to another method which implicitly or explicitly called <code>eval()</code>. If "firstName" was passed to another JavaScript method which implicitly or explicitly called eval() then <code><%=doubleJavaScriptEncodedData%></code> above would need to be changed to <code><%=tripleJavaScriptEncodedData%></code>. 

An important implementation note is that if the JavaScript code tries to utilize the double or triple encoded data in string comparisons, the value may be interpreted as different values based on the number of evals() the data has passed through before being passed to the if comparison and the number of times the value was JavaScript encoded. 

If "A" is double JavaScript encoded then the following if check will return false. 

<code>
var x = "doubleJavaScriptEncodedA"; //\u005c\u0075\u0030\u0030\u0034\u0031
if (x == "A") {
alert("x is A");
} else if (x == "\u0041") {
alert("This is what pops");
}
</code>

This brings up an interesting design point. Ideally, the correct way to apply encoding and avoid the problem stated above is to server-side encode for the output context where data is introduced into the application. Then client-side encode (using a JavaScript encoding library such as ESAPI4JS) for the individual sub context (DOM methods) which untrusted data is passed to. ESAPI4JS (located at http://bit.ly/9hRTLH) 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. 
Here are some examples of how they are used: 
<code>
var input = “<%=Encoder.encodeForJS(untrustedData)%>”; //Server side encoding
</code>
<code>
window.location = ESAPI4JS.encodeForURL(input); //URL encoding is happening in JavaScript
</code>
<code>
document.writeln(ESAPI4JS.encodeForHTML(input)); //HTML encoding is happening in JavaScript
</code>

It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers. One option is to wait till ECMAScript 5 so the JavaScript library could support immutable properties. 
Another option provided by Gaz (Gareth) was to use a specific code construct to limit mutability with anonymous clousures. 

An example follows: 

<code>
function escapeHTML(str) {
str = str + "''";
var out = "''";
for(var i=0; i<str.length; i++) {
if(str[i] === '<') {
out += '&lt;';
} else if(str[i] === '>') {
out += '&gt;';
} else if(str[i] === "'") {
out += '&#39;';
} else if(str[i] === '"') {
out += '&quot;';
} else {
out += str[i];
}
}
return out;
}
</code>

 Chris Schmidt has put together another implementation of a JavaScript encoder at http://yet-another-dev.blogspot.com/2011/02/client-side-contextual-encoding-for.html. 

6. Limit the usage of dynamic untrusted data to right side operations. And be aware of data which may be passed to the application which look like code (eg. <code>location</code>, <code>eval()</code>). (Achim) 
<code>
var x = “<%=properly encoded data for flow%>”;
</code>

If you want to change different object attributes based on user input use a level of indirection. 

Instead of: 

<code>
window[userData] = “moreUserData”;
</code>

Do the following instead: 
<code>
if (userData===”location”) {
window.location = “static/path/or/properly/url/encoded/value”;
}
</code>

7. When URL encoding in DOM be aware of character set issues as the character set in JavaScript DOM is not clearly defined (Mike Samuel). 

8. Limit access to properties objects when using object[x] accessors. (Mike Samuel). In other words use a level of indirection between untrusted input and specified object properties. 
Here is an example of the problem when using map types: 
<code>
var myMapType = {};
myMapType[<%=untrustedData%>] = “moreUntrustedData”;
</code>

Although the developer writing the code above was trying to add additional keyed elements to the <code>myMapType</code> object. This could be used by an attacker to subvert internal and external attributes of the <code>myMapType</code> object. 

9. Run your JavaScript in a ECMAScript 5 canopy or sand box to make it harder for your JavaScript API to be compromised (Gareth Heyes and John Stevens). 

10. Don’t <code>eval()</code> JSON to convert it to native JavaScript objects. Instead use <code>JSON.toJSON()</code> and <code>JSON.parse()</code> (Chris Schmidt).

= Common Problems Associated with Mitgating DOM Based XSS =
==Complex Contexts==
In many cases the context isn’t always strait forward to discern. 
<code>
<a href=”javascript:myFunction(‘<%=untrustedData%>’, 'test');”>Click Me</a>
...
<script>
Function myFunction (url,name) {<
window.location = url;
}
</script>
</code>

In the above example, untrusted data started in the rendering URL context (<code>href</code> attribute of an <code><a></code> tag) then changed to a JavaScript execution context (<code>javascript:</code> protocol handler) which passed the untrusted data to an execution URL sub context (<code>window.location</code> of myFunction). Because the data was introduced in JavaScript code and passed to a URL sub context the appropriate server-side encoding would be the following: 

<code>
<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(Encoder.encodeForURL(untrustedData))%>’, 'test');”>Click Me</a>
…
</code>

Or if you were using ECMAScript 5 with an immutable JavaScript client-side encoding libraries you could do the following: 

<code>

<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(untrustedData)%>’, 'test');”>Click Me</a>
...
<script>
Function myFunction (url,name) {
var encodedURL = ESAPI4JS.encodeForURL(url); //URL encoding using client-side scripts
window.location = encodedURL;
}
</script>
</code>

== Insonsistencies of Encoding Libraries ==
There are a number of open source encoding libraries out there: 

#ESAPI
#Apache Commons String Utils
#Jtidy
#Your company’s custom implementation.

Some work on a black list others ignore important characters like “<” and “>”. ESAPI is one of the few which work on a whitelist and encode all non-alpha numeric characters.
It is important to use an encoding library which understands which characters can be used to exploit vulnerabilies in their respective contexts.
But there are misconceptions abound related to proper encoding.
==Encoding Misconceptions==
Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of “text/xhtml” or the file type extension of “*.xhtml” then HML encoding may not work to mitigate against XSS. 

For example: 

<code>
<script>
&#x61;lert(1);
</script>
</code>

The HTML encoded value above is still executable. If that isn’t enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element. 

Let’s look at the sample page and script: 

<code>
<form name=”myForm” …>
<input type=”text” name=”lName” value=”<%=Encoder.encodeForHTML(last_name)%>”>
…
</form>
<script>
var x = document.myForm.lName.value; //when the value is retrived the encoding is reversed
document.writeln(x); //any code passed into lName is now executable.
</script>
</code>

Finally there is the problem that certain methods in JavaScript which are usually safe can be unsafe in certain contexts. 

==Usually Safe Methods==

One example of an attribute which is usually safe is innerText. Some papers or guides advocate its use as an alternative to innerHTML to mitigate against XSS in innerHTML. However, depending on the tag which innerText is applied, code can be executed. 

<code>
<script>
var tag = document.createElement(“script”);
tag.innerText = “<%=untrustedData%>”; //executes code
</script>
</code>

 

{{Cheatsheet_Navigation}}

[[Category:How To]]

= Authors and Contributing Editors =

Jim Manico - jim[at]owasp.org

Abraham Kang - abraham.kang[at]owasp.org

Gareth (Gaz) Heyes

Stefano Di Paola

Achim Hoffman

Robert (RSnake) Hansen

Mario Heiderich

John Stevens

Chris (Chris BEF) Schmidt

Mike Samuel

Jeremy Long

Edwardo (SirDarkCat) Alberto Vela Nava

Jeff Williams - jeff.williams[at]owasp.org

[[Category:Cheatsheets]]

DOM based XSS Prevention Cheat Sheet

2011-02-24T02:11:34Z

Abraham Kang:

= Introduction =

When looking at XSS (Cross Site Scripting) there are three generally recognized forms of XSS. Reflected, Persisted, and DOM based XSS. The [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] has done an excellent job of addressing Reflected and Persisted XSS. This cheatsheet will address DOM (Document Object Model) based XSS and is an extension (as assumes comprehension of) the the [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] .

In order to understand DOM based XSS one needs to see the fundamental difference between reflected and persisted XSS when compared to DOM based XSS. Reflected and persisted XSS exist in a higher level rendering context and DOM based XSS is primarily found in a lower level execution context. A rendering context is associated with the parsing of HTML tags and their attributes. The HTML parser of the rendering context dictates how data is presented and laid out on the page and can be further broken down into the standard contexts of HTML, HTML attribute, URL, and CSS. The JavaScript or VBScript parser of an execution context is associated with the parsing and execution of script code. Each parser has distinct and separate semantics in the way they can possibly execute script code (XSS) which make creating consistent rules for mitigating both rendering and execution based contexts difficult. The complication is compounded by the differing meanings and treatment of encoded values within each sub context (HTML, HTML attribute, URL, and CSS) within the execution context.

This paper refers to the HTML, HTML attribute, URL, and CSS Cheatsheet contexts as subcontexts because each of these contexts can be reached and set within a JavaScript execution context. In JavaScript code the main context is JavaScript but since an attacker can try to attack the other 4 contexts using equivalent JavaScript DOM methods we refer to the other contexts besides the JavaScript context as sub contexts. 

The following example of an attack which occurs in the JavaScript context and HTML sub context: 

<code>
<script>
var x = ‘<%= htmlAndJavaScriptEncodedVar %>’;
var d = document.createElement(‘div’);
d.innerHTML = x;
document.body.appendChild(d);
</script>
</code>

One consistency, however, is the need to JavaScript encode in addition to the encoding required for the sub context in the execution context. Let’s look at the individual sub contexts of the execution context in turn.

= HTML Sub Context within the Execution Context =

There are several methods and attributes which can be used to directly render HTML content within JavaScript. These methods constitute the HTML Sub Context within the Execution Context.

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

==Methods==
<code>
document.write(“<HTML> Tags and markup”);
document.writeln(“<HTML> Tags and markup”);
</code>

==Guideline==
In a pure HTML execution context (not HTML Attribute) use HTML and JavaScript encoding to mitigate against attacks.
<code>
element.innerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
element.outerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
</code>

==Methods==
<code>
document.write(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);
document.writeln(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);
</code>

= HTML Attribute Sub Context within the Execution Context =

The HTML attribute Sub Context within the Execution context is divergent from the standard encoding rules. This is because the rule to HTML attribute encode in an HTML attribute rendering context is mitigating attacks which try to exit out of the attribute to add additional attributes and/or tags which could have executable code. When you are in a DOM execution context you only need to JavaScript encode HTML attributes which do not execute code (attributes other than event handler, CSS, and URL attributes).

For example, the general rule is to HTML Attribute encode untrusted data (data from the database, http request, user, backend 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.

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

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.

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

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.

= URL Attribute Sub Context 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.

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

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.

=CSS Attribute Sub Context 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.

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

TODO: We have not been able to get the expression() function working from DOM JavaScript code. Need some help.

=Event Handler and JavaScript code Sub Contexts 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.

<code>
var x = document.createElement("a");
x.href="#”;
x.setAttribute("onclick", "\u0061\u006c\u0065\u0072\u0074\u0028\u0032\u0032\u0029");
var y = document.createTextNode("Click To Test");
x.appendChild(y);</code> 
document.body.appendChild(x);
</code>

JavaScript event handler methods are dangerous because they implicitly do an eval() on the data passed to the DOM attribute. There are other places in JavaScript where JavaScript encoding is accepted as valid executable code.

<code>
for ( var \u0062=0; \u0062 < 10; \u0062++){
\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074
.\u0077\u0072\u0069\u0074\u0065\u006c\u006e
("\u0048\u0065\u006c\u006c\u006f\u0020\u0057\u006f\u0072\u006c\u0064");
} </code> 
\u0077\u0069\u006e\u0064\u006f\u0077
.\u0065\u0076\u0061\u006c
\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074
.\u0077\u0072\u0069\u0074\u0065(111111111));
</code>

or

<code>
var s = "\u0065\u0076\u0061\u006c";
var t = "\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029";
window[s](t);
</code>

Because JavaScript is based on an international standard (ECMAScript), JavaScript encoding enables the support of international characters in programming constructs and variables in addition to alternate string representations (string escapes).

However the opposite is the case with HTML encoding. HTML tag elements are well defined and do not support alternate representations of the same tag. So HTML encoding cannot be used to allow the developer to have alternate representations of the <a> tag for example.

==HTML Encoding’s Disarming Nature==

In general, HTML encoding serves to castrate HTML tags which are placed in HTML and HTML attribute contexts.
Working example (no HTML encoding):

<code>
<a href=”…” >
</code>

Normally encoded example (Does Not Work – DNW):

<code>
&#x3c;a href=… &#x3e;
</code>

HTML encoded example to highlight a fundamental difference with JavaScript encoded values (DNW):

<code>
<&#x61; href=…>
</code>

If HTML encoding followed the same semantics as JavaScript encoding. The line above could have possibily worked to render a link. This difference makes JavaScript encoding a less viable weapon in our fight against XSS.

=Guidelines for Developing Secure Applications Utilizing JavaScript=

DOM based XSS is extremely difficult to mitigate against because of its large attack surface and lack of standardization across browsers. The guidelines below are an attempt to provide guidelines for developers when developing Web based JavaScript applications (Web 2.0) such that they can avoid XSS.

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) 
<code>
var x = “<%=encodedJavaScriptData%>”;
</code>
3. Use <code>document.createElement(“…”), element.setAttribute(“…”,”value”), element.appendChild(…)</code>, etc. to build dynamic interfaces. Avoid use of HTML rendering methods: 
#<code>element.innerHTML = “…”; </code>
#<code>element.outerHTML = “…”; </code>
#<code>document.write(…); </code>
#<code>document.writeln(…); </code> 
4. Understand the dataflow of untrusted data through your JavaScript code. If you do have to use the methods above remember to HTML and them JavaScript encode the untrusted data (Stefano Di Paola). 
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. 

Utilizing an Enclosure (as suggested by Gaz)

The example that follows illustrates using closures to avoid double JavaScript encoding.

<code>
setTimeout((function(param) { return function() {
customFunction(param);
}
})("<%=Encoder.encodeForJS(untrustedData)%>"), y);
</code>

The other alternative is using N-levels of encoding. 

N-Levels of Encoding 

If your code looked like the following, you would need to only double JavaScript encode input data.

<code>
setTimeout(“customFunction(‘<%=doubleJavaScriptEncodedData%>’, y)”);
function customFunction (firstName, lastName)
alert("Hello" + firstName + " " + lastNam);
}
</code>

The <code>doubleJavaScriptEncodedData</code> has its first layer of JavaScript encoding reversed in the single quotes. Then the implicit <code>eval()</code> of <code>setTimeout()</code> reverses another layer of JavaScript encoding to pass the correct value to <code>customFunction</code>. The reason why you only need to double JavaScript encode is that the <code>customFunction</code> function did not itself pass the input to another method which implicitly or explicitly called <code>eval()</code>. If "firstName" was passed to another JavaScript method which implicitly or explicitly called eval() then <code><%=doubleJavaScriptEncodedData%></code> above would need to be changed to <code><%=tripleJavaScriptEncodedData%></code>. 

An important implementation note is that if the JavaScript code tries to utilize the double or triple encoded data in string comparisons, the value may be interpreted as different values based on the number of evals() the data has passed through before being passed to the if comparison and the number of times the value was JavaScript encoded. 

If "A" is double JavaScript encoded then the following if check will return false. 

<code>
var x = "doubleJavaScriptEncodedA"; //\u005c\u0075\u0030\u0030\u0034\u0031
if (x == "A") {
alert("x is A");
} else if (x == "\u0041") {
alert("This is what pops");
}
</code>

This brings up an interesting design point. Ideally, the correct way to apply encoding and avoid the problem stated above is to server-side encode for the output context where data is introduced into the application. Then client-side encode (using a JavaScript encoding library such as ESAPI4JS) for the individual sub context (DOM methods) which untrusted data is passed to. ESAPI4JS (located at http://bit.ly/9hRTLH) 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. 
Here are some examples of how they are used: 
<code>
var input = “<%=Encoder.encodeForJS(untrustedData)%>”; //Server side encoding
</code>
<code>
window.location = ESAPI4JS.encodeForURL(input); //URL encoding is happening in JavaScript
</code>
<code>
document.writeln(ESAPI4JS.encodeForHTML(input)); //HTML encoding is happening in JavaScript
</code>

It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers. One option is to wait till ECMAScript 5 so the JavaScript library could support immutable properties. 
Another option provided by Gaz (Gareth) was to use a specific code construct to limit mutability with anonymous clousures. 

An example follows: 

<code>
function escapeHTML(str) {
str = str + "''";
var out = "''";
for(var i=0; i<str.length; i++) {
if(str[i] === '<') {
out += '&lt;';
} else if(str[i] === '>') {
out += '&gt;';
} else if(str[i] === "'") {
out += '&#39;';
} else if(str[i] === '"') {
out += '&quot;';
} else {
out += str[i];
}
}
return out;
}
</code>

 Chris Schmidt has put together another implementation of a JavaScript encoder at http://yet-another-dev.blogspot.com/2011/02/client-side-contextual-encoding-for.html. 

6. Limit the usage of dynamic untrusted data to right side operations. And be aware of data which may be passed to the application which look like code (eg. <code>location</code>, <code>eval()</code>). (Achim) 
<code>
var x = “<%=properly encoded data for flow%>”;
</code>

If you want to change different object attributes based on user input use a level of indirection. 

Instead of: 

<code>
window[userData] = “moreUserData”;
</code>

Do the following instead: 
<code>
if (userData===”location”) {
window.location = “static/path/or/properly/url/encoded/value”;
}
</code>

7. When URL encoding in DOM be aware of character set issues as the character set in JavaScript DOM is not clearly defined (Mike Samuel). 

8. Limit access to properties objects when using object[x] accessors. (Mike Samuel). In other words use a level of indirection between untrusted input and specified object properties. 
Here is an example of the problem when using map types: 
<code>
var myMapType = {};
myMapType[<%=untrustedData%>] = “moreUntrustedData”;
</code>

Although the developer writing the code above was trying to add additional keyed elements to the <code>myMapType</code> object. This could be used by an attacker to subvert internal and external attributes of the <code>myMapType</code> object. 

9. Run your JavaScript in a ECMAScript 5 canopy or sand box to make it harder for your JavaScript API to be compromised (Gareth Heyes and John Stevens). 

10. Don’t <code>eval()</code> JSON to convert it to native JavaScript objects. Instead use <code>JSON.toJSON()</code> and <code>JSON.parse()</code> (Chris Schmidt).

= Common Problems Associated with Mitgating DOM Based XSS =
==Complex Contexts==
In many cases the context isn’t always strait forward to discern. 
<code>
<a href=”javascript:myFunction(‘<%=untrustedData%>’, 'test');”>Click Me</a>
...
<script>
Function myFunction (url,name) {<
window.location = url;
}
</script>
</code>

In the above example, untrusted data started in the rendering URL context (<code>href</code> attribute of an <code><a></code> tag) then changed to a JavaScript execution context (<code>javascript:</code> protocol handler) which passed the untrusted data to an execution URL sub context (<code>window.location</code> of myFunction). Because the data was introduced in JavaScript code and passed to a URL sub context the appropriate server-side encoding would be the following: 

<code>
<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(Encoder.encodeForURL(untrustedData))%>’, 'test');”>Click Me</a>
…
</code>

Or if you were using ECMAScript 5 with an immutable JavaScript client-side encoding libraries you could do the following: 

<code>

<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(untrustedData)%>’, 'test');”>Click Me</a>
...
<script>
Function myFunction (url,name) {
var encodedURL = ESAPI4JS.encodeForURL(url); //URL encoding using client-side scripts
window.location = encodedURL;
}
</script>
</code>

== Insonsistencies of Encoding Libraries ==
There are a number of open source encoding libraries out there: 

#ESAPI
#Apache Commons String Utils
#Jtidy
#Your company’s custom implementation.

Some work on a black list others ignore important characters like “<” and “>”. ESAPI is one of the few which work on a whitelist and encode all non-alpha numeric characters.
It is important to use an encoding library which understands which characters can be used to exploit vulnerabilies in their respective contexts.
But there are misconceptions abound related to proper encoding.
==Encoding Misconceptions==
Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of “text/xhtml” or the file type extension of “*.xhtml” then HML encoding may not work to mitigate against XSS. 

For example: 

<code>
<script>
&#x61;lert(1);
</script>
</code>

The HTML encoded value above is still executable. If that isn’t enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element. 

Let’s look at the sample page and script: 

<code>
<form name=”myForm” …>
<input type=”text” name=”lName” value=”<%=Encoder.encodeForHTML(last_name)%>”>
…
</form>
<script>
var x = document.myForm.lName.value; //when the value is retrived the encoding is reversed
document.writeln(x); //any code passed into lName is now executable.
</script>
</code>

Finally there is the problem that certain methods in JavaScript which are usually safe can be unsafe in certain contexts. 

==Usually Safe Methods==

One example of an attribute which is usually safe is innerText. Some papers or guides advocate its use as an alternative to innerHTML to mitigate against XSS in innerHTML. However, depending on the tag which innerText is applied, code can be executed. 

<code>
<script>
var tag = document.createElement(“script”);
tag.innerText = “<%=untrustedData%>”; //executes code
</script>
</code>

 

= Authors and Contributing Editors =

Jim Manico - jim[at]owasp.org

Abraham Kang - abraham.kang[at]owasp.org

Gareth (Gaz) Heyes

Stefano Di Paola

Achim Hoffman

Robert (RSnake) Hansen

Mario Heiderich

John Stevens

Chris (Chris BEF) Schmidt

Mike Samuel

Jeremy Long

Edwardo (SirDarkCat) Alberto Vela Nava

Jeff Williams - jeff.williams[at]owasp.org

{{Cheatsheet_Navigation}}

[[Category:How To]]
[[Category:Cheatsheets]]

DOM based XSS Prevention Cheat Sheet

2011-02-24T01:58:51Z

Abraham Kang:

= Introduction =

When looking at XSS (Cross Site Scripting) there are three generally recognized forms of XSS. Reflected, Persisted, and DOM based XSS. The [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] has done an excellent job of addressing Reflected and Persisted XSS. This cheatsheet will address DOM (Document Object Model) based XSS and is an extension (as assumes comprehension of) the the [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] .

In order to understand DOM based XSS one needs to see the fundamental difference between reflected and persisted XSS when compared to DOM based XSS. Reflected and persisted XSS exist in a higher level rendering context and DOM based XSS is primarily found in a lower level execution context. A rendering context is associated with the parsing of HTML tags and their attributes. The HTML parser of the rendering context dictates how data is presented and laid out on the page and can be further broken down into the standard contexts of HTML, HTML attribute, URL, and CSS. The JavaScript or VBScript parser of an execution context is associated with the parsing and execution of script code. Each parser has distinct and separate semantics in the way they can possibly execute script code (XSS) which make creating consistent rules for mitigating both rendering and execution based contexts difficult. The complication is compounded by the differing meanings and treatment of encoded values within each sub context (HTML, HTML attribute, URL, and CSS) within the execution context.

This paper refers to the HTML, HTML attribute, URL, and CSS Cheatsheet contexts as subcontexts because each of these contexts can be reached and set within a JavaScript execution context. In JavaScript code the main context is JavaScript but since an attacker can try to attack the other 4 contexts using equivalent JavaScript DOM methods we refer to the other contexts besides the JavaScript context as sub contexts. 

The following example of an attack which occurs in the JavaScript context and HTML sub context: 

<code>
<script>
var x = ‘<%= htmlAndJavaScriptEncodedVar %>’;
var d = document.createElement(‘div’);
d.innerHTML = x;
document.body.appendChild(d);
</script>
</code>

One consistency, however, is the need to JavaScript encode in addition to the encoding required for the sub context in the execution context. Let’s look at the individual sub contexts of the execution context in turn.

= HTML Sub Context within the Execution Context =

There are several methods and attributes which can be used to directly render HTML content within JavaScript. These methods constitute the HTML Sub Context within the Execution Context.

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

==Methods==
<code>
document.write(“<HTML> Tags and markup”);
document.writeln(“<HTML> Tags and markup”);
</code>

==Guideline==
In a pure HTML execution context (not HTML Attribute) use HTML and JavaScript encoding to mitigate against attacks.
<code>
element.innerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
element.outerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
</code>

==Methods==
<code>
document.write(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);
document.writeln(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);
</code>

= HTML Attribute Sub Context within the Execution Context =

The HTML attribute Sub Context within the Execution context is divergent from the standard encoding rules. This is because the rule to HTML attribute encode in an HTML attribute rendering context is mitigating attacks which try to exit out of the attribute to add additional attributes and/or tags which could have executable code. When you are in a DOM execution context you only need to JavaScript encode HTML attributes which do not execute code (attributes other than event handler, CSS, and URL attributes).

For example, the general rule is to HTML Attribute encode untrusted data (data from the database, http request, user, backend 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.

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

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.

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

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.

= URL Attribute Sub Context 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.

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

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.

=CSS Attribute Sub Context 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.

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

TODO: We have not been able to get the expression() function working from DOM JavaScript code. Need some help.

=Event Handler and JavaScript code Sub Contexts 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.

<code>
var x = document.createElement("a");
x.href="#”;
x.setAttribute("onclick", "\u0061\u006c\u0065\u0072\u0074\u0028\u0032\u0032\u0029");
var y = document.createTextNode("Click To Test");
x.appendChild(y);</code> 
document.body.appendChild(x);
</code>

JavaScript event handler methods are dangerous because they implicitly do an eval() on the data passed to the DOM attribute. There are other places in JavaScript where JavaScript encoding is accepted as valid executable code.

<code>
for ( var \u0062=0; \u0062 < 10; \u0062++){
\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074
.\u0077\u0072\u0069\u0074\u0065\u006c\u006e
("\u0048\u0065\u006c\u006c\u006f\u0020\u0057\u006f\u0072\u006c\u0064");
} </code> 
\u0077\u0069\u006e\u0064\u006f\u0077
.\u0065\u0076\u0061\u006c
\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074
.\u0077\u0072\u0069\u0074\u0065(111111111));
</code>

or

<code>
var s = "\u0065\u0076\u0061\u006c";
var t = "\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029";
window[s](t);
</code>

Because JavaScript is based on an international standard (ECMAScript), JavaScript encoding enables the support of international characters in programming constructs and variables in addition to alternate string representations (string escapes).

However the opposite is the case with HTML encoding. HTML tag elements are well defined and do not support alternate representations of the same tag. So HTML encoding cannot be used to allow the developer to have alternate representations of the <a> tag for example.

==HTML Encoding’s Disarming Nature==

In general, HTML encoding serves to castrate HTML tags which are placed in HTML and HTML attribute contexts.
Working example (no HTML encoding):

<code>
<a href=”…” >
</code>

Normally encoded example (Does Not Work – DNW):

<code>
&#x3c;a href=… &#x3e;
</code>

HTML encoded example to highlight a fundamental difference with JavaScript encoded values (DNW):

<code>
<&#x61; href=…>
</code>

If HTML encoding followed the same semantics as JavaScript encoding. The line above could have possibily worked to render a link. This difference makes JavaScript encoding a less viable weapon in our fight against XSS.

=Guidelines for Developing Secure Applications Utilizing JavaScript=

DOM based XSS is extremely difficult to mitigate against because of its large attack surface and lack of standardization across browsers. The guidelines below are an attempt to provide guidelines for developers when developing Web based JavaScript applications (Web 2.0) such that they can avoid XSS.

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) 
<code>
var x = “<%=encodedJavaScriptData%>”;
</code>
3. Use <code>document.createElement(“…”), element.setAttribute(“…”,”value”), element.appendChild(…)</code>, etc. to build dynamic interfaces. Avoid use of HTML rendering methods: 
#<code>element.innerHTML = “…”; </code>
#<code>element.outerHTML = “…”; </code>
#<code>document.write(…); </code>
#<code>document.writeln(…); </code> 
4. Understand the dataflow of untrusted data through your JavaScript code. If you do have to use the methods above remember to HTML and them JavaScript encode the untrusted data (Stefano Di Paola). 
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. 

Utilizing an Enclosure (as suggested by Gaz)

The example that follows illustrates using closures to avoid double JavaScript encoding.

<code>
setTimeout((function(param) { return function() {
customFunction(param);
}
})("<%=Encoder.encodeForJS(untrustedData)%>"), y);
</code>

The other alternative is using N-levels of encoding. 

N-Levels of Encoding 

If your code looked like the following, you would need to only double JavaScript encode input data.

<code>
setTimeout(“customFunction(‘<%=doubleJavaScriptEncodedData%>’, y)”);
function customFunction (firstName, lastName)
alert("Hello" + firstName + " " + lastNam);
}
</code>

The <code>doubleJavaScriptEncodedData</code> has its first layer of JavaScript encoding reversed in the single quotes. Then the implicit <code>eval()</code> of <code>setTimeout()</code> reverses another layer of JavaScript encoding to pass the correct value to <code>customFunction</code>. The reason why you only need to double JavaScript encode is that the <code>customFunction</code> function did not itself pass the input to another method which implicitly or explicitly called <code>eval()</code>. If "firstName" was passed to another JavaScript method which implicitly or explicitly called eval() then <code><%=doubleJavaScriptEncodedData%></code> above would need to be changed to <code><%=tripleJavaScriptEncodedData%></code>. 

An important implementation note is that if the JavaScript code tries to utilize the double or triple encoded data in string comparisons, the value may be interpreted as different values based on the number of evals() the data has passed through before being passed to the if comparison and the number of times the value was JavaScript encoded. 

If "A" is double JavaScript encoded then the following if check will return false. 

<code>
var x = "doubleJavaScriptEncodedA"; //\u005c\u0075\u0030\u0030\u0034\u0031
if (x == "A") {
alert("x is A");
} else if (x == "\u0041") {
alert("This is what pops");
}
</code>

This brings up an interesting design point. Ideally, the correct way to apply encoding and avoid the problem stated above is to server-side encode for the output context where data is introduced into the application. Then client-side encode (using a JavaScript encoding library such as ESAPI4JS) for the individual sub context (DOM methods) which untrusted data is passed to. ESAPI4JS (located at http://bit.ly/9hRTLH) 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. 
Here are some examples of how they are used: 
<code>
var input = “<%=Encoder.encodeForJS(untrustedData)%>”; //Server side encoding
</code>
<code>
window.location = ESAPI4JS.encodeForURL(input); //URL encoding is happening in JavaScript
</code>
<code>
document.writeln(ESAPI4JS.encodeForHTML(input)); //HTML encoding is happening in JavaScript
</code>

It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers. One option is to wait till ECMAScript 5 so the JavaScript library could support immutable properties. 
Another option provided by Gaz (Gareth) was to use a specific code construct to limit mutability with anonymous clousures. 

An example follows: 

<code>
function escapeHTML(str) {
str = str + "''";
var out = "''";
for(var i=0; i<str.length; i++) {
if(str[i] === '<') {
out += '&lt;';
} else if(str[i] === '>') {
out += '&gt;';
} else if(str[i] === "'") {
out += '&#39;';
} else if(str[i] === '"') {
out += '&quot;';
} else {
out += str[i];
}
}
return out;
}
</code>

 Chris Schmidt has put together another implementation of a JavaScript encoder at http://yet-another-dev.blogspot.com/2011/02/client-side-contextual-encoding-for.html. 

6. Limit the usage of dynamic untrusted data to right side operations. And be aware of data which may be passed to the application which look like code (eg. <code>location</code>, <code>eval()</code>). (Achim) 
<code>
var x = “<%=properly encoded data for flow%>”;
</code>

If you want to change different object attributes based on user input use a level of indirection. 

Instead of: 

<code>
window[userData] = “moreUserData”;
</code>

Do the following instead: 
<code>
if (userData===”location”) {
window.location = “static/path/or/properly/url/encoded/value”;
}
</code>

7. When URL encoding in DOM be aware of character set issues as the character set in JavaScript DOM is not clearly defined (Mike Samuel). 

8. Limit access to properties objects when using object[x] accessors. (Mike Samuel). In other words use a level of indirection between untrusted input and specified object properties. 
Here is an example of the problem when using map types: 
<code>
var myMapType = {};
myMapType[<%=untrustedData%>] = “moreUntrustedData”;
</code>

Although the developer writing the code above was trying to add additional keyed elements to the <code>myMapType</code> object. This could be used by an attacker to subvert internal and external attributes of the <code>myMapType</code> object. 

9. Run your JavaScript in a ECMAScript 5 canopy or sand box to make it harder for your JavaScript API to be compromised (Gareth Heyes and John Stevens). 

10. Don’t <code>eval()</code> JSON to convert it to native JavaScript objects. Instead use <code>JSON.toJSON()</code> and <code>JSON.parse()</code> (Chris Schmidt).

= Common Problems Associated with Mitgating DOM Based XSS =
==Complex Contexts==
In many cases the context isn’t always strait forward to discern. 
<code>
<a href=”javascript:myFunction(‘<%=untrustedData%>’, 'test');”>Click Me</a>
...
<script>
Function myFunction (url,name) {<
window.location = url;
}
</script>
</code>

In the above example, untrusted data started in the rendering URL context (<code>href</code> attribute of an <code><a></code> tag) then changed to a JavaScript execution context (<code>javascript:</code> protocol handler) which passed the untrusted data to an execution URL sub context (<code>window.location</code> of myFunction). Because the data was introduced in JavaScript code and passed to a URL sub context the appropriate server-side encoding would be the following: 

<code>
<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(Encoder.encodeForURL(untrustedData))%>’, 'test');”>Click Me</a>
…
</code>

Or if you were using ECMAScript 5 with an immutable JavaScript client-side encoding libraries you could do the following: 

<code>

<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(untrustedData)%>’, 'test');”>Click Me</a>
...
<script>
Function myFunction (url,name) {
var encodedURL = ESAPI4JS.encodeForURL(url); //URL encoding using client-side scripts
window.location = encodedURL;
}
</script>
</code>

== Insonsistencies of Encoding Libraries ==
There are a number of open source encoding libraries out there: 

#ESAPI
#Apache Commons String Utils
#Jtidy
#Your company’s custom implementation.

Some work on a black list others ignore important characters like “<” and “>”. ESAPI is one of the few which work on a whitelist and encode all non-alpha numeric characters.
It is important to use an encoding library which understands which characters can be used to exploit vulnerabilies in their respective contexts.
But there are misconceptions abound related to proper encoding.
==Encoding Misconceptions==
Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of “text/xhtml” or the file type extension of “*.xhtml” then HML encoding may not work to mitigate against XSS. 

For example: 

<code>
<script>
&#x61;lert(1);
</script>
</code>

The HTML encoded value above is still executable. If that isn’t enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element. 

Let’s look at the sample page and script: 

<code>
<form name=”myForm” …>
<input type=”text” name=”lName” value=”<%=Encoder.encodeForHTML(last_name)%>”>
…
</form>
<script>
var x = document.myForm.lName.value; //when the value is retrived the encoding is reversed
document.writeln(x); //any code passed into lName is now executable.
</script>
</code>

Finally there is the problem that certain methods in JavaScript which are usually safe can be unsafe in certain contexts. 

==Usually Safe Methods==

One example of an attribute which is usually safe is innerText. Some papers or guides advocate its use as an alternative to innerHTML to mitigate against XSS in innerHTML. However, depending on the tag which innerText is applied, code can be executed. 

<code>
<script>
var tag = document.createElement(“script”);
tag.innerText = “<%=untrustedData%>”; //executes code
</script>
</code>

 Special thanks to Jim Manico, Gareth Heyes, Stefano Di Paola, Robert Hansen, Mario Heiderich, Achim Hoffmann, John Stevens, Edwardo (SirDarkCat) Alberto Vela Nava, Chris Schmidt, Mike Samuel, Jeremy Long, Jeff Williams, and many others who help make this guide possible.

{{Cheatsheet_Navigation}}

[[Category:How To]]
[[Category:Cheatsheets]]

DOM based XSS Prevention Cheat Sheet

2011-02-23T01:35:28Z

Abraham Kang:

= Introduction =

When looking at XSS (Cross Site Scripting) there are three generally recognized forms of XSS. Reflected, Persisted, and DOM based XSS. The [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] has done an excellent job of addressing Reflected and Persisted XSS. This cheatsheet will address DOM (Document Object Model) based XSS and is an extension (as assumes comprehension of) the the [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] .

In order to understand DOM based XSS one needs to see the fundamental difference between reflected and persisted XSS when compared to DOM based XSS. Reflected and persisted XSS exist in a higher level rendering context and DOM based XSS is primarily found in a lower level execution context. A rendering context is associated with the parsing of HTML tags and their attributes. The HTML parser of the rendering context dictates how data is presented and laid out on the page and can be further broken down into the standard contexts of HTML, HTML attribute, URL, and CSS. The JavaScript or VBScript parser of an execution context is associated with the parsing and execution of script code. Each parser has distinct and separate semantics in the way they can possibly execute script code (XSS) which make creating consistent rules for mitigating both rendering and execution based contexts difficult. The complication is compounded by the differing meanings and treatment of encoded values within each sub context (HTML, HTML attribute, URL, and CSS) within the execution context.

This paper refers to the HTML, HTML attribute, URL, and CSS Cheatsheet contexts as subcontexts because each of these contexts can be reached and set within a JavaScript execution context. In JavaScript code the main context is JavaScript but since an attacker can try to attack the other 4 contexts using equivalent JavaScript DOM methods we refer to the other contexts besides the JavaScript context as sub contexts. 

The following example of an attack which occurs in the JavaScript context and HTML sub context: 

<code>
<script> 
var x = ‘<%= htmlAndJavaScriptEncodedVar %>’; 
var d = document.createElement(‘div’); 
d.innerHTML = x; 
document.body.appendChild(d); 
</script> 
</code>

One consistency, however, is the need to JavaScript encode in addition to the encoding required for the sub context in the execution context. Let’s look at the individual sub contexts of the execution context in turn.

= HTML Sub Context within the Execution Context =

There are several methods and attributes which can be used to directly render HTML content within JavaScript. These methods constitute the HTML Sub Context within the Execution Context.

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

==Methods==
<code>document.write(“<HTML> Tags and markup”);</code> 
<code>document.writeln(“<HTML> Tags and markup”);</code> 

==Guideline==
In a pure HTML execution context (not HTML Attribute) use HTML and JavaScript encoding to mitigate against attacks. 
<code>element.innerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;</code> 
<code>element.outerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;</code> 

==Methods==
<code>document.write(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);</code> 
<code>document.writeln(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);</code> 

= HTML Attribute Sub Context within the Execution Context =

The HTML attribute Sub Context within the Execution context is divergent from the standard encoding rules. This is because the rule to HTML attribute encode in an HTML attribute rendering context is mitigating attacks which try to exit out of the attribute to add additional attributes and/or tags which could have executable code. When you are in a DOM execution context you only need to JavaScript encode HTML attributes which do not execute code (attributes other than event handler, CSS, and URL attributes).

For example, the general rule is to HTML Attribute encode untrusted data (data from the database, http request, user, backend 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.

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

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.

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

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.

= URL Attribute Sub Context 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.

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

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.

=CSS Attribute Sub Context 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.

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

TODO: We have not been able to get the expression() function working from DOM JavaScript code. Need some help.

=Event Handler and JavaScript code Sub Contexts 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.

<code>var x = document.createElement("a"); </code> 
<code>x.href="#”;</code> 
<code>x.setAttribute("onclick", "\u0061\u006c\u0065\u0072\u0074\u0028\u0032\u0032\u0029");</code> 
<code>var y = document.createTextNode("Click To Test"); </code> 
<code>x.appendChild(y);</code> 
<code>document.body.appendChild(x);</code> 

JavaScript event handler methods are dangerous because they implicitly do an eval() on the data passed to the DOM attribute. There are other places in JavaScript where JavaScript encoding is accepted as valid executable code.

<code>for ( var \u0062=0; \u0062 < 10; \u0062++){</code> 
<code> \u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074 </code> 
<code> .\u0077\u0072\u0069\u0074\u0065\u006c\u006e</code> 
<code> ("\u0048\u0065\u006c\u006c\u006f\u0020\u0057\u006f\u0072\u006c\u0064");</code> 
<code>} </code> 
<code>\u0077\u0069\u006e\u0064\u006f\u0077</code> 
<code>.\u0065\u0076\u0061\u006c (</code> 
<code>\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074</code> 
<code>.\u0077\u0072\u0069\u0074\u0065(111111111));</code> 

or

<code>var s = "\u0065\u0076\u0061\u006c"; </code> 
<code>var t = "\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029";</code> 
<code>window[s](t);</code> 

Because JavaScript is based on an international standard (ECMAScript), JavaScript encoding enables the support of international characters in programming constructs and variables in addition to alternate string representations (string escapes).

However the opposite is the case with HTML encoding. HTML tag elements are well defined and do not support alternate representations of the same tag. So HTML encoding cannot be used to allow the developer to have alternate representations of the <a> tag for example.

==HTML Encoding’s Disarming Nature==

In general, HTML encoding serves to castrate HTML tags which are placed in HTML and HTML attribute contexts.
Working example (no HTML encoding):

<code><a href=”…” ></code> 

Normally encoded example (Does Not Work – DNW):

<code>&#x3c;a href=… &#x3e;</code> 

HTML encoded example to highlight a fundamental difference with JavaScript encoded values (DNW):

<code><&#x61; href=…></code> 

If HTML encoding followed the same semantics as JavaScript encoding. The line above could have possibily worked to render a link. This difference makes JavaScript encoding a less viable weapon in our fight against XSS.

=Guidelines for Developing Secure Applications Utilizing JavaScript=

DOM based XSS is extremely difficult to mitigate against because of its large attack surface and lack of standardization across browsers. The guidelines below are an attempt to provide guidelines for developers when developing Web based JavaScript applications (Web 2.0) such that they can avoid XSS.

1. Untrusted data should only be treatedas 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) 
<code>var x = “<%=encodedJavaScriptData%>”;</code> 
3. Use document.createElement(“…”), element.setAttribute(“…”,”value”), element.appendChild(…), etc. to build dynamic interfaces. Avoid use of HTML rendering methods: 
#<code>element.innerHTML = “…”; </code>
#<code>element.outerHTML = “…”; </code>
#<code>document.write(…); </code>
#<code>document.writeln(…); </code> 
4. Understand the dataflow of untrusted data through your JavaScript code. If you do have to use the methods above remember to HTML and them JavaScript encode the untrusted data (Stefano Di Paola). 
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. 

Utilizing an Enclosure (as suggested by Gaz)

The example that follows illustrates using closures to avoid double JavaScript encoding.

<code>setTimeout((function(param) { return function() {</code> 
<code> customFunction(param);</code> 
<code> }</code> 
<code>})("<%=Encoder.encodeForJS(untrustedData)%>"), y);</code> 
 
The other alternative is using N-levels of encoding. 

N-Levels of Encoding 

If your code looked like the following, you would need to only double JavaScript encode input data.

<code>setTimeout(“customFunction(‘<%=doubleJavaScriptEncodedData%>’, y)”);</code> 
<code>function customFunction (firstName, lastName) {</code> 
<code> alert("Hello" + firstName + " " + lastNam);</code> 
<code>}</code> 

The doubleJavaScriptEncodedData has its first layer of JavaScript encoding reversed in the single quotes. Then the implicit eval() of setTimeout reverses another layer of JavaScript encoding to pass the correct value to "customFunction". The reason why you only need to double JavaScript encode is that the "customFunction" function did not itself pass the input to another method which implicitly or explicitly called eval(). If "firstName" was passed to another JavaScript method which implicitly or explicitly called eval() then "<%=doubleJavaScriptEncodedData%>" above would need to be changed to "<%=tripleJavaScriptEncodedData%>". 

An important implementation note is that if the JavaScript code tries to utilize the double or triple encoded data in string comparisons, the value may be interpreted as different values based on the number of evals() the data has passed through before being passed to the if comparison and the number of times the value was JavaScript encoded. 

If "A" is double JavaScript encoded then the following if check will return false. 

<code>var x = "doubleJavaScriptEncodedA"; //\u005c\u0075\u0030\u0030\u0034\u0031</code> 
<code>if (x == "A") { </code> 
<code> alert("x is A"); </code> 
<code>} else if (x == "\u0041") { </code> 
<code> alert("This is what pops");</code> 
<code>} </code> 
This brings up an interesting design point. Ideally, the correct way to apply encoding and avoid the problem stated above is to server side encode for the output context where data is introduced into the application. Then client-side encode (using a JavaScript encoding library) for the individual sub context (DOM methods) which untrusted data is passed to. 
Here is an example: 
<code>
var input = “<%=Encoder.encodeForJS(untrustedData)%>”; //Server side encoding</code> 
<code>
window.location = ESAPI4JS.encodeForURL(input); //URL encoding is happing in JavaScript</code> 
<code>
document.writeln(ESAPI4JS.encodeForHTML(input)); //HTML encoding is happing in JavaScript
</code> 
It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers. One option is to wait till ECMAScript 5 so the JavaScript library could support immutable properties. 
Another option provided by Gaz (Gareth) was to use a specific code construct to limit mutability with anonymous clousures. 

An example follows: 

<code>function escapeHTML(str) {</code> 
<code> str = str + "''";</code> 
<code> var out = "''";</code> 
<code> for(var i=0;i<str.length;i++) {</code> 
<code> if(str[i] === '<') {</code> 
<code> out += '&lt;';</code> 
<code> } else if(str[i] === '>') {</code> 
<code> out += '&gt;';</code> 
<code> } else if(str[i] === "'") {</code> 
<code> out += '&#39;'; </code> 
<code> } else if(str[i] === '"') {</code> 
<code> out += '&quot;'; </code> 
<code> } else {</code> 
<code> out += str[i];</code> 
<code> }</code> 
<code> }</code> 
<code> return out;</code> 
<code> }</code> 

 Chris Schmidt has put together another implementation of a JavaScript encoder at http://yet-another-dev.blogspot.com/2011/02/client-side-contextual-encoding-for.html. 

6. Limit the usage of dynamic untrusted data to right side operations. And be aware of data which may be passed to the application which look like code (eg. “location”, “eval”). (Achim) 
<code>
var x = “<%=properly encoded data for flow%>”; </code> 

If you want to change different object attributes based on user input use a level of indirection. 

Instead of: 

<code>window[userData] = “moreUserData”; </code> 

Do the following instead: 
<code>if (userData===”location”) { </code> 
<code>window.location = “static/path/or/properly/url/encoded/value”; </code> 

7. When URL encoding in DOM be aware of character set issues as the character set in JavaScript DOM is not clearly defined (Mike Samuel). 

8. Limit access to properties objects when using object[x] accessors. (Mike Samuel). In other words use a level of indirection between untrusted input and specified object properties. 
Here is an example of the problem when using map types: 
<code>
Var myMapType = {};
myMapType[<%=untrustedData%>] = “moreUntrustedData”;
</code> 

Although the developer writing the code above was trying to add additional keyed elements to the “myMapType” object. This could be used by an attacker to subvert internal and external attributes of the “myMapType” object. 

9. Run your JavaScript in a ECMAScript 5 canopy or sand box to make it harder for your JavaScript API to be compromised (Gareth Heyes and John Stevens). 

10. Don’t eval() JSON to convert it to native JavaScript objects. Instead use JSON.toJSON() and JSON.parse() (Chris Schmidt).

= Common Problems Associated with Mitgating DOM Based XSS =
==Complex Contexts==
In many cases the context isn’t always strait forward to discern. 
<code>
<a href=”javascript:myFunction(‘<%=untrustedData%>’, “test”);”>Click Me</a></code> 
<code>…</code> 
<code><script></code> 
<code>Function myFunction (url,name) {</code> 
<code> window.location = url;</code> 
<code>}</code> 
<code></script></code> 

In the above example, untrusted data started in the rendering URL context (href attribute of an <a> tag) then changed to a JavaScript execution context (javascript: protocol handler) which passed the untrusted data to an execution URL sub context (window.location of myFunction). Because the data was introduced in JavaScript code and passed to a URL sub context the appropriate server side encoding would be the following: 

<code>
<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(Encoder.encodeForURL(untrustedData))%>’, “test”);”>Click Me</a></code> 
<code>…</code> 

Or if you were using ECMAScript 5 with an immutable JavaScript client-side encoding libraries you could do the following: 

<code>
</code> 
<code><a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(untrustedData)%>’, “test”);”>Click Me</a></code> 
<code>…</code> 
<code><script></code> 
<code>Function myFunction (url,name) {</code> 
<code> var encodedURL = ESAPI4JS.encodeForURL(url); //URL encoding using client-side scripts</code> 
<code> window.location = encodedURL;</code> 
<code>}</code> 
<code></script></code> 

== Insonsistencies of Encoding Libraries ==
There are a number of open source encoding libraries out there: 

#ESAPI
#Apache Commons String Utils
#Jtidy
#Your company’s custom implementation.

Some work on a black list others ignore important characters like “<” and “>”. ESAPI is one of the few which work on a whitelist and encode all non-alpha numeric characters.
It is important to use an encoding library which understands which characters can be used to exploit vulnerabilies in their respective contexts.
But there are misconceptions abound related to proper encoding.
==Encoding Misconceptions==
Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of “text/xhtml” or the file type extension of “*.xhtml” then HML encoding may not work to mitigate against XSS. 

For example: 

<code>
<script>
&#x61;lert(1);
</script>
</code> 
 
The HTML encoded value above is still executable. If that isn’t enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element. 

Let’s look at the sample page and script: 

<code><form name=”myForm” …></code> 
<code><input type=”text” name=”lName” value=”<%=Encoder.encodeForHTML(last_name)%>”></code> 
<code>
…</code> 
<code></form></code> 
<code><script></code> 
<code>var x = document.myForm.lName.value; //when the value is retrived the encoding is reversed</code> 
<code>document.writeln(x); //any code passed into lName is now executable.</code> 
<code></script></code> 

Finally there is the problem that certain methods in JavaScript which are usually safe can be unsafe in certain contexts. 

==Usually Safe Methods==

One example of an attribute which is usually safe is innerText. Some papers or guides advocate its use as an alternative to innerHTML to mitigate against XSS in innerHTML. However, depending on the tag which innerText is applied, code can be executed. 

<code><script></code> 
<code>var tag = document.createElement(“script”);</code> 
<code>tag.innerText = “<%=untrustedData%>”; //executes code</code> 
<code></script></code> 

 Special thanks to Jim Manico, Gareth Heyes, Stefano Di Paola, Robert Hansen, Mario Heiderich, Achim Hoffmann, John Stevens, Edwardo (SirDarkCat) Alberto Vela Nava, Chris Schmidt, Mike Samuel, Jeremy Long, Jeff Williams, and many others who help make this guide possible.

{{Cheatsheet_Navigation}}

[[Category:How To]]
[[Category:Cheatsheets]]

DOM based XSS Prevention Cheat Sheet

2011-02-21T04:01:55Z

Abraham Kang:

= Introduction =

When looking at XSS (Cross Site Scripting) there are three generally recognized forms of XSS. Reflected, Persisted, and DOM based XSS. The [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] has done an excellent job of addressing Reflected and Persisted XSS. This cheatsheet will address DOM (Document Object Model) based XSS and is an extension (as assumes comprehension of) the the [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] .

In order to understand DOM based XSS one needs to see the fundamental difference between reflected and persisted XSS when compared to DOM based XSS. Reflected and persisted XSS exist in a higher level rendering context and DOM based XSS is primarily found in a lower level execution context. A rendering context is associated with the parsing of HTML tags and their attributes. The HTML parser of the rendering context dictates how data is presented and laid out on the page and can be further broken down into the standard contexts of HTML, HTML attribute, URL, and CSS. The JavaScript or VBScript parser of an execution context is associated with the parsing and execution of script code. Each parser has distinct and separate semantics in the way they can possibly execute script code (XSS) which make creating consistent rules for mitigating both rendering and execution based contexts difficult. The complication is compounded by the differing meanings and treatment of encoded values within each sub context (HTML, HTML attribute, URL, and CSS) within the execution context.

This paper refers to the HTML, HTML attribute, URL, and CSS Cheatsheet contexts as subcontexts because each of these contexts can be reached and set within a JavaScript execution context. In JavaScript code the main context is JavaScript but since an attacker can try to attack the other 4 contexts using equivalent JavaScript DOM methods we refer to the other contexts besides the JavaScript context as sub contexts. 

The following example of an attack which occurs in the JavaScript context and HTML sub context: 

<code>
<script> 
var x = ‘<%= htmlAndJavaScriptEncodedVar %>’; 
var d = document.createElement(‘div’); 
d.innerHTML = x; 
document.body.appendChild(d); 
</script> 
</code>

One consistency, however, is the need to JavaScript encode in addition to the encoding required for the sub context in the execution context. Let’s look at the individual sub contexts of the execution context in turn.

= HTML Sub Context within the Execution Context =

There are several methods and attributes which can be used to directly render HTML content within JavaScript. These methods constitute the HTML Sub Context within the Execution Context.

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

==Methods==
<code>document.write(“<HTML> Tags and markup”);</code> 
<code>document.writeln(“<HTML> Tags and markup”);</code> 

==Guideline==
In a pure HTML execution context (not HTML Attribute) use HTML and JavaScript encoding to mitigate against attacks. 
<code>element.innerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;</code> 
<code>element.outerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;</code> 

==Methods==
<code>document.write(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);</code> 
<code>document.writeln(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);</code> 

= HTML Attribute Sub Context within the Execution Context =

The HTML attribute Sub Context within the Execution context is divergent from the standard encoding rules. This is because the rule to HTML attribute encode in an HTML attribute rendering context is mitigating attacks which try to exit out of the attribute to add additional attributes and/or tags which could have executable code. When you are in a DOM execution context you only need to JavaScript encode HTML attributes which do not execute code (attributes other than event handler, CSS, and URL attributes).

For example, the general rule is to HTML Attribute encode untrusted data (data from the database, http request, user, backend 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.

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

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.

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

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.

= URL Attribute Sub Context 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.

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

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.

=CSS Attribute Sub Context 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.

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

TODO: We have not been able to get the expression() function working from DOM JavaScript code. Need some help.

=Event Handler and JavaScript code Sub Contexts 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.

<code>var x = document.createElement("a"); </code> 
<code>x.href="#”;</code> 
<code>x.setAttribute("onclick", "\u0061\u006c\u0065\u0072\u0074\u0028\u0032\u0032\u0029");</code> 
<code>var y = document.createTextNode("Click To Test"); </code> 
<code>x.appendChild(y);</code> 
<code>document.body.appendChild(x);</code> 

JavaScript event handler methods are dangerous because they implicitly do an eval() on the data passed to the DOM attribute. There are other places in JavaScript where JavaScript encoding is accepted as valid executable code.

<code>for ( var \u0062=0; \u0062 < 10; \u0062++){</code> 
<code> \u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074 </code> 
<code> .\u0077\u0072\u0069\u0074\u0065\u006c\u006e</code> 
<code> ("\u0048\u0065\u006c\u006c\u006f\u0020\u0057\u006f\u0072\u006c\u0064");</code> 
<code>} </code> 
<code>\u0077\u0069\u006e\u0064\u006f\u0077</code> 
<code>.\u0065\u0076\u0061\u006c (</code> 
<code>\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074</code> 
<code>.\u0077\u0072\u0069\u0074\u0065(111111111));</code> 

or

<code>var s = "\u0065\u0076\u0061\u006c"; </code> 
<code>var t = "\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029";</code> 
<code>window[s](t);</code> 

Because JavaScript is based on an international standard (ECMAScript), JavaScript encoding enables the support of international characters in programming constructs and variables in addition to alternate string representations (string escapes).

However the opposite is the case with HTML encoding. HTML tag elements are well defined and do not support alternate representations of the same tag. So HTML encoding cannot be used to allow the developer to have alternate representations of the <a> tag for example.

==HTML Encoding’s Disarming Nature==

In general, HTML encoding serves to castrate HTML tags which are placed in HTML and HTML attribute contexts.
Working example (no HTML encoding):

<code><a href=”…” ></code> 

Normally encoded example (Does Not Work – DNW):

<code>&#x3c;a href=… &#x3e;</code> 

HTML encoded example to highlight a fundamental difference with JavaScript encoded values (DNW):

<code><&#x61; href=…></code> 

If HTML encoding followed the same semantics as JavaScript encoding. The line above could have possibily worked to render a link. This difference makes JavaScript encoding a less viable weapon in our fight against XSS.

=Guidelines for Developing Secure Applications Utilizing JavaScript=

DOM based XSS is extremely difficult to mitigate against because of its large attack surface and lack of standardization across browsers. The guidelines below are an attempt to provide guidelines for developers when developing Web based JavaScript applications (Web 2.0) such that they can avoid XSS.

1. Untrusted data should only be treatedas 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) 
<code>var x = “<%=encodedJavaScriptData%>”;</code> 
3. Use document.createElement(“…”), element.setAttribute(“…”,”value”), element.appendChild(…), etc. to build dynamic interfaces. Avoid use of HTML rendering methods: 
#<code>element.innerHTML = “…”; </code>
#<code>element.outerHTML = “…”; </code>
#<code>document.write(…); </code>
#<code>document.writeln(…); </code> 
4. Understand the dataflow of untrusted data through your JavaScript code. If you do have to use the methods above remember to HTML and them JavaScript encode the untrusted data (Stefano Di Paola). 
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. 

Utilizing an Enclosure (as suggested by Gaz)

The example that follows illustrates using closures to avoid double JavaScript encoding.

<code>setTimeout((function(param) { return function() {</code> 
<code> customFunction(param);</code> 
<code> }</code> 
<code>})("<%=Encoder.encodeForJS(untrustedData)%>"), y);</code> 
 
The other alternative is using N-levels of encoding. 

N-Levels of Encoding 

If your code looked like the following, you would need to only double JavaScript encode input data.

<code>setTimeout(“customFunction(‘<%=doubleJavaScriptEncodedData%>’, y)”);</code> 
<code>function customFunction (firstName, lastName) {</code> 
<code> alert("Hello" + firstName + " " + lastNam);</code> 
<code>}</code> 

The doubleJavaScriptEncodedData has its first layer of JavaScript encoding reversed in the single quotes. Then the implicit eval() of setTimeout reverses another layer of JavaScript encoding to pass the correct value to "customFunction". The reason why you only need to double JavaScript encode is that the "customFunction" function did not itself pass the input to another method which implicitly or explicitly called eval(). If "firstName" was passed to another JavaScript method which implicitly or explicitly called eval() then "<%=doubleJavaScriptEncodedData%>" above would need to be changed to "<%=tripleJavaScriptEncodedData%>". 

An important implementation note is that if the JavaScript code tries to utilize the double or triple encoded data in string comparisons, the value may be interpreted as different values based on the number of evals() the data has passed through before being passed to the if comparison and the number of times the value was JavaScript encoded. 

If "A" is double JavaScript encoded then the following if check will return false. 

<code>var x = "doubleJavaScriptEncodedA"; //\u005c\u0075\u0030\u0030\u0034\u0031</code> 
<code>if (x == "A") { </code> 
<code> alert("x is A"); </code> 
<code>} else if (x == "\u0041") { </code> 
<code> alert("This is what pops");</code> 
<code>} </code> 
This brings up an interesting design point. Ideally, the correct way to apply encoding and avoid the problem stated above is to server side encode for the output context where data is introduced into the application. Then client-side encode (using a JavaScript encoding library) for the individual sub context (DOM methods) which untrusted data is passed to. 
Here is an example: 
<code>
var input = “<%=Encoder.encodeForJS(untrustedData)%>”; //Server side encoding</code> 
<code>
window.location = ESAPI4JS.encodeForURL(input); //URL encoding is happing in JavaScript</code> 
<code>
document.writeln(ESAPI4JS.encodeForHTML(input)); //HTML encoding is happing in JavaScript
</code> 
It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers. One option is to wait till ECMAScript 5 so the JavaScript library could support immutable properties. 
Another option provided by Gaz (Gareth) was to use a specific code construct to limit mutability with anonymous clousures. 

An example follows: 

<code>function escapeHTML(str) {</code> 
<code> str = str + "''";</code> 
<code> var out = "''";</code> 
<code> for(var i=0;i<str.length;i++) {</code> 
<code> if(str[i] === '<') {</code> 
<code> out += '&lt;';</code> 
<code> } else if(str[i] === '>') {</code> 
<code> out += '&gt;';</code> 
<code> } else if(str[i] === "'") {</code> 
<code> out += '&#39;'; </code> 
<code> } else if(str[i] === '"') {</code> 
<code> out += '&quot;'; </code> 
<code> } else {</code> 
<code> out += str[i];</code> 
<code> }</code> 
<code> }</code> 
<code> return out;</code> 
<code> }</code> 

 Chris Schmidt has put together another implementation of a JavaScript encoder at http://yet-another-dev.blogspot.com/2011/02/client-side-contextual-encoding-for.html. 

6. Limit the usage of dynamic untrusted data to right side operations. And be aware of data which may be passed to the application which look like code (eg. “location”, “eval”). (Achim) 
<code>
var x = “<%=properly encoded data for flow%>”; </code> 

If you want to change different object attributes based on user input use a level of indirection. 

Instead of: 

<code>window[userData] = “moreUserData”; </code> 

Do the following instead: 
<code>if (userData===”location”) { </code> 
<code>window.location = “static/path/or/properly/url/encoded/value”; </code> 

7. When URL encoding in DOM be aware of character set issues as the character set in JavaScript DOM is not clearly defined (Mike Samuel). 

8. Limit access to properties objects when using object[x] accessors. (Mike Samuel). In other words use a level of indirection between untrusted input and specified object properties. 
Here is an example of the problem when using map types: 
<code>
Var myMapType = {};
myMapType[<%=untrustedData%>] = “moreUntrustedData”;
</code> 

Although the developer writing the code above was trying to add additional keyed elements to the “myMapType” object. This could be used by an attacker to subvert internal and external attributes of the “myMapType” object. 

9. Run your JavaScript in a ECMAScript 5 canopy or sand box to make it harder for your JavaScript API to be compromised (Gareth Heyes and John Stevens). 

10. Don’t eval() JSON to convert it to native JavaScript objects. Instead use JSON.toJSON() and JSON.parse() (Chris Schmidt).

= Common Problems Associated with Mitgating DOM Based XSS =
==Complex Contexts==
In many cases the context isn’t always strait forward to discern. 
<code>
<a href=”javascript:myFunction(‘<%=untrustedData%>’, “test”);”>Click Me</a></code> 
<code>…</code> 
<code><script></code> 
<code>Function myFunction (url,name) {</code> 
<code> window.location = url;</code> 
<code>}</code> 
<code></script></code> 

In the above example, untrusted data started in the rendering URL context (href attribute of an <a> tag) then changed to a JavaScript execution context (javascript: protocol handler) which passed the untrusted data to an execution URL sub context (window.location of myFunction). Because the data was introduced in JavaScript code and passed to a URL sub context the appropriate server side encoding would be the following: 

<code>
<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(Encoder.encodeForURL(untrustedData))%>’, “test”);”>Click Me</a></code> 
<code>…</code> 

Or if you were using ECMAScript 5 with an immutable JavaScript client-side encoding libraries you could do the following: 

<code>
</code> 
<code><a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(untrustedData)%>’, “test”);”>Click Me</a></code> 
<code>…</code> 
<code><script></code> 
<code>Function myFunction (url,name) {</code> 
<code> var encodedURL = ESAPI4JS.encodeForURL(url); //URL encoding using client-side scripts</code> 
<code> window.location = encodedURL;</code> 
<code>}</code> 
<code></script></code> 

== Insonsistencies of Encoding Libraries ==
There are a number of open source encoding libraries out there: 

#ESAPI
#Apache Commons String Utils
#Jtidy
#Your company’s custom implementation.

Some work on a black list others ignore important characters like “<” and “>”. ESAPI is one of the few which work on a whitelist and encode all non-alpha numeric characters.
It is important to use an encoding library which understands which characters can be used to exploit vulnerabilies in their respective contexts.
But there are misconceptions abound related to proper encoding.
==Encoding Misconceptions==
Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of “text/xhtml” or the file type extension of “*.xhtml” then HML encoding may not work to mitigate against XSS. 

For example: 

<code>
<script>
&#x61;lert(1);
</script>
</code> 
 
The HTML encoded value above is still executable. If that isn’t enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element. 

Let’s look at the sample page and script: 

<code><form name=”myForm” …></code> 
<code><input type=”text” name=”lName” value=”<%=Encoder.encodeForHTML(last_name)%>”></code> 
<code>
…</code> 
<code></form></code> 
<code><script></code> 
<code>var x = document.myForm.lName.value; //when the value is retrived the encoding is reversed</code> 
<code>document.writeln(x); //any code passed into lName is now executable.</code> 
<code></script></code> 

Finally there is the problem that certain methods in JavaScript which are usually safe can be unsafe in certain contexts. 

==Usually Safe Methods==

One example of an attribute which is usually safe is innerText. Some papers or guides advocate its use as an alternative to innerHTML to mitigate against XSS in innerHTML. However, depending on the tag which innerText is applied, code can be executed. 

<code><script></code> 
<code>var tag = document.createElement(“script”);</code> 
<code>tag.innerText = “<%=untrustedData%>”; //executes code</code> 
<code></script></code> 

 Special thanks to Jim Manico, Gareth Heyes, Stefano Di Paola, Robert Hansen, Mario Heiderich, Achim Hoffmann, John Stevens, Edwardo (SirDarkCat) Alberto Vela Nava, Chris Schmidt, Mike Samuel, Jeremy Long, Jeff Williams, and many others who help make this guide possible.

{{Cheatsheet_Navigation}}

[[Category:How To]]
[[Category:Cheatsheets]]

DOM based XSS Prevention Cheat Sheet

2011-02-21T03:47:33Z

Abraham Kang:

= Introduction =

When looking at XSS (Cross Site Scripting) there are three generally recognized forms of XSS. Reflected, Persisted, and DOM based XSS. The [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] has done an excellent job of addressing Reflected and Persisted XSS. This cheatsheet will address DOM (Document Object Model) based XSS and is an extension (as assumes comprehension of) the the [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] .

In order to understand DOM based XSS one needs to see the fundamental difference between reflected and persisted XSS when compared to DOM based XSS. Reflected and persisted XSS exist in a higher level rendering context and DOM based XSS is primarily found in a lower level execution context. A rendering context is associated with the parsing of HTML tags and their attributes. The HTML parser of the rendering context dictates how data is presented and laid out on the page and can be further broken down into the standard contexts of HTML, HTML attribute, URL, and CSS. The JavaScript or VBScript parser of an execution context is associated with the parsing and execution of script code. Each parser has distinct and separate semantics in the way they can possibly execute script code (XSS) which make creating consistent rules for mitigating both rendering and execution based contexts difficult. The complication is compounded by the differing meanings and treatment of encoded values within each sub context (HTML, HTML attribute, URL, and CSS) within the execution context.

This paper refers to the HTML, HTML attribute, URL, and CSS Cheatsheet contexts as subcontexts because each of these contexts can be reached and set within a JavaScript execution context. In JavaScript code the main context is JavaScript but since an attacker can try to attack the other 4 contexts using equivalent JavaScript DOM methods we refer to the other contexts besides the JavaScript context as sub contexts. 

The following example of an attack which occurs in the JavaScript context and HTML sub context: 

<code>
<script> 
var x = ‘<%= htmlAndJavaScriptEncodedVar %>’; 
var d = document.createElement(‘div’); 
d.innerHTML = x; 
document.body.appendChild(d); 
</script> 
</code>

One consistency, however, is the need to JavaScript encode in addition to the encoding required for the sub context in the execution context. Let’s look at the individual sub contexts of the execution context in turn.

= HTML Sub Context within the Execution Context =

There are several methods and attributes which can be used to directly render HTML content within JavaScript. These methods constitute the HTML Sub Context within the Execution Context.

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

==Methods==
<code>document.write(“<HTML> Tags and markup”);</code> 
<code>document.writeln(“<HTML> Tags and markup”);</code> 

==Guideline==
In a pure HTML execution context (not HTML Attribute) use HTML and JavaScript encoding to mitigate against attacks. 
<code>element.innerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;</code> 
<code>element.outerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;</code> 

==Methods==
<code>document.write(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);</code> 
<code>document.writeln(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);</code> 

= HTML Attribute Sub Context within the Execution Context =

The HTML attribute Sub Context within the Execution context is divergent from the standard encoding rules. This is because the rule to HTML attribute encode in an HTML attribute rendering context is mitigating attacks which try to exit out of the attribute to add additional attributes and/or tags which could have executable code. When you are in a DOM execution context you only need to JavaScript encode HTML attributes which do not execute code (attributes other than event handler, CSS, and URL attributes).

For example, the general rule is to HTML Attribute encode untrusted data (data from the database, http request, user, backend 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.

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

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.

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

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.

= URL Attribute Sub Context 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.

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

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.

=CSS Attribute Sub Context 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.

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

TODO: We have not been able to get the expression() function working from DOM JavaScript code. Need some help.

=Event Handler and JavaScript code Sub Contexts 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.

<code>var x = document.createElement("a"); </code> 
<code>x.href="#”;</code> 
<code>x.setAttribute("onclick", "\u0061\u006c\u0065\u0072\u0074\u0028\u0032\u0032\u0029");</code> 
<code>var y = document.createTextNode("Click To Test"); </code> 
<code>x.appendChild(y);</code> 
<code>document.body.appendChild(x);</code> 

JavaScript event handler methods are dangerous because they implicitly do an eval() on the data passed to the DOM attribute. There are other places in JavaScript where JavaScript encoding is accepted as valid executable code.

<code>for ( var \u0062=0; \u0062 < 10; \u0062++){</code> 
<code> \u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074 </code> 
<code> .\u0077\u0072\u0069\u0074\u0065\u006c\u006e</code> 
<code> ("\u0048\u0065\u006c\u006c\u006f\u0020\u0057\u006f\u0072\u006c\u0064");</code> 
<code>} </code> 
<code>\u0077\u0069\u006e\u0064\u006f\u0077</code> 
<code>.\u0065\u0076\u0061\u006c (</code> 
<code>\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074</code> 
<code>.\u0077\u0072\u0069\u0074\u0065(111111111));</code> 

or

<code>var s = "\u0065\u0076\u0061\u006c"; </code> 
<code>var t = "\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029";</code> 
<code>window[s](t);</code> 

Because JavaScript is based on an international standard (ECMAScript), JavaScript encoding enables the support of international characters in programming constructs and variables in addition to alternate string representations (string escapes).

However the opposite is the case with HTML encoding. HTML tag elements are well defined and do not support alternate representations of the same tag. So HTML encoding cannot be used to allow the developer to have alternate representations of the <a> tag for example.

==HTML Encoding’s Disarming Nature==

In general, HTML encoding serves to castrate HTML tags which are placed in HTML and HTML attribute contexts.
Working example (no HTML encoding):

<code><a href=”…” ></code> 

Normally encoded example (Does Not Work – DNW):

<code>&#x3c;a href=… &#x3e;</code> 

HTML encoded example to highlight a fundamental difference with JavaScript encoded values (DNW):

<code><&#x61; href=…></code> 

If HTML encoding followed the same semantics as JavaScript encoding. The line above could have possibily worked to render a link. This difference makes JavaScript encoding a less viable weapon in our fight against XSS.

=Guidelines for Developing Secure Applications Utilizing JavaScript=

DOM based XSS is extremely difficult to mitigate against because of its large attack surface and lack of standardization across browsers. The guidelines below are an attempt to provide guidelines for developers when developing Web based JavaScript applications (Web 2.0) such that they can avoid XSS.

1. Untrusted data should only be treatedas 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) 
<code>var x = “<%=encodedJavaScriptData%>”;</code> 
3. Use document.createElement(“…”), element.setAttribute(“…”,”value”), element.appendChild(…), etc. to build dynamic interfaces. Avoid use of HTML rendering methods: 
#<code>element.innerHTML = “…”; </code>
#<code>element.outerHTML = “…”; </code>
#<code>document.write(…); </code>
#<code>document.writeln(…); </code> 
4. Understand the dataflow of untrusted data through your JavaScript code. If you do have to use the methods above remember to HTML and them JavaScript encode the untrusted data (Stefano Di Paola). 
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, 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. 

N-Levels of Encoding 

If your code looked like the following, you would need to only double JavaScript encode input data.

<code>setTimeout(“customFunction(‘<%=doubleJavaScriptEncodedData%>’, y)”);</code> 
<code>function customFunction (firstName, lastName) {</code> 
<code> alert("Hello" + firstName + " " + lastNam);</code> 
<code>}</code> 

The doubleJavaScriptEncodedData has its first layer of JavaScript encoding reversed in the single quotes. Then the implicit eval() of setTimeout reverses another layer of JavaScript encoding to pass the correct value to "customFunction". The reason why you only need to double JavaScript encode is that the "customFunction" function did not itself pass the input to another method which implicitly or explicitly called eval(). If "firstName" was passed to another JavaScript method which implicitly or explicitly called eval() then "<%=doubleJavaScriptEncodedData%>" above would need to be changed to "<%=tripleJavaScriptEncodedData%>". 

An important implementation note is that if the JavaScript code tries to utilize the double or triple encoded data in string comparisons, the value may be interpreted as different values based on the number of evals() the data has passed through before being passed to the if comparison and the number of times the value was JavaScript encoded. 

If "A" is double JavaScript encoded then the following if check will return false. 

<code>var x = "doubleJavaScriptEncodedA"; //\u005c\u0075\u0030\u0030\u0034\u0031</code> 
<code>if (x == "A") { </code> 
<code> alert("x is A"); </code> 
<code>} else if (x == "\u0041") { </code> 
<code> alert("This is what pops");</code> 
<code>} </code> 
This brings up an interesting design point. Ideally, the correct way to apply encoding and avoid the problem stated above is to server side encode for the output context where data is introduced into the application. Then client-side encode (using a JavaScript encoding library) for the individual sub context (DOM methods) which untrusted data is passed to. 
Here is an example: 
<code>
var input = “<%=Encoder.encodeForJS(untrustedData)%>”; //Server side encoding</code> 
<code>
window.location = ESAPI4JS.encodeForURL(input); //URL encoding is happing in JavaScript</code> 
<code>
document.writeln(ESAPI4JS.encodeForHTML(input)); //HTML encoding is happing in JavaScript
</code> 
It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers. One option is to wait till ECMAScript 5 so the JavaScript library could support immutable properties. 
Another option provided by Gaz (Gareth) was to use a specific code construct to limit mutability with anonymous clousures. 

An example follows: 

<code>function escapeHTML(str) {</code> 
<code> str = str + "''";</code> 
<code> var out = "''";</code> 
<code> for(var i=0;i<str.length;i++) {</code> 
<code> if(str[i] === '<') {</code> 
<code> out += '&lt;';</code> 
<code> } else if(str[i] === '>') {</code> 
<code> out += '&gt;';</code> 
<code> } else if(str[i] === "'") {</code> 
<code> out += '&#39;'; </code> 
<code> } else if(str[i] === '"') {</code> 
<code> out += '&quot;'; </code> 
<code> } else {</code> 
<code> out += str[i];</code> 
<code> }</code> 
<code> }</code> 
<code> return out;</code> 
<code> }</code> 

 Chris Schmidt has put together another implementation of a JavaScript encoder at http://yet-another-dev.blogspot.com/2011/02/client-side-contextual-encoding-for.html. 

6. Limit the usage of dynamic untrusted data to right side operations. And be aware of data which may be passed to the application which look like code (eg. “location”, “eval”). (Achim) 
<code>
var x = “<%=properly encoded data for flow%>”; </code> 

If you want to change different object attributes based on user input use a level of indirection. 

Instead of: 

<code>window[userData] = “moreUserData”; </code> 

Do the following instead: 
<code>if (userData===”location”) { </code> 
<code>window.location = “static/path/or/properly/url/encoded/value”; </code> 

7. When URL encoding in DOM be aware of character set issues as the character set in JavaScript DOM is not clearly defined (Mike Samuel). 

8. Limit access to properties objects when using object[x] accessors. (Mike Samuel). In other words use a level of indirection between untrusted input and specified object properties. 
Here is an example of the problem when using map types: 
<code>
Var myMapType = {};
myMapType[<%=untrustedData%>] = “moreUntrustedData”;
</code> 

Although the developer writing the code above was trying to add additional keyed elements to the “myMapType” object. This could be used by an attacker to subvert internal and external attributes of the “myMapType” object. 

9. Run your JavaScript in a ECMAScript 5 canopy or sand box to make it harder for your JavaScript API to be compromised (Gareth Heyes and John Stevens). 

10. Don’t eval() JSON to convert it to native JavaScript objects. Instead use JSON.toJSON() and JSON.parse() (Chris Schmidt).

= Common Problems Associated with Mitgating DOM Based XSS =
==Complex Contexts==
In many cases the context isn’t always strait forward to discern. 
<code>
<a href=”javascript:myFunction(‘<%=untrustedData%>’, “test”);”>Click Me</a></code> 
<code>…</code> 
<code><script></code> 
<code>Function myFunction (url,name) {</code> 
<code> window.location = url;</code> 
<code>}</code> 
<code></script></code> 

In the above example, untrusted data started in the rendering URL context (href attribute of an <a> tag) then changed to a JavaScript execution context (javascript: protocol handler) which passed the untrusted data to an execution URL sub context (window.location of myFunction). Because the data was introduced in JavaScript code and passed to a URL sub context the appropriate server side encoding would be the following: 

<code>
<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(Encoder.encodeForURL(untrustedData))%>’, “test”);”>Click Me</a></code> 
<code>…</code> 

Or if you were using ECMAScript 5 with an immutable JavaScript client-side encoding libraries you could do the following: 

<code>
</code> 
<code><a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(untrustedData)%>’, “test”);”>Click Me</a></code> 
<code>…</code> 
<code><script></code> 
<code>Function myFunction (url,name) {</code> 
<code> var encodedURL = ESAPI4JS.encodeForURL(url); //URL encoding using client-side scripts</code> 
<code> window.location = encodedURL;</code> 
<code>}</code> 
<code></script></code> 

== Insonsistencies of Encoding Libraries ==
There are a number of open source encoding libraries out there: 

#ESAPI
#Apache Commons String Utils
#Jtidy
#Your company’s custom implementation.

Some work on a black list others ignore important characters like “<” and “>”. ESAPI is one of the few which work on a whitelist and encode all non-alpha numeric characters.
It is important to use an encoding library which understands which characters can be used to exploit vulnerabilies in their respective contexts.
But there are misconceptions abound related to proper encoding.
==Encoding Misconceptions==
Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of “text/xhtml” or the file type extension of “*.xhtml” then HML encoding may not work to mitigate against XSS. 

For example: 

<code>
<script>
&#x61;lert(1);
</script>
</code> 
 
The HTML encoded value above is still executable. If that isn’t enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element. 

Let’s look at the sample page and script: 

<code><form name=”myForm” …></code> 
<code><input type=”text” name=”lName” value=”<%=Encoder.encodeForHTML(last_name)%>”></code> 
<code>
…</code> 
<code></form></code> 
<code><script></code> 
<code>var x = document.myForm.lName.value; //when the value is retrived the encoding is reversed</code> 
<code>document.writeln(x); //any code passed into lName is now executable.</code> 
<code></script></code> 

Finally there is the problem that certain methods in JavaScript which are usually safe can be unsafe in certain contexts. 

==Usually Safe Methods==

One example of an attribute which is usually safe is innerText. Some papers or guides advocate its use as an alternative to innerHTML to mitigate against XSS in innerHTML. However, depending on the tag which innerText is applied, code can be executed. 

<code><script></code> 
<code>var tag = document.createElement(“script”);</code> 
<code>tag.innerText = “<%=untrustedData%>”; //executes code</code> 
<code></script></code> 

 Special thanks to Jim Manico, Gareth Heyes, Stefano Di Paola, Robert Hansen, Mario Heiderich, Achim Hoffmann, John Stevens, Edwardo (SirDarkCat) Alberto Vela Nava, Chris Schmidt, Mike Samuel, Jeremy Long, Jeff Williams, and many others who help make this guide possible.

{{Cheatsheet_Navigation}}

[[Category:How To]]
[[Category:Cheatsheets]]

DOM based XSS Prevention Cheat Sheet

2011-02-21T03:29:34Z

Abraham Kang:

= Introduction =

When looking at XSS (Cross Site Scripting) there are three generally recognized forms of XSS. Reflected, Persisted, and DOM based XSS. The [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] has done an excellent job of addressing Reflected and Persisted XSS. This cheatsheet will address DOM (Document Object Model) based XSS and is an extension (as assumes comprehension of) the the [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] .

In order to understand DOM based XSS one needs to see the fundamental difference between reflected and persisted XSS when compared to DOM based XSS. Reflected and persisted XSS exist in a higher level rendering context and DOM based XSS is primarily found in a lower level execution context. A rendering context is associated with the parsing of HTML tags and their attributes. The HTML parser of the rendering context dictates how data is presented and laid out on the page and can be further broken down into the standard contexts of HTML, HTML attribute, URL, and CSS. The JavaScript or VBScript parser of an execution context is associated with the parsing and execution of script code. Each parser has distinct and separate semantics in the way they can possibly execute script code (XSS) which make creating consistent rules for mitigating both rendering and execution based contexts difficult. The complication is compounded by the differing meanings and treatment of encoded values within each sub context (HTML, HTML attribute, URL, and CSS) within the execution context.

This paper refers to the HTML, HTML attribute, URL, and CSS Cheatsheet contexts as subcontexts because each of these contexts can be reached and set within a JavaScript execution context. In JavaScript code the main context is JavaScript but since an attacker can try to attack the other 4 contexts using equivalent JavaScript DOM methods we refer to the other contexts besides the JavaScript context as sub contexts. 

The following example of an attack which occurs in the JavaScript context and HTML sub context: 

<code>
<script> 
var x = ‘<%= htmlAndJavaScriptEncodedVar %>’; 
var d = document.createElement(‘div’); 
d.innerHTML = x; 
document.body.appendChild(d); 
</script> 
</code>

One consistency, however, is the need to JavaScript encode in addition to the encoding required for the sub context in the execution context. Let’s look at the individual sub contexts of the execution context in turn.

= HTML Sub Context within the Execution Context =

There are several methods and attributes which can be used to directly render HTML content within JavaScript. These methods constitute the HTML Sub Context within the Execution Context.

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

==Methods==
<code>document.write(“<HTML> Tags and markup”);</code> 
<code>document.writeln(“<HTML> Tags and markup”);</code> 

==Guideline==
In a pure HTML execution context (not HTML Attribute) use HTML and JavaScript encoding to mitigate against attacks. 
<code>element.innerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;</code> 
<code>element.outerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;</code> 

==Methods==
<code>document.write(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);</code> 
<code>document.writeln(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);</code> 

= HTML Attribute Sub Context within the Execution Context =

The HTML attribute Sub Context within the Execution context is divergent from the standard encoding rules. This is because the rule to HTML attribute encode in an HTML attribute rendering context is mitigating attacks which try to exit out of the attribute to add additional attributes and/or tags which could have executable code. When you are in a DOM execution context you only need to JavaScript encode HTML attributes which do not execute code (attributes other than event handler, CSS, and URL attributes).

For example, the general rule is to HTML Attribute encode untrusted data (data from the database, http request, user, backend 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.

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

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.

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

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.

= URL Attribute Sub Context 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.

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

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.

=CSS Attribute Sub Context 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.

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

TODO: We have not been able to get the expression() function working from DOM JavaScript code. Need some help.

=Event Handler and JavaScript code Sub Contexts 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.

<code>var x = document.createElement("a"); </code> 
<code>x.href="#”;</code> 
<code>x.setAttribute("onclick", "\u0061\u006c\u0065\u0072\u0074\u0028\u0032\u0032\u0029");</code> 
<code>var y = document.createTextNode("Click To Test"); </code> 
<code>x.appendChild(y);</code> 
<code>document.body.appendChild(x);</code> 

JavaScript event handler methods are dangerous because they implicitly do an eval() on the data passed to the DOM attribute. There are other places in JavaScript where JavaScript encoding is accepted as valid executable code.

<code>for ( var \u0062=0; \u0062 < 10; \u0062++){</code> 
<code> \u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074 </code> 
<code> .\u0077\u0072\u0069\u0074\u0065\u006c\u006e</code> 
<code> ("\u0048\u0065\u006c\u006c\u006f\u0020\u0057\u006f\u0072\u006c\u0064");</code> 
<code>} </code> 
<code>\u0077\u0069\u006e\u0064\u006f\u0077</code> 
<code>.\u0065\u0076\u0061\u006c (</code> 
<code>\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074</code> 
<code>.\u0077\u0072\u0069\u0074\u0065(111111111));</code> 

or

<code>var s = "\u0065\u0076\u0061\u006c"; </code> 
<code>var t = "\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029";</code> 
<code>window[s](t);</code> 

Because JavaScript is based on an international standard (ECMAScript), JavaScript encoding enables the support of international characters in programming constructs and variables in addition to alternate string representations (string escapes).

However the opposite is the case with HTML encoding. HTML tag elements are well defined and do not support alternate representations of the same tag. So HTML encoding cannot be used to allow the developer to have alternate representations of the <a> tag for example.

==HTML Encoding’s Disarming Nature==

In general, HTML encoding serves to castrate HTML tags which are placed in HTML and HTML attribute contexts.
Working example (no HTML encoding):

<code><a href=”…” ></code> 

Normally encoded example (Does Not Work – DNW):

<code>&#x3c;a href=… &#x3e;</code> 

HTML encoded example to highlight a fundamental difference with JavaScript encoded values (DNW):

<code><&#x61; href=…></code> 

If HTML encoding followed the same semantics as JavaScript encoding. The line above could have possibily worked to render a link. This difference makes JavaScript encoding a less viable weapon in our fight against XSS.

=Guidelines for Developing Secure Applications Utilizing JavaScript=

DOM based XSS is extremely difficult to mitigate against because of its large attack surface and lack of standardization across browsers. The guidelines below are an attempt to provide guidelines for developers when developing Web based JavaScript applications (Web 2.0) such that they can avoid XSS.

1. Untrusted data should only be treatedas 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) 
<code>var x = “<%=encodedJavaScriptData%>”;</code> 
3. Use document.createElement(“…”), element.setAttribute(“…”,”value”), element.appendChild(…), etc. to build dynamic interfaces. Avoid use of HTML rendering methods: 
#<code>element.innerHTML = “…”; </code>
#<code>element.outerHTML = “…”; </code>
#<code>document.write(…); </code>
#<code>document.writeln(…); </code> 
4. Understand the dataflow of untrusted data through your JavaScript code. If you do have to use the methods above remember to HTML and them JavaScript encode the untrusted data (Stefano Di Paola). 
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, 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. 

N-Levels of Encoding 

If your code looked like the following, you would need to only double JavaScript encode input data.

<code>setTimeout(“customFunction(‘<%=doubleJavaScriptEncodedData%>’, y)”);</code> 
<code>function customFunction (firstName, lastName) {</code> 
<code> alert("Hello" + firstName + " " + lastNam);</code> 
<code>}</code> 

The doubleJavaScriptEncodedData has its first layer of JavaScript encoding reversed in the single quotes. Then the implicit eval() of setTimeout reverses another layer of JavaScript encoding to pass the correct value to "customFunction". The reason why you only need to double JavaScript encode is that the "customFunction" function did not itself pass the input to another method which implicitly or explicitly called eval(). If "firstName" was passed to another JavaScript method which implicitly or explicitly called eval() then "<%=doubleJavaScriptEncodedData%>" above would need to be changed to "<%=tripleJavaScriptEncodedData%>". 

An important implementation note is that if the JavaScript code tries to utilize the double or triple encoded data in string comparisons, the value may be interpreted as different values based on the number of evals() the data has passed through before being passed to the if comparison and the number of times the value was JavaScript encoded. 

If "A" is double JavaScript encoded then the following if check will return false. 

<code>var x = "doubleJavaScriptEncodedA"; //\u005c\u0075\u0030\u0030\u0034\u0031</code> 
<code>if (x == "A") { </code> 
<code> alert("x is A"); </code> 
<code>} else if (x == "\u0041") { </code> 
<code> alert("This is what pops");</code> 
<code>} </code> 
This brings up an interesting design point. Ideally, the correct way to apply encoding and avoid the problem stated above is to server side encode for the output context where data is introduced into the application. Then client-side encode (using a JavaScript encoding library) for the individual sub context (DOM methods) which untrusted data is passed to. 
Here is an example: 
<code>
var input = “<%=Encoder.encodeForJS(untrustedData)%>”; //Server side encoding</code> 
<code>
window.location = ESAPI4JS.encodeForURL(input); //URL encoding is happing in JavaScript</code> 
<code>
document.writeln(ESAPI4JS.encodeForHTML(input)); //HTML encoding is happing in JavaScript
</code> 
It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers. One option is to wait till ECMAScript 5 so the JavaScript library could support immutable properties. 
Another option provided by Gaz (Gareth) was to use a specific code construct to limit mutability with anonymous clousures. 

An example follows: 

<code>function escapeHTML(str) {</code> 
<code> str = str + '';</code> 
<code> var out = '';</code> 
<code> for(var i=0;i<str.length;i++) {</code> 
<code> if(str[i] === '<') {</code> 
<code> out += '&lt;';</code> 
<code> } else if(str[i] === '>') {</code> 
<code> out += '&gt;';</code> 
<code> } else if(str[i] === "'") {</code> 
<code> out += '&#39;'; </code> 
<code> } else if(str[i] === '"') {</code> 
<code> out += '&quot;'; </code> 
<code> } else {</code> 
<code> out += str[i];</code> 
<code> }</code> 
<code> }</code> 
<code> return out;</code> 
<code> }</code> 

 Chris Schmidt has put together another implementation of a JavaScript encoder at http://yet-another-dev.blogspot.com/2011/02/client-side-contextual-encoding-for.html. 

6. Limit the usage of dynamic untrusted data to right side operations. And be aware of data which may be passed to the application which look like code (eg. “location”, “eval”). (Achim) 
<code>
var x = “<%=properly encoded data for flow%>”; </code> 

If you want to change different object attributes based on user input use a level of indirection. 

Instead of: 

<code>window[userData] = “moreUserData”; </code> 

Do the following instead: 
<code>if (userData===”location”) { </code> 
<code>window.location = “static/path/or/properly/url/encoded/value”; </code> 

7. When URL encoding in DOM be aware of character set issues as the character set in JavaScript DOM is not clearly defined (Mike Samuel). 

8. Limit access to properties objects when using object[x] accessors. (Mike Samuel). In other words use a level of indirection between untrusted input and specified object properties. 
Here is an example of the problem when using map types: 
<code>
Var myMapType = {};
myMapType[<%=untrustedData%>] = “moreUntrustedData”;
</code> 

Although the developer writing the code above was trying to add additional keyed elements to the “myMapType” object. This could be used by an attacker to subvert internal and external attributes of the “myMapType” object. 

9. Run your JavaScript in a ECMAScript 5 canopy or sand box to make it harder for your JavaScript API to be compromised (Gareth Heyes and John Stevens). 

10. Don’t eval() JSON to convert it to native JavaScript objects. Instead use JSON.toJSON() and JSON.parse() (Chris Schmidt).

= Common Problems Associated with Mitgating DOM Based XSS =
==Complex Contexts==
In many cases the context isn’t always strait forward to discern. 
<code>
<a href=”javascript:myFunction(‘<%=untrustedData%>’, “test”);”>Click Me</a></code> 
<code>…</code> 
<code><script></code> 
<code>Function myFunction (url,name) {</code> 
<code> window.location = url;</code> 
<code>}</code> 
<code></script></code> 

In the above example, untrusted data started in the rendering URL context (href attribute of an <a> tag) then changed to a JavaScript execution context (javascript: protocol handler) which passed the untrusted data to an execution URL sub context (window.location of myFunction). Because the data was introduced in JavaScript code and passed to a URL sub context the appropriate server side encoding would be the following: 

<code>
<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(Encoder.encodeForURL(untrustedData))%>’, “test”);”>Click Me</a></code> 
<code>…</code> 

Or if you were using ECMAScript 5 with an immutable JavaScript client-side encoding libraries you could do the following: 

<code>
</code> 
<code><a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(untrustedData)%>’, “test”);”>Click Me</a></code> 
<code>…</code> 
<code><script></code> 
<code>Function myFunction (url,name) {</code> 
<code> var encodedURL = ESAPI4JS.encodeForURL(url); //URL encoding using client-side scripts</code> 
<code> window.location = encodedURL;</code> 
<code>}</code> 
<code></script></code> 

== Insonsistencies of Encoding Libraries ==
There are a number of open source encoding libraries out there: 

#ESAPI
#Apache Commons String Utils
#Jtidy
#Your company’s custom implementation.

Some work on a black list others ignore important characters like “<” and “>”. ESAPI is one of the few which work on a whitelist and encode all non-alpha numeric characters.
It is important to use an encoding library which understands which characters can be used to exploit vulnerabilies in their respective contexts.
But there are misconceptions abound related to proper encoding.
==Encoding Misconceptions==
Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of “text/xhtml” or the file type extension of “*.xhtml” then HML encoding may not work to mitigate against XSS. 

For example: 

<code>
<script>
&#x61;lert(1);
</script>
</code> 
 
The HTML encoded value above is still executable. If that isn’t enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element. 

Let’s look at the sample page and script: 

<code><form name=”myForm” …></code> 
<code><input type=”text” name=”lName” value=”<%=Encoder.encodeForHTML(last_name)%>”></code> 
<code>
…</code> 
<code></form></code> 
<code><script></code> 
<code>var x = document.myForm.lName.value; //when the value is retrived the encoding is reversed</code> 
<code>document.writeln(x); //any code passed into lName is now executable.</code> 
<code></script></code> 

Finally there is the problem that certain methods in JavaScript which are usually safe can be unsafe in certain contexts. 

==Usually Safe Methods==

One example of an attribute which is usually safe is innerText. Some papers or guides advocate its use as an alternative to innerHTML to mitigate against XSS in innerHTML. However, depending on the tag which innerText is applied, code can be executed. 

<code><script></code> 
<code>var tag = document.createElement(“script”);</code> 
<code>tag.innerText = “<%=untrustedData%>”; //executes code</code> 
<code></script></code> 

 Special thanks to Jim Manico, Gareth Heyes, Stefano Di Paola, Robert Hansen, Mario Heiderich, Achim Hoffmann, John Stevens, Edwardo (SirDarkCat) Alberto Vela Nava, Chris Schmidt, Mike Samuel, Jeremy Long, Jeff Williams, and many others who help make this guide possible.

{{Cheatsheet_Navigation}}

[[Category:How To]]
[[Category:Cheatsheets]]

DOM based XSS Prevention Cheat Sheet

2011-02-20T20:44:58Z

Abraham Kang: Mitigating DOM based XSS (Remediation)

= Introduction =

When looking at XSS (Cross Site Scripting) there are three generally recognized forms of XSS. Reflected, Persisted, and DOM based XSS. The [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] has done an excellent job of addressing Reflected and Persisted XSS. This cheatsheet will address DOM (Document Object Model) based XSS and is an extension (as assumes comprehension of) the the [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] .

In order to understand DOM based XSS one needs to see the fundamental difference between reflected and persisted XSS when compared to DOM based XSS. Reflected and persisted XSS exist in a higher level rendering context and DOM based XSS is primarily found in a lower level execution context. A rendering context is associated with the parsing of HTML tags and their attributes. The HTML parser of the rendering context dictates how data is presented and laid out on the page and can be further broken down into the standard contexts of HTML, HTML attribute, URL, and CSS. The JavaScript or VBScript parser of an execution context is associated with the parsing and execution of script code. Each parser has distinct and separate semantics in the way they can possibly execute script code (XSS) which make creating consistent rules for mitigating both rendering and execution based contexts difficult. The complication is compounded by the differing meanings and treatment of encoded values within each sub context (HTML, HTML attribute, URL, and CSS) within the execution context.

This paper refers to the HTML, HTML attribute, URL, and CSS Cheatsheet contexts as subcontexts because each of these contexts can be reached and set within a JavaScript execution context. In JavaScript code the main context is JavaScript but since an attacker can try to attack the other 4 contexts using equivalent JavaScript DOM methods we refer to the other contexts besides the JavaScript context as sub contexts. 

The following example of an attack which occurs in the JavaScript context and HTML sub context: 

<code>
<script> 
var x = ‘<%= htmlAndJavaScriptEncodedVar %>’; 
var d = document.createElement(‘div’); 
d.innerHTML = x; 
document.body.appendChild(d); 
</script> 
</code>

One consistency, however, is the need to JavaScript encode in addition to the encoding required for the sub context in the execution context. Let’s look at the individual sub contexts of the execution context in turn.

= HTML Sub Context within the Execution Context =

There are several methods and attributes which can be used to directly render HTML content within JavaScript. These methods constitute the HTML Sub Context within the Execution Context.

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

==Methods==
<code>document.write(“<HTML> Tags and markup”);</code> 
<code>document.writeln(“<HTML> Tags and markup”);</code> 

==Guideline==
In a pure HTML execution context (not HTML Attribute) use HTML and JavaScript encoding to mitigate against attacks. 
<code>element.innerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;</code> 
<code>element.outerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;</code> 

==Methods==
<code>document.write(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);</code> 
<code>document.writeln(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);</code> 

= HTML Attribute Sub Context within the Execution Context =

The HTML attribute Sub Context within the Execution context is divergent from the standard encoding rules. This is because the rule to HTML attribute encode in an HTML attribute rendering context is mitigating attacks which try to exit out of the attribute to add additional attributes and/or tags which could have executable code. When you are in a DOM execution context you only need to JavaScript encode HTML attributes which do not execute code (attributes other than event handler, CSS, and URL attributes).

For example, the general rule is to HTML Attribute encode untrusted data (data from the database, http request, user, backend 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.

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

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.

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

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.

= URL Attribute Sub Context 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.

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

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.

=CSS Attribute Sub Context 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.

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

TODO: We have not been able to get the expression() function working from DOM JavaScript code. Need some help.

=Event Handler and JavaScript code Sub Contexts 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.

<code>var x = document.createElement("a"); </code> 
<code>x.href="#”;</code> 
<code>x.setAttribute("onclick", "\u0061\u006c\u0065\u0072\u0074\u0028\u0032\u0032\u0029");</code> 
<code>var y = document.createTextNode("Click To Test"); </code> 
<code>x.appendChild(y);</code> 
<code>document.body.appendChild(x);</code> 

JavaScript event handler methods are dangerous because they implicitly do an eval() on the data passed to the DOM attribute. There are other places in JavaScript where JavaScript encoding is accepted as valid executable code.

<code>for ( var \u0062=0; \u0062 < 10; \u0062++){</code> 
<code> \u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074 </code> 
<code> .\u0077\u0072\u0069\u0074\u0065\u006c\u006e</code> 
<code> ("\u0048\u0065\u006c\u006c\u006f\u0020\u0057\u006f\u0072\u006c\u0064");</code> 
<code>} </code> 
<code>\u0077\u0069\u006e\u0064\u006f\u0077</code> 
<code>.\u0065\u0076\u0061\u006c (</code> 
<code>\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074</code> 
<code>.\u0077\u0072\u0069\u0074\u0065(111111111));</code> 

or

<code>var s = "\u0065\u0076\u0061\u006c"; </code> 
<code>var t = "\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029";</code> 
<code>window[s](t);</code> 

Because JavaScript is based on an international standard (ECMAScript), JavaScript encoding enables the support of international characters in programming constructs and variables in addition to alternate string representations (string escapes).

However the opposite is the case with HTML encoding. HTML tag elements are well defined and do not support alternate representations of the same tag. So HTML encoding cannot be used to allow the developer to have alternate representations of the <a> tag for example.

==HTML Encoding’s Disarming Nature==

In general, HTML encoding serves to castrate HTML tags which are placed in HTML and HTML attribute contexts.
Working example (no HTML encoding):

<code><a href=”…” ></code> 

Normally encoded example (Does Not Work – DNW):

<code>&#x3c;a href=… &#x3e;</code> 

HTML encoded example to highlight a fundamental difference with JavaScript encoded values (DNW):

<code><&#x61; href=…></code> 

If HTML encoding followed the same semantics as JavaScript encoding. The line above could have possibily worked to render a link. This difference makes JavaScript encoding a less viable weapon in our fight against XSS.

=Guidelines for Developing Secure Applications Utilizing JavaScript=

DOM based XSS is extremely difficult to mitigate against because of its large attack surface and lack of standardization across browsers. The guidelines below are an attempt to provide guidelines for developers when developing Web based JavaScript applications (Web 2.0) such that they can avoid XSS.

1. Untrusted data should only be treatedas 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) 
<code>var x = “<%=encodedJavaScriptData%>”;</code> 
3. Use document.createElement(“…”), element.setAttribute(“…”,”value”), element.appendChild(…), etc. to build dynamic interfaces. Avoid use of HTML rendering methods: 
#<code>element.innerHTML = “…”; </code>
#<code>element.outerHTML = “…”; </code>
#<code>document.write(…); </code>
#<code>document.writeln(…); </code> 
4. Understand the dataflow of untrusted data through your JavaScript code. If you do have to use the methods above remember to HTML and them JavaScript encode the untrusted data (Stefano Di Paola). 
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, 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. 

N-Levels of Encoding 

If your code looked like the following, you would need to only double JavaScript encode input data.

<code>setTimeout(“customFunction(‘<%=doubleJavaScriptEncodedData%>’, y)”);</code> 
<code>function customFunction (firstName, lastName) {</code> 
<code> alert("Hello" + firstName + " " + lastNam);</code> 
<code>}</code> 

The doubleJavaScriptEncodedData has its first layer of JavaScript encoding reversed in the single quotes. Then the implicit eval() of setTimeout reverses another layer of JavaScript encoding to pass the correct value to "customFunction". The reason why you only need to double JavaScript encode is that the "customFunction" function did not itself pass the input to another method which implicitly or explicitly called eval(). If "firstName" was passed to another JavaScript method which implicitly or explicitly called eval() then "<%=doubleJavaScriptEncodedData%>" above would need to be changed to "<%=tripleJavaScriptEncodedData%>". 

An important implementation note is that if the JavaScript code tries to utilize the double or triple encoded data in string comparisons, the value may be interpreted as different values based on the number of evals() the data has passed through before being passed to the if comparison and the number of times the value was JavaScript encoded. 

If "A" is double JavaScript encoded then the following if check will return false. 

<code>var x = "doubleJavaScriptEncodedA"; //\u005c\u0075\u0030\u0030\u0034\u0031</code> 
<code>if (x == "A") { </code> 
<code> alert("x is A"); </code> 
<code>} else if (x == "\u0041") { </code> 
<code> alert("This is what pops");</code> 
<code>} </code> 
This brings up an interesting design point. Ideally, the correct way to apply encoding and avoid the problem stated above is to server side encode for the output context where data is introduced into the application. Then client-side encode (using a JavaScript encoding library) for the individual sub context (DOM methods) which untrusted data is passed to. 
Here is an example: 
<code>
var input = “<%=Encoder.encodeForJS(untrustedData)%>”; //Server side encoding</code> 
<code>
window.location = ESAPI4JS.encodeForURL(input); //URL encoding is happing in JavaScript</code> 
<code>
document.writeln(ESAPI4JS.encodeForHTML(input)); //HTML encoding is happing in JavaScript
</code> 
It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers. One option is to wait till ECMAScript 5 so the JavaScript library could support immutable properties. 
Another option provided by Gaz (Gareth) was to use a specific code construct to limit mutability with anonymous clousures. 

An example follows: 

<code>function escapeHTML(str) {</code> 
<code> str = str + '';</code> 
<code> var out = '';</code> 
<code> for(var i=0;i<str.length;i++) {</code> 
<code> if(str[i] === '<') {</code> 
<code> out += '<';</code> 
<code> } else if(str[i] === '>') {</code> 
<code> out += '>';</code> 
<code> } else if(str[i] === "'") {</code> 
<code> out += '''; </code> 
<code> } else if(str[i] === '"') {</code> 
<code> out += '"'; </code> 
<code> } else {</code> 
<code> out += str[i];</code> 
<code> }</code> 
<code> }</code> 
<code> return out;</code> 
<code> }</code> 

 Chris Schmidt has put together another implementation of a JavaScript encoder at http://yet-another-dev.blogspot.com/2011/02/client-side-contextual-encoding-for.html. 

6. Limit the usage of dynamic untrusted data to right side operations. And be aware of data which may be passed to the application which look like code (eg. “location”, “eval”). (Achim) 
<code>
var x = “<%=properly encoded data for flow%>”; </code> 

If you want to change different object attributes based on user input use a level of indirection. 

Instead of: 

<code>window[userData] = “moreUserData”; </code> 

Do the following instead: 
<code>if (userData===”location”) { </code> 
<code>window.location = “static/path/or/properly/url/encoded/value”; </code> 

7. When URL encoding in DOM be aware of character set issues as the character set in JavaScript DOM is not clearly defined (Mike Samuel). 

8. Limit access to properties objects when using object[x] accessors. (Mike Samuel). In other words use a level of indirection between untrusted input and specified object properties. 
Here is an example of the problem when using map types: 
<code>
Var myMapType = {};
myMapType[<%=untrustedData%>] = “moreUntrustedData”;
</code> 

Although the developer writing the code above was trying to add additional keyed elements to the “myMapType” object. This could be used by an attacker to subvert internal and external attributes of the “myMapType” object. 

9. Run your JavaScript in a ECMAScript 5 canopy or sand box to make it harder for your JavaScript API to be compromised (Gareth Heyes and John Stevens). 

10. Don’t eval() JSON to convert it to native JavaScript objects. Instead use JSON.toJSON() and JSON.parse() (Chris Schmidt).

= Common Problems Associated with Mitgating DOM Based XSS =
==Complex Contexts==
In many cases the context isn’t always strait forward to discern. 
<code>
<a href=”javascript:myFunction(‘<%=untrustedData%>’, “test”);”>Click Me</a></code> 
<code>…</code> 
<code><script></code> 
<code>Function myFunction (url,name) {</code> 
<code> window.location = url;</code> 
<code>}</code> 
<code></script></code> 

In the above example, untrusted data started in the rendering URL context (href attribute of an <a> tag) then changed to a JavaScript execution context (javascript: protocol handler) which passed the untrusted data to an execution URL sub context (window.location of myFunction). Because the data was introduced in JavaScript code and passed to a URL sub context the appropriate server side encoding would be the following: 

<code>
<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(Encoder.encodeForURL(untrustedData))%>’, “test”);”>Click Me</a></code> 
<code>…</code> 

Or if you were using ECMAScript 5 with an immutable JavaScript client-side encoding libraries you could do the following: 

<code>
</code> 
<code><a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(untrustedData)%>’, “test”);”>Click Me</a></code> 
<code>…</code> 
<code><script></code> 
<code>Function myFunction (url,name) {</code> 
<code> var encodedURL = ESAPI4JS.encodeForURL(url); //URL encoding using client-side scripts</code> 
<code> window.location = encodedURL;</code> 
<code>}</code> 
<code></script></code> 

== Insonsistencies of Encoding Libraries ==
There are a number of open source encoding libraries out there: 

#ESAPI
#Apache Commons String Utils
#Jtidy
#Your company’s custom implementation.

Some work on a black list others ignore important characters like “<” and “>”. ESAPI is one of the few which work on a whitelist and encode all non-alpha numeric characters.
It is important to use an encoding library which understands which characters can be used to exploit vulnerabilies in their respective contexts.
But there are misconceptions abound related to proper encoding.
==Encoding Misconceptions==
Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of “text/xhtml” or the file type extension of “*.xhtml” then HML encoding may not work to mitigate against XSS. 

For example: 

<code>
<script>
&#x61;lert(1);
</script>
</code> 
 
The HTML encoded value above is still executable. If that isn’t enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element. 

Let’s look at the sample page and script: 

<code><form name=”myForm” …></code> 
<code><input type=”text” name=”lName” value=”<%=Encoder.encodeForHTML(last_name)%>”></code> 
<code>
…</code> 
<code></form></code> 
<code><script></code> 
<code>var x = document.myForm.lName.value; //when the value is retrived the encoding is reversed</code> 
<code>document.writeln(x); //any code passed into lName is now executable.</code> 
<code></script></code> 

Finally there is the problem that certain methods in JavaScript which are usually safe can be unsafe in certain contexts. 

==Usually Safe Methods==

One example of an attribute which is usually safe is innerText. Some papers or guides advocate its use as an alternative to innerHTML to mitigate against XSS in innerHTML. However, depending on the tag which innerText is applied, code can be executed. 

<code><script></code> 
<code>var tag = document.createElement(“script”);</code> 
<code>tag.innerText = “<%=untrustedData%>”; //executes code</code> 
<code></script></code> 

 Special thanks to Jim Manico, Gareth Heyes, Stefano Di Paola, Robert Hansen, Mario Heiderich, Achim Hoffmann, John Stevens, Edwardo (SirDarkCat) Alberto Vela Nava, Chris Schmidt, Mike Samuel, Jeremy Long, Jeff Williams, and many others who help make this guide possible.

{{Cheatsheet_Navigation}}

[[Category:How To]]
[[Category:Cheatsheets]]

Global Industry Committee - Application 10

2011-02-18T17:14:12Z

Abraham Kang:

[[How to Join a Committee|Click here to return to 'How to Join a Committee' page]]

----

{| style="width:100%" border="0" align="center"
|-
! colspan="2" align="center" style="background:#4058A0; color:white" | '''COMMITTEE APPLICATION FORM'''
|-
| style="width:25%; background:#7B8ABD" align="center" | '''Applicant's Name'''
| colspan="1" style="width:85%; background:#cccccc" align="left" | Sherif Koussa
|-
| style="width:25%; background:#7B8ABD" align="center" | '''Current and past OWASP Roles'''
| colspan="1" style="width:85%; background:#cccccc" align="left" | OWASP Ottawa Chapter Leader - WebGoat 5.0
|-
| style="width:25%; background:#7B8ABD" align="center" | '''Committee Applying for'''
| colspan="1" style="width:85%; background:#cccccc" align="left" | Global Industry Committee
|}

----

 

----

Please be aware that for an application to be considered by the board, '''you MUST have 5 recommendations'''. An incomplete application will not be considered for vote.

----

 

----

{| style="width:100%" border="0" align="center"
|-
! colspan="8" align="center" style="background:#4058A0; color:white" | '''COMMITTEE RECOMMENDATIONS'''
|-
! align="center" style="background:white; color:white" | 
! align="center" style="background:#7B8ABD; color:white" | '''Who Recommends/Name'''
! align="center" style="background:#7B8ABD; color:white" | '''Role in OWASP'''
! align="center" style="background:#7B8ABD; color:white" | '''Recommendation Content'''
|-
| style="width:3%; background:#cccccc" align="center" | '''1'''
| style="width:20%; background:#cccccc" align="center" | Dinis Cruz
| style="width:20%; background:#cccccc" align="center" | [[O2 Platform]] Project Leader
| style="width:57%; background:#cccccc" align="center" | Sherif is an active OWASP leader and in the past has already made a number of bridges and connections with the Industry. I think he will be a great addition to this Committee
|-
| style="width:3%; background:#cccccc" align="center" | '''2'''
| style="width:20%; background:#cccccc" align="center" | Bruce Mayhew
| style="width:20%; background:#cccccc" align="center" | [[WebGoat]] Project Leader
| style="width:57%; background:#cccccc" align="center" | Sherif is active in the security community, active in OWASP, and has made major contributions to WebGoat. Sherif will be an asset to this committee.
|-
| style="width:3%; background:#cccccc" align="center" | '''3'''
| style="width:20%; background:#cccccc" align="center" | Karim Nathoo
| style="width:20%; background:#cccccc" align="center" | OWASP Ottawa Chapter Co-Leader
| style="width:57%; background:#cccccc" align="center" | Sherif is the driving force behind the Ottawa Chapter.  He is both a very passionate and motivated volunteer and also a talented application security professional.  I am confident he will be an asset to the Global Industry Committee.
|-
| style="width:3%; background:#cccccc" align="center" | '''4'''
| style="width:20%; background:#cccccc" align="center" | Joe Bernik 
| style="width:20%; background:#cccccc" align="center" | Committee member 
| style="width:57%; background:#cccccc" align="center" | Sherif is a driven leader in Canada and will make a great contribution to the Committee.
|-
| style="width:3%; background:#cccccc" align="center" | '''5'''
| style="width:20%; background:#cccccc" align="center" | Abraham Kang
| style="width:20%; background:#cccccc" align="center" | DOM based XSS Cheatsheet Co-Leader
| style="width:57%; background:#cccccc" align="center" | Sherif is a talented application security engineer. He has worked in many industrusties and his experience would be a great asset to the committee.
|}

----

DOM based XSS Prevention Cheat Sheet

2011-02-18T17:08:27Z

Abraham Kang:

= Introduction =

When looking at XSS (Cross Site Scripting) there are three generally recognized forms of XSS. Reflected, Persisted, and DOM based XSS. The [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] has done an excellent job of addressing Reflected and Persisted XSS. This cheatsheet will address DOM (Document Object Model) based XSS and is an extension (as assumes comprehension of) the the [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] .

In order to understand DOM based XSS one needs to see the fundamental difference between reflected and persisted XSS when compared to DOM based XSS. Reflected and persisted XSS exist in a higher level rendering context and DOM based XSS is primarily found in a lower level execution context. A rendering context is associated with the parsing of HTML tags and their attributes. The HTML parser of the rendering context dictates how data is presented and laid out on the page and can be further broken down into the standard contexts of HTML, HTML attribute, URL, and CSS. The JavaScript or VBScript parser of an execution context is associated with the parsing and execution of script code. Each parser has distinct and separate semantics in the way they can possibly execute script code (XSS) which make creating consistent rules for mitigating both rendering and execution based contexts difficult. The complication is compounded by the differing meanings and treatment of encoded values within each sub context (HTML, HTML attribute, URL, and CSS) within the execution context.

This paper refers to the HTML, HTML attribute, URL, and CSS Cheatsheet contexts as subcontexts because each of these contexts can be reached and set within a JavaScript execution context. In JavaScript code the main context is JavaScript but since an attacker can try to attack the other 4 contexts using equivalent JavaScript DOM methods we refer to the other contexts besides the JavaScript context as sub contexts. 

The following example of an attack which occurs in the JavaScript context and HTML sub context: 

<code>
<script> 
var x = ‘<%= htmlAndJavaScriptEncodedVar %>’; 
var d = document.createElement(‘div’); 
d.innerHTML = x; 
document.body.appendChild(d); 
</script> 
</code>

One consistency, however, is the need to JavaScript encode in addition to the encoding required for the sub context in the execution context. Let’s look at the individual sub contexts of the execution context in turn.

= HTML Sub Context within the Execution Context =

There are several methods and attributes which can be used to directly render HTML content within JavaScript. These methods constitute the HTML Sub Context within the Execution Context.

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

==Methods==
<code>document.write(“<HTML> Tags and markup”);</code> 
<code>document.writeln(“<HTML> Tags and markup”);</code> 

==Guideline==
In a pure HTML execution context (not HTML Attribute) use HTML and JavaScript encoding to mitigate against attacks. 
<code>element.innerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;</code> 
<code>element.outerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;</code> 

==Methods==
<code>document.write(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);</code> 
<code>document.writeln(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);</code> 

= HTML Attribute Sub Context within the Execution Context =

The HTML attribute Sub Context within the Execution context is divergent from the standard encoding rules. This is because the rule to HTML attribute encode in an HTML attribute rendering context is mitigating attacks which try to exit out of the attribute to add additional attributes and/or tags which could have executable code. When you are in a DOM execution context you only need to JavaScript encode HTML attributes which do not execute code (attributes other than event handler, CSS, and URL attributes).

For example, the general rule is to HTML Attribute encode untrusted data (data from the database, http request, user, backend 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.

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

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.

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

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.

= URL Attribute Sub Context 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.

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

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.

=CSS Attribute Sub Context 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.

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

TODO: We have not been able to get the expression() function working from DOM JavaScript code. Need some help.

=Event Handler and JavaScript code Sub Contexts 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.

<code>var x = document.createElement("a"); </code> 
<code>x.href="#”;</code> 
<code>x.setAttribute("onclick", "\u0061\u006c\u0065\u0072\u0074\u0028\u0032\u0032\u0029");</code> 
<code>var y = document.createTextNode("Click To Test"); </code> 
<code>x.appendChild(y);</code> 
<code>document.body.appendChild(x);</code> 

JavaScript event handler methods are dangerous because they implicitly do an eval() on the data passed to the DOM attribute. There are other places in JavaScript where JavaScript encoding is accepted as valid executable code.

<code>for ( var \u0062=0; \u0062 < 10; \u0062++){</code> 
<code> \u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074 </code> 
<code> .\u0077\u0072\u0069\u0074\u0065\u006c\u006e</code> 
<code> ("\u0048\u0065\u006c\u006c\u006f\u0020\u0057\u006f\u0072\u006c\u0064");</code> 
<code>} </code> 
<code>\u0077\u0069\u006e\u0064\u006f\u0077</code> 
<code>.\u0065\u0076\u0061\u006c (</code> 
<code>\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074</code> 
<code>.\u0077\u0072\u0069\u0074\u0065(111111111));</code> 

or

<code>var s = "\u0065\u0076\u0061\u006c"; </code> 
<code>var t = "\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029";</code> 
<code>window[s](t);</code> 

Because JavaScript is based on an international standard (ECMAScript), JavaScript encoding enables the support of international characters in programming constructs and variables in addition to alternate string representations (string escapes).

However the opposite is the case with HTML encoding. HTML tag elements are well defined and do not support alternate representations of the same tag. So HTML encoding cannot be used to allow the developer to have alternate representations of the <a> tag for example.

==HTML Encoding’s Disarming Nature==

In general, HTML encoding serves to castrate HTML tags which are placed in HTML and HTML attribute contexts.
Working example (no HTML encoding):

<code><a href=”…” ></code> 

Normally encoded example (Does Not Work – DNW):

<code>&#x3c;a href=… &#x3e;</code> 

HTML encoded example to highlight a fundamental difference with JavaScript encoded values (DNW):

<code><&#x61; href=…></code> 

If HTML encoding followed the same semantics as JavaScript encoding. The line above could have possibily worked to render a link. This difference makes JavaScript encoding a less viable weapon in our fight against XSS.

=Guidelines for Developing Secure Applications Utilizing JavaScript=

DOM based XSS is extremely difficult to mitigate against because of its large attack surface and lack of standardization across browsers. The guidelines below are an attempt to provide guidelines for developers when developing Web based JavaScript applications (Web 2.0) such that they can avoid XSS.

1. Untrusted data should only be treatedas 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) 
<code>var x = “<%=encodedJavaScriptData%>”;</code> 
3. Use document.createElement(“…”), element.setAttribute(“…”,”value”), element.appendChild(…), etc. to build dynamic interfaces. Avoid use of HTML rendering methods: 
#<code>element.innerHTML = “…”; </code>
#<code>element.outerHTML = “…”; </code>
#<code>document.write(…); </code>
#<code>document.writeln(…); </code> 
4. Understand the dataflow of untrusted data through your JavaScript code. If you do have to use the methods above remember to HTML and them JavaScript encode the untrusted data (Stefano Di Paola). 
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, 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. 

N-Levels of Encoding 

If your code looked like the following, you would need to only double JavaScript encode input data.

<code>setTimeout(“customFunction(‘<%=doubleJavaScriptEncodedData%>’, y)”);</code> 
<code>function customFunction (firstName, lastName) {</code> 
<code> alert("Hello" + firstName + " " + lastNam);</code> 
<code>}</code> 

The doubleJavaScriptEncodedData has its first layer of JavaScript encoding reversed in the single quotes. Then the implicit eval() of setTimeout reverses another layer of JavaScript encoding to pass the correct value to "customFunction". The reason why you only need to double JavaScript encode is that the "customFunction" function did not itself pass the input to another method which implicitly or explicitly called eval(). If "firstName" was passed to another JavaScript method which implicitly or explicitly called eval() then "<%=doubleJavaScriptEncodedData%>" above would need to be changed to "<%=tripleJavaScriptEncodedData%>". 

An important implementation note is that if the JavaScript code tries to utilize the double or triple encoded data in string comparisons, the value may be interpreted as different values based on the number of evals() the data has passed through before being passed to the if comparison and the number of times the value was JavaScript encoded. 

If "A" is double JavaScript encoded then the following if check will return false. 

<code>var x = "doubleJavaScriptEncodedA"; //\u005c\u0075\u0030\u0030\u0034\u0031</code> 
<code>if (x == "A") { </code> 
<code> alert("x is A"); </code> 
<code>} else if (x == "\u0041") { </code> 
<code> alert("This is what pops");</code> 
<code>} </code> 
This brings up an interesting design point. Ideally, the correct way to apply encoding and avoid the problem stated above is to server side encode for the output context where data is introduced into the application. Then client-side encode (using a JavaScript encoding library) for the individual sub context (DOM methods) which untrusted data is passed to. 
Here is an example: 
<code>
var input = “<%=Encoder.encodeForJS(untrustedData)%>”; //Server side encoding</code> 
<code>
window.location = ESAPI4JS.encodeForURL(input); //URL encoding is happing in JavaScript</code> 
<code>
document.writeln(ESAPI4JS.encodeForHTML(input)); //HTML encoding is happing in JavaScript
</code> 
It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers. One option is to wait till ECMAScript 5 so the JavaScript library could support immutable properties. 
Another option provided by Gaz (Gareth) was to use a specific code construct to limit mutability with anonymous clousures. 

An example follows: 

<code>function escapeHTML(str) {</code> 
<code> str = str + '';</code> 
<code> var out = '';</code> 
<code> for(var i=0;i<str.length;i++) {</code> 
<code> if(str[i] === '<') {</code> 
<code> out += '<';</code> 
<code> } else if(str[i] === '>') {</code> 
<code> out += '>';</code> 
<code> } else if(str[i] === "'") {</code> 
<code> out += '''; </code> 
<code> } else if(str[i] === '"') {</code> 
<code> out += '"'; </code> 
<code> } else {</code> 
<code> out += str[i];</code> 
<code> }</code> 
<code> }</code> 
<code> return out;</code> 
<code> }</code> 

6. Limit the usage of dynamic untrusted data to right side operations. And be aware of data which may be passed to the application which look like code (eg. “location”, “eval”). (Achim) 
<code>
var x = “<%=properly encoded data for flow%>”; </code> 

If you want to change different object attributes based on user input use a level of indirection. 

Instead of: 

<code>window[userData] = “moreUserData”; </code> 

Do the following instead: 
<code>if (userData===”location”) { </code> 
<code>window.location = “static/path/or/properly/url/encoded/value”; </code> 

7. When URL encoding in DOM be aware of character set issues as the character set in JavaScript DOM is not clearly defined (Mike Samuel). 

8. Limit access to properties objects when using object[x] accessors. (Mike Samuel). In other words use a level of indirection between untrusted input and specified object properties. 
Here is an example of the problem when using map types: 
<code>
Var myMapType = {};
myMapType[<%=untrustedData%>] = “moreUntrustedData”;
</code> 

Although the developer writing the code above was trying to add additional keyed elements to the “myMapType” object. This could be used by an attacker to subvert internal and external attributes of the “myMapType” object. 

9. Run your JavaScript in a ECMAScript 5 canopy or sand box to make it harder for your JavaScript API to be compromised (Gareth Heyes and John Stevens). 

10. Don’t eval() JSON to convert it to native JavaScript objects. Instead use JSON.toJSON() and JSON.parse() (Chris Schmidt).

= Common Problems Associated with Mitgating DOM Based XSS =
==Complex Contexts==
In many cases the context isn’t always strait forward to discern. 
<code>
<a href=”javascript:myFunction(‘<%=untrustedData%>’, “test”);”>Click Me</a></code> 
<code>…</code> 
<code><script></code> 
<code>Function myFunction (url,name) {</code> 
<code> window.location = url;</code> 
<code>}</code> 
<code></script></code> 

In the above example, untrusted data started in the rendering URL context (href attribute of an <a> tag) then changed to a JavaScript execution context (javascript: protocol handler) which passed the untrusted data to an execution URL sub context (window.location of myFunction). Because the data was introduced in JavaScript code and passed to a URL sub context the appropriate server side encoding would be the following: 

<code>
<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(Encoder.encodeForURL(untrustedData))%>’, “test”);”>Click Me</a></code> 
<code>…</code> 

Or if you were using ECMAScript 5 with an immutable JavaScript client-side encoding libraries you could do the following: 

<code>
</code> 
<code><a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(untrustedData)%>’, “test”);”>Click Me</a></code> 
<code>…</code> 
<code><script></code> 
<code>Function myFunction (url,name) {</code> 
<code> var encodedURL = ESAPI4JS.encodeForURL(url); //URL encoding using client-side scripts</code> 
<code> window.location = encodedURL;</code> 
<code>}</code> 
<code></script></code> 

== Insonsistencies of Encoding Libraries ==
There are a number of open source encoding libraries out there: 

#ESAPI
#Apache Commons String Utils
#Jtidy
#Your company’s custom implementation.

Some work on a black list others ignore important characters like “<” and “>”. ESAPI is one of the few which work on a whitelist and encode all non-alpha numeric characters.
It is important to use an encoding library which understands which characters can be used to exploit vulnerabilies in their respective contexts.
But there are misconceptions abound related to proper encoding.
==Encoding Misconceptions==
Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of “text/xhtml” or the file type extension of “*.xhtml” then HML encoding may not work to mitigate against XSS. 

For example: 

<code>
<script>
&#x61;lert(1);
</script>
</code> 
 
The HTML encoded value above is still executable. If that isn’t enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element. 

Let’s look at the sample page and script: 

<code><form name=”myForm” …></code> 
<code><input type=”text” name=”lName” value=”<%=Encoder.encodeForHTML(last_name)%>”></code> 
<code>
…</code> 
<code></form></code> 
<code><script></code> 
<code>var x = document.myForm.lName.value; //when the value is retrived the encoding is reversed</code> 
<code>document.writeln(x); //any code passed into lName is now executable.</code> 
<code></script></code> 

Finally there is the problem that certain methods in JavaScript which are usually safe can be unsafe in certain contexts. 

==Usually Safe Methods==

One example of an attribute which is usually safe is innerText. Some papers or guides advocate its use as an alternative to innerHTML to mitigate against XSS in innerHTML. However, depending on the tag which innerText is applied, code can be executed. 

<code><script></code> 
<code>var tag = document.createElement(“script”);</code> 
<code>tag.innerText = “<%=untrustedData%>”; //executes code</code> 
<code></script></code> 

 Special thanks to Jim Manico, Gareth Heyes, Stefano Di Paola, Robert Hansen, Mario Heiderich, Achim Hoffmann, John Stevens, Edwardo (SirDarkCat) Alberto Vela Nava, Chris Schmidt, Mike Samuel, Jeremy Long, Jeff Williams, and many others who help make this guide possible.

{{Cheatsheet_Navigation}}

[[Category:How To]]
[[Category:Cheatsheets]]

DOM based XSS Prevention Cheat Sheet

2011-02-18T05:02:33Z

Abraham Kang:

= Introduction =

When looking at XSS (Cross Site Scripting) there are three generally recognized forms of XSS. Reflected, Persisted, and DOM based XSS. The [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] has done an excellent job of addressing Reflected and Persisted XSS. This cheatsheet will address DOM (Document Object Model) based XSS and is an extension (as assumes comprehension of) the the [http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet XSS Prevention Cheatsheet] .

In order to understand DOM based XSS one needs to see the fundamental difference between reflected and persisted XSS when compared to DOM based XSS. Reflected and persisted XSS exist in a higher level rendering context and DOM based XSS is primarily found in a lower level execution context. A rendering context is associated with the parsing of HTML tags and their attributes. The HTML parser of the rendering context dictates how data is presented and laid out on the page and can be further broken down into the standard contexts of HTML, HTML attribute, URL, and CSS. The JavaScript or VBScript parser of an execution context is associated with the parsing and execution of script code. Each parser has distinct and separate semantics in the way they can possibly execute script code (XSS) which make creating consistent rules for mitigating both rendering and execution based contexts difficult. The complication is compounded by the differing meanings and treatment of encoded values within each sub context (HTML, HTML attribute, URL, and CSS) within the execution context.

This paper refers to the HTML, HTML attribute, URL, and CSS Cheatsheet contexts as subcontexts because each of these contexts can be reached and set within a JavaScript execution context. In JavaScript code the main context is JavaScript but since an attacker can try to attack the other 4 contexts using equivalent JavaScript DOM methods we refer to the other contexts besides the JavaScript context as sub contexts. 

The following example of an attack which occurs in the JavaScript context and HTML sub context: 

<code>
<script> 
var x = ‘<%= htmlAndJavaScriptEncodedVar %>’; 
var d = document.createElement(‘div’); 
d.innerHTML = x; 
document.body.appendChild(d); 
</script> 
</code>

One consistency, however, is the need to JavaScript encode in addition to the encoding required for the sub context in the execution context. Let’s look at the individual sub contexts of the execution context in turn.

= HTML Sub Context within the Execution Context =

There are several methods and attributes which can be used to directly render HTML content within JavaScript. These methods constitute the HTML Sub Context within the Execution Context.

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

==Methods==
<code>document.write(“<HTML> Tags and markup”);</code> 
<code>document.writeln(“<HTML> Tags and markup”);</code> 

==Guideline==
In a pure HTML execution context (not HTML Attribute) use HTML and JavaScript encoding to mitigate against attacks. 
<code>element.innerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;</code> 
<code>element.outerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;</code> 

==Methods==
<code>document.write(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);</code> 
<code>document.writeln(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);</code> 

= HTML Attribute Sub Context within the Execution Context =

The HTML attribute Sub Context within the Execution context is divergent from the standard encoding rules. This is because the rule to HTML attribute encode in an HTML attribute rendering context is mitigating attacks which try to exit out of the attribute to add additional attributes and/or tags which could have executable code. When you are in a DOM execution context you only need to JavaScript encode HTML attributes which do not execute code (attributes other than event handler, CSS, and URL attributes).

For example, the general rule is to HTML Attribute encode untrusted data (data from the database, http request, user, backend 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.

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

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.

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

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.

= URL Attribute Sub Context 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.

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

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.

=CSS Attribute Sub Context 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.

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

TODO: We have not been able to get the expression() function working from DOM JavaScript code. Need some help.

=Event Handler and JavaScript code Sub Contexts 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.

<code>var x = document.createElement("a"); </code> 
<code>x.href="#”;</code> 
<code>x.setAttribute("onclick", "\u0061\u006c\u0065\u0072\u0074\u0028\u0032\u0032\u0029");</code> 
<code>var y = document.createTextNode("Click To Test"); </code> 
<code>x.appendChild(y);</code> 
<code>document.body.appendChild(x);</code> 

JavaScript event handler methods are dangerous because they implicitly do an eval() on the data passed to the DOM attribute. There are other places in JavaScript where JavaScript encoding is accepted as valid executable code.

<code>for ( var \u0062=0; \u0062 < 10; \u0062++){</code> 
<code> \u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074 </code> 
<code> .\u0077\u0072\u0069\u0074\u0065\u006c\u006e</code> 
<code> ("\u0048\u0065\u006c\u006c\u006f\u0020\u0057\u006f\u0072\u006c\u0064");</code> 
<code>} </code> 
<code>\u0077\u0069\u006e\u0064\u006f\u0077</code> 
<code>.\u0065\u0076\u0061\u006c (</code> 
<code>\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074</code> 
<code>.\u0077\u0072\u0069\u0074\u0065(111111111));</code> 

or

<code>var s = "\u0065\u0076\u0061\u006c"; </code> 
<code>var t = "\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029";</code> 
<code>window[s](t);</code> 

Because JavaScript is based on an international standard (ECMAScript), JavaScript encoding enables the support of international characters in programming constructs and variables in addition to alternate string representations (string escapes).

However the opposite is the case with HTML encoding. HTML tag elements are well defined and do not support alternate representations of the same tag. So HTML encoding cannot be used to allow the developer to have alternate representations of the <a> tag for example.

==HTML Encoding’s Disarming Nature==

In general, HTML encoding serves to castrate HTML tags which are placed in HTML and HTML attribute contexts.
Working example (no HTML encoding):

<code><a href=”…” ></code> 

Normally encoded example (Does Not Work – DNW):

<code>&#x3c;a href=… &#x3e;</code> 

HTML encoded example to highlight a fundamental difference with JavaScript encoded values (DNW):

<code><&#x61; href=…></code> 

If HTML encoding followed the same semantics as JavaScript encoding. The line above could have possibily worked to render a link. This difference makes JavaScript encoding a less viable weapon in our fight against XSS.

=Guidelines for Developing Secure Applications Utilizing JavaScript=

DOM based XSS is extremely difficult to mitigate against because of its large attack surface and lack of standardization across browsers. The guidelines below are an attempt to provide guidelines for developers when developing Web based JavaScript applications (Web 2.0) such that they can avoid XSS.

1. Untrusted data should only be treatedas 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) 
<code>var x = “<%=encodedJavaScriptData%>”;</code> 
3. Use document.createElement(“…”), element.setAttribute(“…”,”value”), element.appendChild(…), etc. to build dynamic interfaces. Avoid use of HTML rendering methods: 
#<code>element.innerHTML = “…”; </code>
#<code>element.outerHTML = “…”; </code>
#<code>document.write(…); </code>
#<code>document.writeln(…); </code> 
4. Understand the dataflow of untrusted data through your JavaScript code. If you do have to use the methods above remember to HTML and them JavaScript encode the untrusted data (Stefano Di Paola). 
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, 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. 

N-Levels of Encoding 

If your code looked like the following, you would need to only double JavaScript encode input data.

<code>setTimeout(“customFunction(‘<%=doubleJavaScriptEncodedData%>’, y)”);</code> 
<code>function customFunction (firstName, lastName) {</code> 
<code> alert("Hello" + firstName + " " + lastNam);</code> 
<code>}</code> 

The doubleJavaScriptEncodedData has its first layer of JavaScript encoding reversed in the single quotes. Then the implicit eval() of setTimeout reverses another layer of JavaScript encoding to pass the correct value to "customFunction". The reason why you only need to double JavaScript encode is that the "customFunction" function did not itself pass the input to another method which implicitly or explicitly called eval(). If "firstName" was passed to another JavaScript method which implicitly or explicitly called eval() then "<%=doubleJavaScriptEncodedData%>" above would need to be changed to "<%=tripleJavaScriptEncodedData%>". 

An important implementation note is that if the JavaScript code tries to utilize the double or triple encoded data in string comparisons, the value may be interpreted as different values based on the number of evals() the data has passed through before being passed to the if comparison and the number of times the value was JavaScript encoded. 

If "A" is double JavaScript encoded then the following if check will return false. 

<code>var x = "doubleJavaScriptEncodedA"; //\u005c\u0075\u0030\u0030\u0034\u0031</code> 
<code>if (x == "A") { </code> 
<code> alert("x is A"); </code> 
<code>} else if (x == "\u0041") { </code> 
<code> alert("This is what pops");</code> 
<code>} </code> 
This brings up an interesting design point. Ideally, the correct way to apply encoding and avoid the problem stated above is to server side encode for the output context where data is introduced into the application. Then client-side encode (using a JavaScript encoding library) for the individual sub context (DOM methods) which untrusted data is passed to. 
Here is an example: 
<code>
var input = “<%=Encoder.encodeForJS(untrustedData)%>”; //Server side encoding</code> 
<code>
window.location = ESAPI4JS.encodeForURL(input); //URL encoding is happing in JavaScript</code> 
<code>
document.writeln(ESAPI4JS.encodeForHTML(input)); //HTML encoding is happing in JavaScript
</code> 
It has been well noted by the group that any kind of reliance on a JavaScript library for encoding would be problematic as the JavaScript library could be subverted by attackers. One option is to wait till ECMAScript 5 so the JavaScript library could support immutable properties. 
Another option provided by Gaz (Gareth) was to use a specific code construct to limit mutability with anonymous clousures. 

An example follows: 

<code>function escapeHTML(str) {</code> 
<code> str = str + '';</code> 
<code> var out = '';</code> 
<code> for(var i=0;i<str.length;i++) {</code> 
<code> if(str[i] === '<') {</code> 
<code> out += '<';</code> 
<code> } else if(str[i] === '>') {</code> 
<code> out += '>';</code> 
<code> } else if(str[i] === "'") {</code> 
<code> out += '''; </code> 
<code> } else if(str[i] === '"') {</code> 
<code> out += '"'; </code> 
<code> } else {</code> 
<code> out += str[i];</code> 
<code> }</code> 
<code> }</code> 
<code> return out;</code> 
<code> }</code> 

6. Limit the usage of dynamic untrusted data to right side operations. And be aware of data which may be passed to the application which look like code (eg. “location”, “eval”). (Achim) 
<code>
var x = “<%=properly encoded data for flow%>”; </code> 

If you want to change different object attributes based on user input use a level of indirection. 

Instead of: 

<code>window[userData] = “moreUserData”; </code> 

Do the following instead: 
<code>if (userData===”location”) { </code> 
<code>window.location = “static/path/or/properly/url/encoded/value”; </code> 

7. When URL encoding in DOM be aware of character set issues as the character set in JavaScript DOM is not clearly defined (Mike Samuel). 

8. Limit access to properties objects when using object[x] accessors. (Mike Samuel). In other words use a level of indirection between untrusted input and specified object properties. 
Here is an example of the problem when using map types: 
<code>
Var myMapType = {};
myMapType[<%=untrustedData%>] = “moreUntrustedData”;
</code> 

Although the developer writing the code above was trying to add additional keyed elements to the “myMapType” object. This could be used by an attacker to subvert internal and external attributes of the “myMapType” object. 

9. Run your JavaScript in a ECMAScript 5 canopy or sand box to make it harder for your JavaScript API to be compromised (Gareth Heyes and John Stevens). 

10. Don’t eval() JSON to convert it to native JavaScript objects. Instead use JSON.toJSON() and JSON.parse() (Chris Schmidt).

= Common Problems Associated with Mitgating DOM Based XSS =
==Complex Contexts==
In many cases the context isn’t always strait forward to discern. 
<code>
<a href=”javascript:myFunction(‘<%=untrustedData%>’, “test”);”>Click Me</a></code> 
<code>…</code> 
<code><script></code> 
<code>Function myFunction (url,name) {</code> 
<code> window.location = url;</code> 
<code>}</code> 
<code></script></code> 

In the above example, untrusted data started in the rendering URL context (href attribute of an <a> tag) then changed to a JavaScript execution context (javascript: protocol handler) which passed the untrusted data to an execution URL sub context (window.location of myFunction). Because the data was introduced in JavaScript code and passed to a URL sub context the appropriate server side encoding would be the following: 

<code>
<a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(Encoder.encodeForURL(untrustedData))%>’, “test”);”>Click Me</a></code> 
<code>…</code> 

Or if you were using ECMAScript 5 with an immutable JavaScript client-side encoding libraries you could do the following: 

<code>
</code> 
<code><a href=”javascript:myFunction(‘<%=Encoder.encodeForJS(untrustedData)%>’, “test”);”>Click Me</a></code> 
<code>…</code> 
<code><script></code> 
<code>Function myFunction (url,name) {</code> 
<code> var encodedURL = ESAPI4JS.encodeForURL(url); //URL encoding using client-side scripts</code> 
<code> window.location = encodedURL;</code> 
<code>}</code> 
<code></script></code> 

== Insonsistencies of Encoding Libraries ==
There are a number of open source encoding libraries out there: 

#ESAPI
#Apache Commons String Utils
#Jtidy
#Your company’s custom implementation.

Some work on a black list others ignore important characters like “<” and “>”. ESAPI is one of the few which work on a whitelist and encode all non-alpha numeric characters.
It is important to use an encoding library which understands which characters can be used to exploit vulnerabilies in their respective contexts.
But there are misconceptions abound related to proper encoding.
==Encoding Misconceptions==
Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of “text/xhtml” or the file type extension of “*.xhtml” then HML encoding may not work to mitigate against XSS. 

For example: 

<code>
<script>
alert(1);
</script>
</code>
The HTML encoded value above is still executable. If that isn’t enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element. 

Let’s look at the sample page and script: 

<code><form name=”myForm” …></code> 
<code><input type=”text” name=”lName” value=”<%=Encoder.encodeForHTML(last_name)%>”></code> 
<code>
…</code> 
<code></form></code> 
<code><script></code> 
<code>var x = document.myForm.lName.value; //when the value is retrived the encoding is reversed</code> 
<code>document.writeln(x); //any code passed into lName is now executable.</code> 
<code></script></code> 

Finally there is the problem that certain methods in JavaScript which are usually safe can be unsafe in certain contexts. 

==Usually Safe Methods==

One example of an attribute which is usually safe is innerText. Some papers or guides advocate its use as an alternative to innerHTML to mitigate against XSS in innerHTML. However, depending on the tag which innerText is applied, code can be executed. 

<code><script></code> 
<code>var tag = document.createElement(“script”);</code> 
<code>tag.innerText = “<%=untrustedData%>”; //executes code</code> 
<code></script></code> 

 Special thanks to Jim Manico, Gareth Heyes, Stefano Di Paola, Robert Hansen, Mario Heiderich, Achim Hoffmann, John Stevens, Edwardo (SirDarkCat) Alberto Vela Nava, Chris Schmidt, Mike Samuel, Jeremy Long, Jeff Williams, and many others who help make this guide possible.

{{Cheatsheet_Navigation}}

[[Category:How To]]
[[Category:Cheatsheets]]

DOM based XSS Prevention Cheat Sheet

2011-02-17T05:56:34Z

Abraham Kang:

DOM based XSS Prevention Cheat Sheet

2011-02-17T05:54:48Z

Abraham Kang:

DOM based XSS Prevention Cheat Sheet

2011-02-17T05:22:08Z

Abraham Kang:

DOM based XSS Prevention Cheat Sheet

2011-02-17T05:19:53Z

Abraham Kang:

DOM based XSS Prevention Cheat Sheet

2011-02-17T05:16:38Z

Abraham Kang:

DOM based XSS Prevention Cheat Sheet

2011-02-17T05:13:08Z

Abraham Kang:

DOM based XSS Prevention Cheat Sheet

2011-02-17T05:09:46Z

Abraham Kang:

DOM based XSS Prevention Cheat Sheet

2011-02-17T05:08:57Z

Abraham Kang:

DOM based XSS Prevention Cheat Sheet

2011-02-17T05:06:47Z

Abraham Kang:

DOM based XSS Prevention Cheat Sheet

2011-02-17T04:59:59Z

Abraham Kang:

DOM based XSS Prevention Cheat Sheet

2011-02-17T04:54:35Z

Abraham Kang:

DOM based XSS Prevention Cheat Sheet

2011-02-15T06:07:13Z

Abraham Kang: DOM based XSS Cheatsheet

Summit 2011 Working Sessions/Session090/Deliverable 5

2011-02-14T06:20:52Z

Abraham Kang:

OWASP Licensing FAQ (Frequently Asked Questions) -- Deliverable from OWASP Summit meeting in Lisbon 2011 Disclaimer: The following is not legal advice. It is highly recommended for a licensed lawyer to review your specific situation and ascertain all relevant issues when selecting and understanding license agreements. 1. Who own the content and code submitted to OWASP? a. The author of the submitted code or content owns the code. However, the author submitting the creative work agrees to open source their work under an approved open source license. The author also has the option of completely assigning all rights in his work to OWASP. Under copyright law the author of a creative work gains copyright protection once the creative work is put into a tangible form. 2. Can I take back from OWASP the code/documentation I had previously submitted? a. Technically no, because you open sourced your code/documentation. However, you can fork your documentation/code and close source your additional changes as the owner of the original documentation/code. 3. Does OWASP require you to share back your changes? a. It depends on the license associated with the code/documentation you are modifying. Some licenses require you to share back any code changes the instant you make then. Other licenses require you to use the same license as the parent code/document which you used. Some are triggered upon distribution and others are triggered on modification or use. 4. What is the default license for information posted on the OWASP wiki? a. Creative Commons 3.0 SA Attribution 5. Can you override the default license which OWASP runs under? a. Yes, but you have to follow the directions in the license you are selecting to abide by the selected license. If the license you selected for your code/document does not include placement directions. Add a license section in the header comments of a code file or the appendix of a document. 6. Which license should I use if I want to give enterprises free will to build products on top of your submitted code or make and use changes to your submitted documents? a. BSD 7. Which license should I use to control distribution, sale or modification of the submitted code/documentation? a. It depends on the limitations you want to enforce in your submitted code/documentation. So read the license and talk to an attorney to understand what you are getting into. Remember that the more restrictive the license then the less likely that an enterprise will want to use it. 8. Is it possible to change my license after my document/code is released to the public? a. If you are the sole contributor for the document/code then you can make changes to the license at any time. If there are multiple contributors to a document or code base you will need go get agreement for the license change from all contributors.

Summit 2011 Working Sessions/Session090/Deliverable 5

2011-02-14T06:20:18Z

Abraham Kang: Created page with "OWASP Licensing FAQ (Frequently Asked Questions) -- Deliverable from OWASP Summit meeting in Lisbon 2011 Disclaimer: The following is not legal advice. It is highly recommended..."

OWASP Licensing FAQ (Frequently Asked Questions) -- Deliverable from OWASP Summit meeting in Lisbon 2011
Disclaimer: The following is not legal advice. It is highly recommended for a licensed lawyer to review your specific situation and ascertain all relevant issues when selecting and understanding license agreements.
1. Who own the content and code submitted to OWASP?
a. The author of the submitted code or content owns the code. However, the author submitting the creative work agrees to open source their work under an approved open source license. The author also has the option of completely assigning all rights in his work to OWASP. Under copyright law the author of a creative work gains copyright protection once the creative work is put into a tangible form.
2. Can I take back from OWASP the code/documentation I had previously submitted?
a. Technically no, because you open sourced your code/documentation. However, you can fork your documentation/code and close source your additional changes as the owner of the original documentation/code.
3. Does OWASP require you to share back your changes?
a. It depends on the license associated with the code/documentation you are modifying. Some licenses require you to share back any code changes the instant you make then. Other licenses require you to use the same license as the parent code/document which you used. Some are triggered upon distribution and others are triggered on modification or use.
4. What is the default license for information posted on the OWASP wiki?
a. Creative Commons 3.0 SA Attribution
5. Can you override the default license which OWASP runs under?
a. Yes, but you have to follow the directions in the license you are selecting to abide by the selected license. If the license you selected for your code/document does not include placement directions. Add a license section in the header comments of a code file or the appendix of a document.
6. Which license should I use if I want to give enterprises free will to build products on top of your submitted code or make and use changes to your submitted documents?
a. BSD
7. Which license should I use to control distribution, sale or modification of the submitted code/documentation?
a. It depends on the limitations you want to enforce in your submitted code/documentation. So read the license and talk to an attorney to understand what you are getting into. Remember that the more restrictive the license then the less likely that an enterprise will want to use it.
8. Is it possible to change my license after my document/code is released to the public?
a. If you are the sole contributor for the document/code then you can make changes to the license at any time. If there are multiple contributors to a document or code base you will need go get agreement for the license change from all contributors.

Summit 2011 Working Sessions/Session090

2011-02-14T06:19:16Z

Abraham Kang:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Summit 2011 Working Sessions test tab</noinclude>
|-

| summit_session_attendee_name1 = Abraham Kang
| summit_session_attendee_email1 = abraham.kang@owasp.org
| summit_session_attendee_username1 =
| summit_session_attendee_company1=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed1=

| summit_session_attendee_name2 = Alexandre Miguel Aniceto
| summit_session_attendee_email2 = alexandre.aniceto@sekirite.org
| summit_session_attendee_username2 = Alexandre Miguel Aniceto
| summit_session_attendee_company2= Willway
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed2=

| summit_session_attendee_name3 =
| summit_session_attendee_email3 =
| summit_session_attendee_username3 =
| summit_session_attendee_company3=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed3=

| summit_session_attendee_name4 =
| summit_session_attendee_email4 =
| summit_session_attendee_username4 =
| summit_session_attendee_company4=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed4=

| summit_session_attendee_name5 =
| summit_session_attendee_email5 =
| summit_session_attendee_username5 =
| summit_session_attendee_company5=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed5=

| summit_session_attendee_name6 =
| summit_session_attendee_email6 =
| summit_session_attendee_username6 =
| summit_session_attendee_company6=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed6=

| summit_session_attendee_name7 =
| summit_session_attendee_email7 =
| summit_session_attendee_username7 =
| summit_session_attendee_company7=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed7=

| summit_session_attendee_name8 =
| summit_session_attendee_email8 =
| summit_session_attendee_username8 =
| summit_session_attendee_company8=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed8=

| summit_session_attendee_name9 =
| summit_session_attendee_email9 =
| summit_session_attendee_username9 =
| summit_session_attendee_company9=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed9=

| summit_session_attendee_name10 =
| summit_session_attendee_email10 =
| summit_session_attendee_username10 =
| summit_session_attendee_company10=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed10=

| summit_session_attendee_name11 =
| summit_session_attendee_email11 =
| summit_session_attendee_username11 =
| summit_session_attendee_company11=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed11=

| summit_session_attendee_name12 =
| summit_session_attendee_email12 =
| summit_session_attendee_username12 =
| summit_session_attendee_company12=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed12=

| summit_session_attendee_name13 =
| summit_session_attendee_email13 =
| summit_session_attendee_username13 =
| summit_session_attendee_company13=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed13=

| summit_session_attendee_name14 =
| summit_session_attendee_email14 =
| summit_session_attendee_username14 =
| summit_session_attendee_company14=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed14=

| summit_session_attendee_name15 =
| summit_session_attendee_email15 =
| summit_session_attendee_username15 =
| summit_session_attendee_company15=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed15=

| summit_session_attendee_name16 =
| summit_session_attendee_email16 =
| summit_session_attendee_username16 =
| summit_session_attendee_company16=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed16=

| summit_session_attendee_name17 =
| summit_session_attendee_email17 =
| summit_session_attendee_username17 =
| summit_session_attendee_company17=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed17=

| summit_session_attendee_name18 =
| summit_session_attendee_email18 =
| summit_session_attendee_username18 =
| summit_session_attendee_company18=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed18=

| summit_session_attendee_name19 =
| summit_session_attendee_email19 =
| summit_session_attendee_username19 =
| summit_session_attendee_company19=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed19=

| summit_session_attendee_name20 =
| summit_session_attendee_email20 =
| summit_session_attendee_username20 =
| summit_session_attendee_company20=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed20=
|-
| summit_track_logo =
| summit_ws_logo =
| summit_session_name = OWASP Licensing
| summit_session_url = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session090

|-

| short_working_session_description= Go over the OWASP Licenses related to OWASP documentation to discuss if the is a way to make the license more amiable to corporate users thereby spurring sales of corporate sponsorships.

|-

| related_project_name1 = OWASP Guide
| related_project_url_1 = http://www.owasp.org/index.php/OWASP_Guide_Project

| related_project_name2 = ESAPI
| related_project_url_2 = http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

| related_project_name3 = ASVS
| related_project_url_3 = http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

| related_project_name4 =
| related_project_url_4 =

| related_project_name5 =
| related_project_url_5 =

|-

| summit_session_objective_name1= Discuss the goals of the OWASP Licensing model for OWASP documents and informative materials.

| summit_session_objective_name2 = Understand better the corporate use cases for OWASP documentation and artifacts.

| summit_session_objective_name3 = Identify possible options for licensing changes to spur growth in corporate sponsorships.

| summit_session_objective_name4 =

| summit_session_objective_name5 =

|-

| working_session_date_and_time =

|-

| discussion_model = participants and attendees

|-

| operational_resources = Projector, whiteboards, markers, Internet connectivity, power

|-

| working_session_additional_details = Corporations face similar problems related to educating, creating, and implementing security policies and measures. Corporations require update-to-date security material to supplement their policies. OWASP has this information but licensing constraints may be limiting use of OWASP material in enterprises.
|-

|summit_session_deliverable_name1 = Licensing Requirements for OWASP documentation

|summit_session_deliverable_name2 = List existing Licenses used by OWASP projects.

|summit_session_deliverable_name3 = Problem corporations face with adopting and utilizing OWASP materials and code

|summit_session_deliverable_name4 = Recommendations for changes in the OWASP License

|summit_session_deliverable_name5 = OWASP: Licensing FAQs

|summit_session_deliverable_name6 =

|summit_session_deliverable_name7 =

|summit_session_deliverable_name8 =

|-

| summit_session_leader_name1 = Abraham Kang
| summit_session_leader_email1 = abraham.kang@owasp.org
| summit_session_leader_username1 =

| summit_session_leader_name2 =
| summit_session_leader_email2 =
| summit_session_leader_username2 =

| summit_session_leader_name3 =
| summit_session_leader_email3 =
| summit_session_leader_username3 =

|-

| operational_leader_name1 = Abraham Kang
| operational_leader_email1 = abraham.kang@owasp.org
| operational_leader_username1 = Abraham Kang

|-

| meeting_notes = See the "discussion" page for deliverables

|-
| session_name_mask = Session090
| session_home_page = Summit_2011_Working_Sessions/Session090
}} Test

Summit 2011 Working Sessions/Session090

2011-02-14T06:13:03Z

Abraham Kang:

{{Template:<IMG class=FCK__MWIncludeonly src="http://www.owasp.org/extensions/FCKeditor/fckeditor/editor/images/spacer.gif" width=1 height=1 _fckfakelement="true" _fckrealelement="3" _fck_mw_includeonly="true"><IMG class=FCK__MWNoinclude src="http://www.owasp.org/extensions/FCKeditor/fckeditor/editor/images/spacer.gif" width=1 height=1 _fckfakelement="true" _fckrealelement="2" _fck_mw_noinclude="true">
|-

| summit_session_attendee_name1 = Abraham Kang
| summit_session_attendee_email1 = abraham.kang@owasp.org
| summit_session_attendee_username1 =
| summit_session_attendee_company1=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed1=

| summit_session_attendee_name2 = Alexandre Miguel Aniceto
| summit_session_attendee_email2 = alexandre.aniceto@sekirite.org
| summit_session_attendee_username2 = Alexandre Miguel Aniceto
| summit_session_attendee_company2= Willway
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed2=

| summit_session_attendee_name3 =
| summit_session_attendee_email3 =
| summit_session_attendee_username3 =
| summit_session_attendee_company3=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed3=

| summit_session_attendee_name4 =
| summit_session_attendee_email4 =
| summit_session_attendee_username4 =
| summit_session_attendee_company4=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed4=

| summit_session_attendee_name5 =
| summit_session_attendee_email5 =
| summit_session_attendee_username5 =
| summit_session_attendee_company5=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed5=

| summit_session_attendee_name6 =
| summit_session_attendee_email6 =
| summit_session_attendee_username6 =
| summit_session_attendee_company6=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed6=

| summit_session_attendee_name7 =
| summit_session_attendee_email7 =
| summit_session_attendee_username7 =
| summit_session_attendee_company7=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed7=

| summit_session_attendee_name8 =
| summit_session_attendee_email8 =
| summit_session_attendee_username8 =
| summit_session_attendee_company8=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed8=

| summit_session_attendee_name9 =
| summit_session_attendee_email9 =
| summit_session_attendee_username9 =
| summit_session_attendee_company9=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed9=

| summit_session_attendee_name10 =
| summit_session_attendee_email10 =
| summit_session_attendee_username10 =
| summit_session_attendee_company10=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed10=

| summit_session_attendee_name11 =
| summit_session_attendee_email11 =
| summit_session_attendee_username11 =
| summit_session_attendee_company11=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed11=

| summit_session_attendee_name12 =
| summit_session_attendee_email12 =
| summit_session_attendee_username12 =
| summit_session_attendee_company12=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed12=

| summit_session_attendee_name13 =
| summit_session_attendee_email13 =
| summit_session_attendee_username13 =
| summit_session_attendee_company13=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed13=

| summit_session_attendee_name14 =
| summit_session_attendee_email14 =
| summit_session_attendee_username14 =
| summit_session_attendee_company14=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed14=

| summit_session_attendee_name15 =
| summit_session_attendee_email15 =
| summit_session_attendee_username15 =
| summit_session_attendee_company15=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed15=

| summit_session_attendee_name16 =
| summit_session_attendee_email16 =
| summit_session_attendee_username16 =
| summit_session_attendee_company16=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed16=

| summit_session_attendee_name17 =
| summit_session_attendee_email17 =
| summit_session_attendee_username17 =
| summit_session_attendee_company17=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed17=

| summit_session_attendee_name18 =
| summit_session_attendee_email18 =
| summit_session_attendee_username18 =
| summit_session_attendee_company18=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed18=

| summit_session_attendee_name19 =
| summit_session_attendee_email19 =
| summit_session_attendee_username19 =
| summit_session_attendee_company19=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed19=

| summit_session_attendee_name20 =
| summit_session_attendee_email20 =
| summit_session_attendee_username20 =
| summit_session_attendee_company20=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed20=
|-
| summit_track_logo =
| summit_ws_logo =
| summit_session_name = OWASP Licensing
| summit_session_url = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session090

|-

| short_working_session_description= Go over the OWASP Licenses related to OWASP documentation to discuss if the is a way to make the license more amiable to corporate users thereby spurring sales of corporate sponsorships.

|-

| related_project_name1 = OWASP Guide
| related_project_url_1 = http://www.owasp.org/index.php/OWASP_Guide_Project

| related_project_name2 = ESAPI
| related_project_url_2 = http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

| related_project_name3 = ASVS
| related_project_url_3 = http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

| related_project_name4 =
| related_project_url_4 =

| related_project_name5 =
| related_project_url_5 =

|-

| summit_session_objective_name1= Discuss the goals of the OWASP Licensing model for OWASP documents and informative materials.

| summit_session_objective_name2 = Understand better the corporate use cases for OWASP documentation and artifacts.

| summit_session_objective_name3 = Identify possible options for licensing changes to spur growth in corporate sponsorships.

| summit_session_objective_name4 =

| summit_session_objective_name5 =

|-

| working_session_date_and_time =

|-

| discussion_model = participants and attendees

|-

| operational_resources = Projector, whiteboards, markers, Internet connectivity, power

|-

| working_session_additional_details = Corporations face similar problems related to educating, creating, and implementing security policies and measures. Corporations require update-to-date security material to supplement their policies. OWASP has this information but licensing constraints may be limiting use of OWASP material in enterprises.
|-

|summit_session_deliverable_name1 = Licensing Requirements for OWASP documentation

|summit_session_deliverable_name2 = List existing Licenses used by OWASP projects.

|summit_session_deliverable_name3 = Problem corporations face with adopting and utilizing OWASP materials and code

|summit_session_deliverable_name4 = Recommendations for changes in the OWASP License

|summit_session_deliverable_name5 = OWASP: Licensing FAQs

|summit_session_deliverable_name6 =

|summit_session_deliverable_name7 =

|summit_session_deliverable_name8 =

|-

| summit_session_leader_name1 = Abraham Kang
| summit_session_leader_email1 = abraham.kang@owasp.org
| summit_session_leader_username1 =

| summit_session_leader_name2 =
| summit_session_leader_email2 =
| summit_session_leader_username2 =

| summit_session_leader_name3 =
| summit_session_leader_email3 =
| summit_session_leader_username3 =

|-

| operational_leader_name1 = Abraham Kang
| operational_leader_email1 = abraham.kang@owasp.org
| operational_leader_username1 = Abraham Kang

|-

| meeting_notes = See the "discussion" page for deliverables

|-
| session_name_mask = Session090
| session_home_page = Summit_2011_Working_Sessions/Session090
}}

Talk:Summit 2011 Working Sessions/Session090

2011-02-14T06:10:27Z

Abraham Kang:

'''OWASP Licensing FAQ (Frequently Asked Questions) -- Deliverable 1 from OWASP Summit meeting in Lisbon 2011'''

Disclaimer: The following is not legal advice. It is highly recommended for a licensed lawyer to review your specific situation and ascertain all relevant issues when selecting and understanding license agreements.

 1. Who own the content and code submitted to OWASP? a. The author of the submitted code or content owns the code. However, the author submitting the creative work agrees to open source their work under an approved open source license. The author also has the option of completely assigning all rights in his work to OWASP. Under copyright law the author of a creative work gains copyright protection once the creative work is put into a tangible form.

2. Can I take back from OWASP the code/documentation I had previously submitted? a. Technically no, because you open sourced your code/documentation. However, you can fork your documentation/code and close source your additional changes as the owner of the original documentation/code.

3. Does OWASP require you to share back your changes? a. It depends on the license associated with the code/documentation you are modifying. Some licenses require you to share back any code changes the instant you make then. Other licenses require you to use the same license as the parent code/document which you used. Some are triggered upon distribution and others are triggered on modification or use.

4. What is the default license for information posted on the OWASP wiki? a. Creative Commons 3.0 SA Attribution

5. Can you override the default license which OWASP runs under? a. Yes, but you have to follow the directions in the license you are selecting to abide by the selected license. If the license you selected for your code/document does not include placement directions. Add a license section in the header comments of a code file or the appendix of a document.

6. Which license should I use if I want to give enterprises free will to build products on top of your submitted code or make and use changes to your submitted documents? a. BSD

7. Which license should I use to control distribution, sale or modification of the submitted code/documentation? a. It depends on the limitations you want to enforce in your submitted code/documentation. So read the license and talk to an attorney to understand what you are getting into. Remember that the more restrictive the license then the less likely that an enterprise will want to use it.

8. Is it possible to change my license after my document/code is released to the public? a. If you are the sole contributor for the document/code then you can make changes to the license at any time. If there are multiple contributors to a document or code base you will need go get agreement for the license change from all contributors.

 

'''OWASP Licensing Issues to Consider -- Deliverable 2 from OWASP Summit meeting in Lisbon 2011'''

1. Should we require contributors to completely assign their rights to OWASP. During the meeting it was mentioned that Apache does this and it makes changing licenses and other management functions easier.

2. How should we deal with a multi-contributor document or code base where there is a lack of agreement for license types or other things requiring a unanimous agreement.

3. I thought that the choice of licensing by owner was open to any open source license. Should we limit the options?

4. It was determined that the major issue with enterprise adoption of OWASP documents was the requirement to open source/share back any derivative documents upon use (older licenses) or utilize the same or similar open source license upon distribution (Creative Commons 3.0 SA Attribution). Can we clarify the meaning of “distribution” such that the passing of derived works to partners or affiliates does not constitute public “distribution” under Creative Commons 3.0 SA Attribution)?

5. Can we have a licensed attorney review the licenses in question to ensure that there are no hidden issues with OWASP licensing? For example, to discuss if C.C. Share Alike 3.0 SA Attribution is the correct license for OWASP documentation. Also to see if there is a process which can be used to update older document licenses (such as giving contributors notice and opportunity to object to license changes)

6. Is there any difference with international contributors as to copyright and ownership rules?

7. The OWASP:Copyright page needs to be updated to Creative Commons 3.0 SA Attribution.

Summit 2011 Working Sessions/Session090/Deliverable 4

2011-02-14T06:08:05Z

Abraham Kang: Created page with "Clarify the term "distribution" so that it does not include affiliates and partners of enterprises.  This would help enterprises who modify OWASP documents to use them ..."

Clarify the term "distribution" so that it does not include affiliates and partners of enterprises.  This would help enterprises who modify OWASP documents to use them for internal operations with occasional distribution to affiliates and partners.

Summit 2011 Working Sessions/Session090/Deliverable 3

2011-02-14T06:01:35Z

Abraham Kang: Created page with "4. It was determined that the major issue with enterprise adoption of OWASP documents was the requirement to open source/share back any derivative documents upon use (older licen..."

4. It was determined that the major issue with enterprise adoption of OWASP documents was the requirement to open source/share back any derivative documents upon use (older licenses) or utilize the same or similar open source license upon distribution (Creative Commons 3.0 SA Attribution). Can we clarify the meaning of “distribution” such that the passing of derived works to partners or affiliates does not constitute public “distribution” under Creative Commons 3.0 SA Attribution)?

Summit 2011 Working Sessions/Session090/Deliverable 2

2011-02-14T05:59:43Z

Abraham Kang:

The most popular licenses used at OWASP are

GNU Free Documentation License

LGPL ang GPL

Creative Commons 3.0 SA Attribution (all wiki content is this)

BSD

Summit 2011 Working Sessions/Session090/Deliverable 2

2011-02-14T05:53:05Z

Abraham Kang: Created page with "The most popular licenses used at OWASP are GNU Free Documentation License LGPL ang GPL Creative Commons 3.0 SA Attribution BSD"

The most popular licenses used at OWASP are
GNU Free Documentation License
LGPL ang GPL
Creative Commons 3.0 SA Attribution
BSD

Summit 2011 Working Sessions/Session090

2011-02-14T05:44:32Z

Abraham Kang:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Summit 2011 Working Sessions test tab</noinclude>
|-

| summit_session_attendee_name1 = Abraham Kang
| summit_session_attendee_email1 = abraham.kang@owasp.org
| summit_session_attendee_username1 =
| summit_session_attendee_company1=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed1=

| summit_session_attendee_name2 = Alexandre Miguel Aniceto
| summit_session_attendee_email2 = alexandre.aniceto@sekirite.org
| summit_session_attendee_username2 = Alexandre Miguel Aniceto
| summit_session_attendee_company2= Willway
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed2=

| summit_session_attendee_name3 =
| summit_session_attendee_email3 =
| summit_session_attendee_username3 =
| summit_session_attendee_company3=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed3=

| summit_session_attendee_name4 =
| summit_session_attendee_email4 =
| summit_session_attendee_username4 =
| summit_session_attendee_company4=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed4=

| summit_session_attendee_name5 =
| summit_session_attendee_email5 =
| summit_session_attendee_username5 =
| summit_session_attendee_company5=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed5=

| summit_session_attendee_name6 =
| summit_session_attendee_email6 =
| summit_session_attendee_username6 =
| summit_session_attendee_company6=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed6=

| summit_session_attendee_name7 =
| summit_session_attendee_email7 =
| summit_session_attendee_username7 =
| summit_session_attendee_company7=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed7=

| summit_session_attendee_name8 =
| summit_session_attendee_email8 =
| summit_session_attendee_username8 =
| summit_session_attendee_company8=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed8=

| summit_session_attendee_name9 =
| summit_session_attendee_email9 =
| summit_session_attendee_username9 =
| summit_session_attendee_company9=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed9=

| summit_session_attendee_name10 =
| summit_session_attendee_email10 =
| summit_session_attendee_username10 =
| summit_session_attendee_company10=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed10=

| summit_session_attendee_name11 =
| summit_session_attendee_email11 =
| summit_session_attendee_username11 =
| summit_session_attendee_company11=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed11=

| summit_session_attendee_name12 =
| summit_session_attendee_email12 =
| summit_session_attendee_username12 =
| summit_session_attendee_company12=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed12=

| summit_session_attendee_name13 =
| summit_session_attendee_email13 =
| summit_session_attendee_username13 =
| summit_session_attendee_company13=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed13=

| summit_session_attendee_name14 =
| summit_session_attendee_email14 =
| summit_session_attendee_username14 =
| summit_session_attendee_company14=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed14=

| summit_session_attendee_name15 =
| summit_session_attendee_email15 =
| summit_session_attendee_username15 =
| summit_session_attendee_company15=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed15=

| summit_session_attendee_name16 =
| summit_session_attendee_email16 =
| summit_session_attendee_username16 =
| summit_session_attendee_company16=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed16=

| summit_session_attendee_name17 =
| summit_session_attendee_email17 =
| summit_session_attendee_username17 =
| summit_session_attendee_company17=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed17=

| summit_session_attendee_name18 =
| summit_session_attendee_email18 =
| summit_session_attendee_username18 =
| summit_session_attendee_company18=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed18=

| summit_session_attendee_name19 =
| summit_session_attendee_email19 =
| summit_session_attendee_username19 =
| summit_session_attendee_company19=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed19=

| summit_session_attendee_name20 =
| summit_session_attendee_email20 =
| summit_session_attendee_username20 =
| summit_session_attendee_company20=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed20=
|-
| summit_track_logo =
| summit_ws_logo =
| summit_session_name = OWASP Licensing
| summit_session_url = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session090

|-

| short_working_session_description= Go over the OWASP Licenses related to OWASP documentation to discuss if the is a way to make the license more amiable to corporate users thereby spurring sales of corporate sponsorships.

|-

| related_project_name1 = OWASP Guide
| related_project_url_1 = http://www.owasp.org/index.php/OWASP_Guide_Project

| related_project_name2 = ESAPI
| related_project_url_2 = http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

| related_project_name3 = ASVS
| related_project_url_3 = http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

| related_project_name4 =
| related_project_url_4 =

| related_project_name5 =
| related_project_url_5 =

|-

| summit_session_objective_name1= Discuss the goals of the OWASP Licensing model for OWASP documents and informative materials.

| summit_session_objective_name2 = Understand better the corporate use cases for OWASP documentation and artifacts.

| summit_session_objective_name3 = Identify possible options for licensing changes to spur growth in corporate sponsorships.

| summit_session_objective_name4 =

| summit_session_objective_name5 =

|-

| working_session_date_and_time =

|-

| discussion_model = participants and attendees

|-

| operational_resources = Projector, whiteboards, markers, Internet connectivity, power

|-

| working_session_additional_details = Corporations face similar problems related to educating, creating, and implementing security policies and measures. Corporations require update-to-date security material to supplement their policies. OWASP has this information but licensing constraints may be limiting use of OWASP material in enterprises.
|-

|summit_session_deliverable_name1 = Licensing Requirements for OWASP documentation

|summit_session_deliverable_name2 = List existing Licenses used by OWASP projects.

|summit_session_deliverable_name3 = Problem corporations face with adopting and utilizing OWASP materials and code

|summit_session_deliverable_name4 = Recommendations for changes in the OWASP License

|summit_session_deliverable_name5 =

|summit_session_deliverable_name6 =

|summit_session_deliverable_name7 =

|summit_session_deliverable_name8 =

|-

| summit_session_leader_name1 = Abraham Kang
| summit_session_leader_email1 = abraham.kang@owasp.org
| summit_session_leader_username1 =

| summit_session_leader_name2 =
| summit_session_leader_email2 =
| summit_session_leader_username2 =

| summit_session_leader_name3 =
| summit_session_leader_email3 =
| summit_session_leader_username3 =

|-

| operational_leader_name1 = Abraham Kang
| operational_leader_email1 = abraham.kang@owasp.org
| operational_leader_username1 = Abraham Kang

|-

| meeting_notes = See the "discussion" page for deliverables

|-
| session_name_mask =  Session090
| session_home_page =  Summit_2011_Working_Sessions/Session090
}}

Summit 2011 Working Sessions/Session090

2011-02-14T05:42:42Z

Abraham Kang:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Summit 2011 Working Sessions test tab</noinclude>
|-

| summit_session_attendee_name1 = Abraham Kang
| summit_session_attendee_email1 = abraham.kang@owasp.org
| summit_session_attendee_username1 =
| summit_session_attendee_company1=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed1=

| summit_session_attendee_name2 = Alexandre Miguel Aniceto
| summit_session_attendee_email2 = alexandre.aniceto@sekirite.org
| summit_session_attendee_username2 = Alexandre Miguel Aniceto
| summit_session_attendee_company2= Willway
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed2=

| summit_session_attendee_name3 =
| summit_session_attendee_email3 =
| summit_session_attendee_username3 =
| summit_session_attendee_company3=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed3=

| summit_session_attendee_name4 =
| summit_session_attendee_email4 =
| summit_session_attendee_username4 =
| summit_session_attendee_company4=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed4=

| summit_session_attendee_name5 =
| summit_session_attendee_email5 =
| summit_session_attendee_username5 =
| summit_session_attendee_company5=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed5=

| summit_session_attendee_name6 =
| summit_session_attendee_email6 =
| summit_session_attendee_username6 =
| summit_session_attendee_company6=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed6=

| summit_session_attendee_name7 =
| summit_session_attendee_email7 =
| summit_session_attendee_username7 =
| summit_session_attendee_company7=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed7=

| summit_session_attendee_name8 =
| summit_session_attendee_email8 =
| summit_session_attendee_username8 =
| summit_session_attendee_company8=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed8=

| summit_session_attendee_name9 =
| summit_session_attendee_email9 =
| summit_session_attendee_username9 =
| summit_session_attendee_company9=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed9=

| summit_session_attendee_name10 =
| summit_session_attendee_email10 =
| summit_session_attendee_username10 =
| summit_session_attendee_company10=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed10=

| summit_session_attendee_name11 =
| summit_session_attendee_email11 =
| summit_session_attendee_username11 =
| summit_session_attendee_company11=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed11=

| summit_session_attendee_name12 =
| summit_session_attendee_email12 =
| summit_session_attendee_username12 =
| summit_session_attendee_company12=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed12=

| summit_session_attendee_name13 =
| summit_session_attendee_email13 =
| summit_session_attendee_username13 =
| summit_session_attendee_company13=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed13=

| summit_session_attendee_name14 =
| summit_session_attendee_email14 =
| summit_session_attendee_username14 =
| summit_session_attendee_company14=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed14=

| summit_session_attendee_name15 =
| summit_session_attendee_email15 =
| summit_session_attendee_username15 =
| summit_session_attendee_company15=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed15=

| summit_session_attendee_name16 =
| summit_session_attendee_email16 =
| summit_session_attendee_username16 =
| summit_session_attendee_company16=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed16=

| summit_session_attendee_name17 =
| summit_session_attendee_email17 =
| summit_session_attendee_username17 =
| summit_session_attendee_company17=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed17=

| summit_session_attendee_name18 =
| summit_session_attendee_email18 =
| summit_session_attendee_username18 =
| summit_session_attendee_company18=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed18=

| summit_session_attendee_name19 =
| summit_session_attendee_email19 =
| summit_session_attendee_username19 =
| summit_session_attendee_company19=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed19=

| summit_session_attendee_name20 =
| summit_session_attendee_email20 =
| summit_session_attendee_username20 =
| summit_session_attendee_company20=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed20=
|-
| summit_track_logo =
| summit_ws_logo =
| summit_session_name = OWASP Licensing
| summit_session_url = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session090

|-

| short_working_session_description= Go over the OWASP Licenses related to OWASP documentation to discuss if the is a way to make the license more amiable to corporate users thereby spurring sales of corporate sponsorships.

|-

| related_project_name1 = OWASP Guide
| related_project_url_1 = http://www.owasp.org/index.php/OWASP_Guide_Project

| related_project_name2 = ESAPI
| related_project_url_2 = http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

| related_project_name3 = ASVS
| related_project_url_3 = http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

| related_project_name4 =
| related_project_url_4 =

| related_project_name5 =
| related_project_url_5 =

|-

| summit_session_objective_name1= Discuss the goals of the OWASP Licensing model for OWASP documents and informative materials.

| summit_session_objective_name2 = Understand better the corporate use cases for OWASP documentation and artifacts.

| summit_session_objective_name3 = Identify possible options for licensing changes to spur growth in corporate sponsorships.

| summit_session_objective_name4 =

| summit_session_objective_name5 =

|-

| working_session_date_and_time =

|-

| discussion_model = participants and attendees

|-

| operational_resources = Projector, whiteboards, markers, Internet connectivity, power

|-

| working_session_additional_details = Corporations face similar problems related to educating, creating, and implementing security policies and measures. Corporations require update-to-date security material to supplement their policies. OWASP has this information but licensing constraints may be limiting use of OWASP material in enterprises.
|-

|summit_session_deliverable_name1 = Licensing Requirements for OWASP documentation

|summit_session_deliverable_name2 = List is existing Licenses used by OWASP projects.

|summit_session_deliverable_name3 = Problem corporations face with adopting and utilizing OWASP materials and code

|summit_session_deliverable_name4 = Recommendations for changes in the OWASP License

|summit_session_deliverable_name5 =

|summit_session_deliverable_name6 =

|summit_session_deliverable_name7 =

|summit_session_deliverable_name8 =

|-

| summit_session_leader_name1 = Abraham Kang
| summit_session_leader_email1 = abraham.kang@owasp.org
| summit_session_leader_username1 =

| summit_session_leader_name2 =
| summit_session_leader_email2 =
| summit_session_leader_username2 =

| summit_session_leader_name3 =
| summit_session_leader_email3 =
| summit_session_leader_username3 =

|-

| operational_leader_name1 = Abraham Kang
| operational_leader_email1 = abraham.kang@owasp.org
| operational_leader_username1 = Abraham Kang

|-

| meeting_notes = See the "discussion" page for deliverables

|-
| session_name_mask =  Session090
| session_home_page =  Summit_2011_Working_Sessions/Session090
}}

Summit 2011 Working Sessions/Session090

2011-02-14T05:41:07Z

Abraham Kang:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Summit 2011 Working Sessions test tab</noinclude>
|-

| summit_session_attendee_name1 = Abraham Kang
| summit_session_attendee_email1 = abraham.kang@owasp.org
| summit_session_attendee_username1 =
| summit_session_attendee_company1=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed1=

| summit_session_attendee_name2 = Alexandre Miguel Aniceto
| summit_session_attendee_email2 = alexandre.aniceto@sekirite.org
| summit_session_attendee_username2 = Alexandre Miguel Aniceto
| summit_session_attendee_company2= Willway
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed2=

| summit_session_attendee_name3 =
| summit_session_attendee_email3 =
| summit_session_attendee_username3 =
| summit_session_attendee_company3=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed3=

| summit_session_attendee_name4 =
| summit_session_attendee_email4 =
| summit_session_attendee_username4 =
| summit_session_attendee_company4=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed4=

| summit_session_attendee_name5 =
| summit_session_attendee_email5 =
| summit_session_attendee_username5 =
| summit_session_attendee_company5=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed5=

| summit_session_attendee_name6 =
| summit_session_attendee_email6 =
| summit_session_attendee_username6 =
| summit_session_attendee_company6=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed6=

| summit_session_attendee_name7 =
| summit_session_attendee_email7 =
| summit_session_attendee_username7 =
| summit_session_attendee_company7=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed7=

| summit_session_attendee_name8 =
| summit_session_attendee_email8 =
| summit_session_attendee_username8 =
| summit_session_attendee_company8=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed8=

| summit_session_attendee_name9 =
| summit_session_attendee_email9 =
| summit_session_attendee_username9 =
| summit_session_attendee_company9=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed9=

| summit_session_attendee_name10 =
| summit_session_attendee_email10 =
| summit_session_attendee_username10 =
| summit_session_attendee_company10=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed10=

| summit_session_attendee_name11 =
| summit_session_attendee_email11 =
| summit_session_attendee_username11 =
| summit_session_attendee_company11=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed11=

| summit_session_attendee_name12 =
| summit_session_attendee_email12 =
| summit_session_attendee_username12 =
| summit_session_attendee_company12=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed12=

| summit_session_attendee_name13 =
| summit_session_attendee_email13 =
| summit_session_attendee_username13 =
| summit_session_attendee_company13=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed13=

| summit_session_attendee_name14 =
| summit_session_attendee_email14 =
| summit_session_attendee_username14 =
| summit_session_attendee_company14=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed14=

| summit_session_attendee_name15 =
| summit_session_attendee_email15 =
| summit_session_attendee_username15 =
| summit_session_attendee_company15=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed15=

| summit_session_attendee_name16 =
| summit_session_attendee_email16 =
| summit_session_attendee_username16 =
| summit_session_attendee_company16=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed16=

| summit_session_attendee_name17 =
| summit_session_attendee_email17 =
| summit_session_attendee_username17 =
| summit_session_attendee_company17=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed17=

| summit_session_attendee_name18 =
| summit_session_attendee_email18 =
| summit_session_attendee_username18 =
| summit_session_attendee_company18=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed18=

| summit_session_attendee_name19 =
| summit_session_attendee_email19 =
| summit_session_attendee_username19 =
| summit_session_attendee_company19=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed19=

| summit_session_attendee_name20 =
| summit_session_attendee_email20 =
| summit_session_attendee_username20 =
| summit_session_attendee_company20=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed20=
|-
| summit_track_logo =
| summit_ws_logo =
| summit_session_name = OWASP Licensing
| summit_session_url = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session090

|-

| short_working_session_description= Go over the OWASP Licenses related to OWASP documentation to discuss if the is a way to make the license more amiable to corporate users thereby spurring sales of corporate sponsorships.

|-

| related_project_name1 = OWASP Guide
| related_project_url_1 = http://www.owasp.org/index.php/OWASP_Guide_Project

| related_project_name2 = ESAPI
| related_project_url_2 = http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

| related_project_name3 = ASVS
| related_project_url_3 = http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

| related_project_name4 =
| related_project_url_4 =

| related_project_name5 =
| related_project_url_5 =

|-

| summit_session_objective_name1= Discuss the goals of the OWASP Licensing model for OWASP documents and informative materials.

| summit_session_objective_name2 = Understand better the corporate use cases for OWASP documentation and artifacts.

| summit_session_objective_name3 = Identify possible options for licensing changes to spur growth in corporate sponsorships.

| summit_session_objective_name4 =

| summit_session_objective_name5 =

|-

| working_session_date_and_time =

|-

| discussion_model = participants and attendees

|-

| operational_resources = Projector, whiteboards, markers, Internet connectivity, power

|-

| working_session_additional_details = Corporations face similar problems related to educating, creating, and implementing security policies and measures. Corporations require update-to-date security material to supplement their policies. OWASP has this information but licensing constraints may be limiting use of OWASP material in enterprises.
|-

|summit_session_deliverable_name1 = Licensing Requirements for OWASP documentation

|summit_session_deliverable_name2 = List is existing Licenses used by OWASP projects.

|summit_session_deliverable_name3 = Problem corporations face with adopting and utilizing OWASP materials and code

|summit_session_deliverable_name4 = Recommendations for changes in the OWASP License

|summit_session_deliverable_name5 =

|summit_session_deliverable_name6 =

|summit_session_deliverable_name7 =

|summit_session_deliverable_name8 =

|-

| summit_session_leader_name1 = Abraham Kang
| summit_session_leader_email1 = abraham.kang@owasp.org
| summit_session_leader_username1 =

| summit_session_leader_name2 =
| summit_session_leader_email2 =
| summit_session_leader_username2 =

| summit_session_leader_name3 =
| summit_session_leader_email3 =
| summit_session_leader_username3 =

|-

| operational_leader_name1 = Abraham Kang
| operational_leader_email1 = abraham.kang@owasp.org
| operational_leader_username1 = Abraham Kang

|-

| meeting_notes = See the "discussion" page for diliverables

|-
| session_name_mask =  Session090
| session_home_page =  Summit_2011_Working_Sessions/Session090
}}

Summit 2011 Working Sessions/Session090/Deliverable 1

2011-02-14T05:31:25Z

Abraham Kang: Created page with "OWASP only asks that contributors utilize an approved Open Source License. However, the preferred license for wiki content is the Creative Commons 3.0 SA Attribution."

OWASP only asks that contributors utilize an approved Open Source License.

However, the preferred license for wiki content is the Creative Commons 3.0 SA Attribution.

Talk:Summit 2011 Working Sessions/Session090

2011-02-14T05:19:52Z

Abraham Kang: 2 Deliverables from Session Workshop

Summit 2011 Working Sessions/Session086

2011-02-04T21:44:07Z

Abraham Kang:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Summit 2011 Working Sessions test tab</noinclude>
|-

| summit_session_attendee_name1 = Abraham Kang
| summit_session_attendee_email1 = abraham.kang@owasp.org
| summit_session_attendee_username1 = Abraham Kang
| summit_session_attendee_company1=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed1=

| summit_session_attendee_name2 =
| summit_session_attendee_email2 =
| summit_session_attendee_username2 =
| summit_session_attendee_company2=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed2=

| summit_session_attendee_name3 =
| summit_session_attendee_email3 =
| summit_session_attendee_username3 =
| summit_session_attendee_company3=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed3=

| summit_session_attendee_name4 =
| summit_session_attendee_email4 =
| summit_session_attendee_username4 =
| summit_session_attendee_company4=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed4=

| summit_session_attendee_name5 =
| summit_session_attendee_email5 =
| summit_session_attendee_username5 =
| summit_session_attendee_company5=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed5=

| summit_session_attendee_name6 =
| summit_session_attendee_email6 =
| summit_session_attendee_username6 =
| summit_session_attendee_company6=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed6=

| summit_session_attendee_name7 =
| summit_session_attendee_email7 =
| summit_session_attendee_username7 =
| summit_session_attendee_company7=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed7=

| summit_session_attendee_name8 =
| summit_session_attendee_email8 =
| summit_session_attendee_username8 =
| summit_session_attendee_company8=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed8=

| summit_session_attendee_name9 =
| summit_session_attendee_email9 =
| summit_session_attendee_username9 =
| summit_session_attendee_company9=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed9=

| summit_session_attendee_name10 =
| summit_session_attendee_email10 =
| summit_session_attendee_username10 =
| summit_session_attendee_company10=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed10=

| summit_session_attendee_name11 =
| summit_session_attendee_email11 =
| summit_session_attendee_username11 =
| summit_session_attendee_company11=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed11=

| summit_session_attendee_name12 =
| summit_session_attendee_email12 =
| summit_session_attendee_username12 =
| summit_session_attendee_company12=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed12=

| summit_session_attendee_name13 =
| summit_session_attendee_email13 =
| summit_session_attendee_username13 =
| summit_session_attendee_company13=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed13=

| summit_session_attendee_name14 =
| summit_session_attendee_email14 =
| summit_session_attendee_username14 =
| summit_session_attendee_company14=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed14=

| summit_session_attendee_name15 =
| summit_session_attendee_email15 =
| summit_session_attendee_username15 =
| summit_session_attendee_company15=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed15=

| summit_session_attendee_name16 =
| summit_session_attendee_email16 =
| summit_session_attendee_username16 =
| summit_session_attendee_company16=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed16=

| summit_session_attendee_name17 =
| summit_session_attendee_email17 =
| summit_session_attendee_username17 =
| summit_session_attendee_company17=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed17=

| summit_session_attendee_name18 =
| summit_session_attendee_email18 =
| summit_session_attendee_username18 =
| summit_session_attendee_company18=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed18=

| summit_session_attendee_name19 =
| summit_session_attendee_email19 =
| summit_session_attendee_username19 =
| summit_session_attendee_company19=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed19=

| summit_session_attendee_name20 =
| summit_session_attendee_email20 =
| summit_session_attendee_username20 =
| summit_session_attendee_company20=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed20=

|-
| summit_track_logo = [[Image:T._metrics.jpg]]
| summit_ws_logo = [[Image:WS._metrics.jpg]]
| summit_session_name = Creating a unified "finding"
| summit_session_url = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session086
| mailing_list =

|-

| short_working_session_description=

|-

| related_project_name1 =
| related_project_url_1 =

| related_project_name2 =
| related_project_url_2 =

| related_project_name3 =
| related_project_url_3 =

| related_project_name4 =
| related_project_url_4 =

| related_project_name5 =
| related_project_url_5 =

|-

| summit_session_objective_name1=

| summit_session_objective_name2 =

| summit_session_objective_name3 =

| summit_session_objective_name4 =

| summit_session_objective_name5 =

|-

| working_session_date_and_time =

|-

| discussion_model = participants and attendees

|-

| operational_resources = Projector, whiteboards, markers, Internet connectivity, power

|-

| working_session_additional_details =

|-

|summit_session_deliverable_name1 =

|summit_session_deliverable_name2 =

|summit_session_deliverable_name3 =

|summit_session_deliverable_name4 =

|summit_session_deliverable_name5 =

|summit_session_deliverable_name6 =

|summit_session_deliverable_name7 =

|summit_session_deliverable_name8 =

|-

| summit_session_leader_name1 = Dinis Cruz
| summit_session_leader_email1 = dinis.cruz@owasp.org
| summit_session_leader_username1 = Dinis.cruz

| summit_session_leader_name2 =
| summit_session_leader_email2 =
| summit_session_leader_username2 =

| summit_session_leader_name3 =
| summit_session_leader_email3 =
| summit_session_leader_username3 =

|-

| operational_leader_name1 =
| operational_leader_email1 =
| operational_leader_username1 =

|-
| meeting_notes =

|-
| session_name_mask =  Session086
| session_home_page =  Summit_2011_Working_Sessions/Session086
}}

Summit 2011 Working Sessions/Session002

2011-02-04T21:42:24Z

Abraham Kang:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Summit 2011 Working Sessions test tab</noinclude>
|-

| summit_session_attendee_name1 = John Wilander
| summit_session_attendee_email1 = john.wilander@owasp.org
| summit_session_attendee_username1 = John.wilander
| summit_session_attendee_company1=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed1=

| summit_session_attendee_name2 = Michael Coates
| summit_session_attendee_email2 = Michael.Coates@owasp.org
| summit_session_attendee_username2 = MichaelCoates
| summit_session_attendee_company2=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed2=

| summit_session_attendee_name3 = Tony UcedaVelez
| summit_session_attendee_email3 = tonyuv@owasp.org
| summit_session_attendee_username3 = Tony UcedaVelez
| summit_session_attendee_company3= VerSprite
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed3=

| summit_session_attendee_name4 = Stefano Di Paola
| summit_session_attendee_email4 =
| summit_session_attendee_username4 =
| summit_session_attendee_company4=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed4=

| summit_session_attendee_name5 = Isaac Dawson
| summit_session_attendee_email5 =
| summit_session_attendee_username5 =
| summit_session_attendee_company5= Veracode
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed5=

| summit_session_attendee_name6 = Chris Eng
| summit_session_attendee_email6 = ceng@veracode.com
| summit_session_attendee_username6=
| summit_session_attendee_company6= Veracode
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed6=

| summit_session_attendee_name7 = Nishi Kumar
| summit_session_attendee_email7 = nishi.kumar@owasp.org
| summit_session_attendee_username7=
| summit_session_attendee_company7= FIS
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed7=

| summit_session_attendee_name8 = Elke Roth-Mandutz
| summit_session_attendee_email8 = elke.roth-mandutz@ohm-hochschule.de
| summit_session_attendee_username8=
| summit_session_attendee_company8=GSO-University of Applied Science
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed8=

| summit_session_attendee_name9 = Giorgio Fedon
| summit_session_attendee_email9 =
| summit_session_attendee_username9= gfedon
| summit_session_attendee_company9=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed9=

| summit_session_attendee_name10 = Paolo Perego
| summit_session_attendee_email10 = thesp0nge@owasp.org
| summit_session_attendee_username10= thesp0nge
| summit_session_attendee_company10= Armoredcode.com
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed10=

| summit_session_attendee_name11 = Eduardo Vela
| summit_session_attendee_email11 = evn@google.com
| summit_session_attendee_username11= EduardoVela
| summit_session_attendee_company11= Google
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed11=

| summit_session_attendee_name12 = Abraham Kang
| summit_session_attendee_email12 = abraham.kang@owasp.org
| summit_session_attendee_username12= Abraham Kang
| summit_session_attendee_company12 =
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed12=

| summit_session_attendee_name13 =
| summit_session_attendee_email13 =
| summit_session_attendee_username13 =
| summit_session_attendee_company13=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed13=

| summit_session_attendee_name14 =
| summit_session_attendee_email14 =
| summit_session_attendee_username14=
| summit_session_attendee_company14=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed14=

| summit_session_attendee_name15 =
| summit_session_attendee_email15 =
| summit_session_attendee_username15=
| summit_session_attendee_company15=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed15=

| summit_session_attendee_name16 =
| summit_session_attendee_email16 =
| summit_session_attendee_username16=
| summit_session_attendee_company16=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed16=

| summit_session_attendee_name17 =
| summit_session_attendee_email17 =
| summit_session_attendee_username17=
| summit_session_attendee_company17=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed17=

| summit_session_attendee_name18 =
| summit_session_attendee_email18 =
| summit_session_attendee_username18=
| summit_session_attendee_company18=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed18=

| summit_session_attendee_name19 =
| summit_session_attendee_email19 =
| summit_session_attendee_username19=
| summit_session_attendee_company19=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed19=

| summit_session_attendee_name20 =
| summit_session_attendee_email20 =
| summit_session_attendee_username20=
| summit_session_attendee_company20=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed20=

|-
| summit_track_logo = [[Image:T._browser_security.jpg]]
| summit_ws_logo = [[Image:WS._browser_security.jpg]]
| summit_session_name = HTML5 Security
| summit_session_url = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session002
| mailing_list = https://groups.google.com/group/owasp-summit-browsersec
|-

| short_working_session_description=
|-

| related_project_name1 = Browser Security Track - main page
| related_project_url_1 = http://www.owasp.org/index.php/Category:Summit_2011_Browser_Security_Track

| related_project_name2 = Google Group for the Browser Security Track
| related_project_url_2 = https://groups.google.com/group/owasp-summit-browsersec

| related_project_name3 =
| related_project_url_3 =

| related_project_name4 =
| related_project_url_4 =

| related_project_name5 =
| related_project_url_5 =

|-

| summit_session_objective_name1= '''Handle autofocus in a unified and secure way'''.<noinclude> Make sure SOP applies for autofocus usage in frame/iframe'd websites. Re-discuss necessity for (future) attributes like this.</noinclude>

| summit_session_objective_name2 = '''Discuss necessity and capability for the HTML5 form controls'''.<noinclude> Do we need a non-SOP formaction attribute and why? </noinclude>

| summit_session_objective_name3 = <noinclude>'''Goal I''':</noinclude> Initiate and create documentation and references for developers that address security issues. <noinclude>Html5sec.org is a start but impossible to continue or extend large scale without vendor help</noinclude>

| summit_session_objective_name4 = <noinclude>'''Goal II''':</noinclude>Discuss and heavily restrict SVG capabilities - especially when deployed in CSS backgrounds and <img> tags. <noinclude>Mainly Opera and Mozilla are addressed here.</noinclude>

| summit_session_objective_name5 = '''Long Term Goal(s)''': Provide a working and easy to use as well as vendor supported HTML5 compliant filter software such as HTMLPurifier. <noinclude>Browser vendors should participate in creating security software and filters - not undermine them as we could experience in the last decade.</noinclude>
|-

| working_session_date_and_time = Tuesday, 09 February Time: TBA

|-

| discussion_model = The working form will most probably be short presentations to frame the topic and then round table discussions. Depending on number of attendees we'll break into groups.

|-

| operational_resources = Projector, whiteboards, markers, Internet connectivity, power

|-

| working_session_additional_details = 

[[Image:Html5_mario_hackvertor.jpg‎‎]]

===Co-chair Mario Heiderich===
Mario Heiderich works as a researcher for the Ruhr-University in Bochum, Germany and currently focuses on HTML5, SVG security and security implications of the ES5 specification draft. Mario invoked the [http://html5sec.org/ HTML5 security cheat-sheet] and maintains the [http://php-ids.org/ PHPIDS filter rules]. In his spare time he delivers trainings and security consultancy for larger German and international companies. He is also one of the co-authors of [http://www.amazon.com/Web-Application-Obfuscation-WAFs-Evasion-Filters-alert/dp/1597496049 Web Application Obfuscation: '-/WAFs..Evasion..Filters//alert(/Obfuscation/)-'] – a book on how an attacker would bypass different types of security controls including IDS/IPS.

===Co-chair Gareth Heyes===
Gareth "Gaz" Heyes calls himself Chief Conspiracy theorist and is affiliated with Microsoft. He is the designer and developer behind [http://www.owasp.org/index.php/OWASP_JavaScript_Sandboxes#tab=JSReg JSReg] – a Javascript sandbox which converts code using regular expressions; [http://www.owasp.org/index.php/OWASP_JavaScript_Sandboxes#tab=HTMLReg HTMLReg] & [http://www.owasp.org/index.php/OWASP_JavaScript_Sandboxes#tab=CSSReg CSSReg] – converters of malicious HTML/CSS into a safe form of HTML. He is also one of the co-authors of [http://www.amazon.com/Web-Application-Obfuscation-WAFs-Evasion-Filters-alert/dp/1597496049 Web Application Obfuscation: '-/WAFs..Evasion..Filters//alert(/Obfuscation/)-'] – a book on how an attacker would bypass different types of security controls including IDS/IPS.

|-

|summit_session_deliverable_name1 = Browser Security Report
|summit_session_deliverable_url_1 =

|summit_session_deliverable_name2 = Browser Security Priority Report
|summit_session_deliverable_url_2 =

|summit_session_deliverable_name3 =
|summit_session_deliverable_url_3 =

|summit_session_deliverable_name4 =
|summit_session_deliverable_url_4 =

|summit_session_deliverable_name5 =
|summit_session_deliverable_url_5 =

|summit_session_deliverable_name6 =
|summit_session_deliverable_url_6 =

|summit_session_deliverable_name7 =
|summit_session_deliverable_url_7 =

|summit_session_deliverable_name8 =
|summit_session_deliverable_url_8 =

|-

| summit_session_leader_name1 = Mario Heiderich
| summit_session_leader_email1 =
| summit_session_leader_username1 =

| summit_session_leader_name2 = Gareth Heyes
| summit_session_leader_email2 = gazheyes@gmail.com
| summit_session_leader_username2 = Gareth Heyes

| summit_session_leader_name3 =
| summit_session_leader_email3 =
| summit_session_leader_username3 =

|-

| operational_leader_name1 = John Wilander
| operational_leader_email1 = john.wilander@owasp.org
| operational_leader_username1 = John.wilander

|-
| meeting_notes =
|-
| session_name_mask =  Session002
| session_home_page =  Summit_2011_Working_Sessions/Session002
}}
</includeonly>

Summit 2011 Working Sessions/Session090

2011-02-03T22:10:41Z

Abraham Kang:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Summit 2011 Working Sessions test tab</noinclude>
|-

| summit_session_attendee_name1 = Abraham Kang
| summit_session_attendee_email1 = abraham.kang@owasp.org
| summit_session_attendee_username1 =
| summit_session_attendee_company1=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed1=

| summit_session_attendee_name2 =
| summit_session_attendee_email2 =
| summit_session_attendee_username2 =
| summit_session_attendee_company2=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed2=

| summit_session_attendee_name3 =
| summit_session_attendee_email3 =
| summit_session_attendee_username3 =
| summit_session_attendee_company3=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed3=

| summit_session_attendee_name4 =
| summit_session_attendee_email4 =
| summit_session_attendee_username4 =
| summit_session_attendee_company4=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed4=

| summit_session_attendee_name5 =
| summit_session_attendee_email5 =
| summit_session_attendee_username5 =
| summit_session_attendee_company5=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed5=

| summit_session_attendee_name6 =
| summit_session_attendee_email6 =
| summit_session_attendee_username6 =
| summit_session_attendee_company6=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed6=

| summit_session_attendee_name7 =
| summit_session_attendee_email7 =
| summit_session_attendee_username7 =
| summit_session_attendee_company7=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed7=

| summit_session_attendee_name8 =
| summit_session_attendee_email8 =
| summit_session_attendee_username8 =
| summit_session_attendee_company8=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed8=

| summit_session_attendee_name9 =
| summit_session_attendee_email9 =
| summit_session_attendee_username9 =
| summit_session_attendee_company9=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed9=

| summit_session_attendee_name10 =
| summit_session_attendee_email10 =
| summit_session_attendee_username10 =
| summit_session_attendee_company10=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed10=

| summit_session_attendee_name11 =
| summit_session_attendee_email11 =
| summit_session_attendee_username11 =
| summit_session_attendee_company11=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed11=

| summit_session_attendee_name12 =
| summit_session_attendee_email12 =
| summit_session_attendee_username12 =
| summit_session_attendee_company12=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed12=

| summit_session_attendee_name13 =
| summit_session_attendee_email13 =
| summit_session_attendee_username13 =
| summit_session_attendee_company13=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed13=

| summit_session_attendee_name14 =
| summit_session_attendee_email14 =
| summit_session_attendee_username14 =
| summit_session_attendee_company14=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed14=

| summit_session_attendee_name15 =
| summit_session_attendee_email15 =
| summit_session_attendee_username15 =
| summit_session_attendee_company15=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed15=

| summit_session_attendee_name16 =
| summit_session_attendee_email16 =
| summit_session_attendee_username16 =
| summit_session_attendee_company16=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed16=

| summit_session_attendee_name17 =
| summit_session_attendee_email17 =
| summit_session_attendee_username17 =
| summit_session_attendee_company17=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed17=

| summit_session_attendee_name18 =
| summit_session_attendee_email18 =
| summit_session_attendee_username18 =
| summit_session_attendee_company18=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed18=

| summit_session_attendee_name19 =
| summit_session_attendee_email19 =
| summit_session_attendee_username19 =
| summit_session_attendee_company19=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed19=

| summit_session_attendee_name20 =
| summit_session_attendee_email20 =
| summit_session_attendee_username20 =
| summit_session_attendee_company20=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed20=
|-
| summit_track_logo =
| summit_ws_logo =
| summit_session_name = OWASP Licensing
| summit_session_url = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session090

|-

| short_working_session_description= Go over the OWASP Licenses related to OWASP documentation to discuss if the is a way to make the license more amiable to corporate users thereby spurring sales of corporate sponsorships.

|-

| related_project_name1 = OWASP Guide
| related_project_url_1 = http://www.owasp.org/index.php/OWASP_Guide_Project

| related_project_name2 = ESAPI
| related_project_url_2 = http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

| related_project_name3 = ASVS
| related_project_url_3 = http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

| related_project_name4 =
| related_project_url_4 =

| related_project_name5 =
| related_project_url_5 =

|-

| summit_session_objective_name1= Discuss the goals of the OWASP Licensing model for OWASP documents and informative materials.

| summit_session_objective_name2 = Understand better the corporate use cases for OWASP documentation and artifacts.

| summit_session_objective_name3 = Identify possible options for licensing changes to spur growth in corporate sponsorships.

| summit_session_objective_name4 =

| summit_session_objective_name5 =

|-

| working_session_date_and_time =

|-

| discussion_model = participants and attendees

|-

| operational_resources = Projector, whiteboards, markers, Internet connectivity, power

|-

| working_session_additional_details = Corporations face similar problems related to educating, creating, and implementing security policies and measures. Corporations require update-to-date security material to supplement their policies. OWASP has this information but licensing constraints may be limiting use of OWASP material in enterprises.
|-

|summit_session_deliverable_name1 = Licensing Requirements for OWASP documentation

|summit_session_deliverable_name2 = List is existing Licenses used by OWASP projects.

|summit_session_deliverable_name3 = Problem corporations face with adopting and utilizing OWASP materials and code

|summit_session_deliverable_name4 = Recommendations for changes in the OWASP License

|summit_session_deliverable_name5 =

|summit_session_deliverable_name6 =

|summit_session_deliverable_name7 =

|summit_session_deliverable_name8 =

|-

| summit_session_leader_name1 = Abraham Kang
| summit_session_leader_email1 = abraham.kang@owasp.org
| summit_session_leader_username1 =

| summit_session_leader_name2 =
| summit_session_leader_email2 =
| summit_session_leader_username2 =

| summit_session_leader_name3 =
| summit_session_leader_email3 =
| summit_session_leader_username3 =

|-

| operational_leader_name1 = Abraham Kang
| operational_leader_email1 = abraham.kang@owasp.org
| operational_leader_username1 = Abraham Kang

|-

| meeting_notes =

|-
| session_name_mask =  Session090
| session_home_page =  Summit_2011_Working_Sessions/Session090
}}

Summit 2011 Working Sessions/Session090

2011-02-03T22:04:42Z

Abraham Kang:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Summit 2011 Working Sessions test tab</noinclude>
|-

| summit_session_attendee_name1 = Abraham Kang
| summit_session_attendee_email1 = abraham.kang@owasp.org
| summit_session_attendee_username1 =
| summit_session_attendee_company1=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed1=

| summit_session_attendee_name2 =
| summit_session_attendee_email2 =
| summit_session_attendee_username2 =
| summit_session_attendee_company2=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed2=

| summit_session_attendee_name3 =
| summit_session_attendee_email3 =
| summit_session_attendee_username3 =
| summit_session_attendee_company3=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed3=

| summit_session_attendee_name4 =
| summit_session_attendee_email4 =
| summit_session_attendee_username4 =
| summit_session_attendee_company4=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed4=

| summit_session_attendee_name5 =
| summit_session_attendee_email5 =
| summit_session_attendee_username5 =
| summit_session_attendee_company5=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed5=

| summit_session_attendee_name6 =
| summit_session_attendee_email6 =
| summit_session_attendee_username6 =
| summit_session_attendee_company6=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed6=

| summit_session_attendee_name7 =
| summit_session_attendee_email7 =
| summit_session_attendee_username7 =
| summit_session_attendee_company7=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed7=

| summit_session_attendee_name8 =
| summit_session_attendee_email8 =
| summit_session_attendee_username8 =
| summit_session_attendee_company8=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed8=

| summit_session_attendee_name9 =
| summit_session_attendee_email9 =
| summit_session_attendee_username9 =
| summit_session_attendee_company9=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed9=

| summit_session_attendee_name10 =
| summit_session_attendee_email10 =
| summit_session_attendee_username10 =
| summit_session_attendee_company10=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed10=

| summit_session_attendee_name11 =
| summit_session_attendee_email11 =
| summit_session_attendee_username11 =
| summit_session_attendee_company11=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed11=

| summit_session_attendee_name12 =
| summit_session_attendee_email12 =
| summit_session_attendee_username12 =
| summit_session_attendee_company12=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed12=

| summit_session_attendee_name13 =
| summit_session_attendee_email13 =
| summit_session_attendee_username13 =
| summit_session_attendee_company13=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed13=

| summit_session_attendee_name14 =
| summit_session_attendee_email14 =
| summit_session_attendee_username14 =
| summit_session_attendee_company14=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed14=

| summit_session_attendee_name15 =
| summit_session_attendee_email15 =
| summit_session_attendee_username15 =
| summit_session_attendee_company15=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed15=

| summit_session_attendee_name16 =
| summit_session_attendee_email16 =
| summit_session_attendee_username16 =
| summit_session_attendee_company16=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed16=

| summit_session_attendee_name17 =
| summit_session_attendee_email17 =
| summit_session_attendee_username17 =
| summit_session_attendee_company17=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed17=

| summit_session_attendee_name18 =
| summit_session_attendee_email18 =
| summit_session_attendee_username18 =
| summit_session_attendee_company18=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed18=

| summit_session_attendee_name19 =
| summit_session_attendee_email19 =
| summit_session_attendee_username19 =
| summit_session_attendee_company19=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed19=

| summit_session_attendee_name20 =
| summit_session_attendee_email20 =
| summit_session_attendee_username20 =
| summit_session_attendee_company20=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed20=
|-
| summit_track_logo =
| summit_ws_logo =
| summit_session_name = OWASP Licensing
| summit_session_url = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session090

|-

| short_working_session_description= Go over the OWASP Licenses related to OWASP documentation to discuss if the is a way to make the license more amiable to corporate users thereby spurring sales of corporate sponsorships.

|-

| related_project_name1 =
| related_project_url_1 =

| related_project_name2 =
| related_project_url_2 =

| related_project_name3 =
| related_project_url_3 =

| related_project_name4 =
| related_project_url_4 =

| related_project_name5 =
| related_project_url_5 =

|-

| summit_session_objective_name1= Discuss the goals of the OWASP Licensing model for OWASP documents and informative materials.

| summit_session_objective_name2 = Understand better the corporate use cases for OWASP documentation and artifacts.

| summit_session_objective_name3 = Identify possible options for licensing changes to spur growth in corporate sponsorships.

| summit_session_objective_name4 =

| summit_session_objective_name5 =

|-

| working_session_date_and_time =

|-

| discussion_model = participants and attendees

|-

| operational_resources = Projector, whiteboards, markers, Internet connectivity, power

|-

| working_session_additional_details = Corporations face similar problems related to educating, creating, and implementing security policies and measures. Corporations require update-to-date security material to supplement their policies. OWASP has this information but licensing constraints may be limiting use of OWASP material in enterprises.
|-

|summit_session_deliverable_name1 = Licensing Requirements for OWASP documentation

|summit_session_deliverable_name2 = List is existing Licenses used by OWASP projects.

|summit_session_deliverable_name3 = Problem corporations face with adopting and utilizing OWASP materials and code

|summit_session_deliverable_name4 = Recommendations for changes in the OWASP License

|summit_session_deliverable_name5 =

|summit_session_deliverable_name6 =

|summit_session_deliverable_name7 =

|summit_session_deliverable_name8 =

|-

| summit_session_leader_name1 = Abraham Kang
| summit_session_leader_email1 = abraham.kang@owasp.org
| summit_session_leader_username1 =

| summit_session_leader_name2 =
| summit_session_leader_email2 =
| summit_session_leader_username2 =

| summit_session_leader_name3 =
| summit_session_leader_email3 =
| summit_session_leader_username3 =

|-

| operational_leader_name1 = Abraham Kang
| operational_leader_email1 = abraham.kang@owasp.org
| operational_leader_username1 = Abraham Kang

|-

| meeting_notes =

|-
| session_name_mask =  Session090
| session_home_page =  Summit_2011_Working_Sessions/Session090
}}