Skip to content

Commit

Permalink
feat(xss-context): improve comments and add tutorial section
Browse files Browse the repository at this point in the history
  • Loading branch information
@lirantal
lirantal committed Sep 10, 2018
1 parent 86d2c6a commit 5b88848
Show file tree
Hide file tree
Showing 3 changed files with 75 additions and 20 deletions.
2 changes: 1 addition & 1 deletion app/routes/profile.js
View file
Expand Up @@ -23,7 +23,7 @@ function ProfileHandler(db) {
doc.firstNameSafeString = ESAPI.encoder().encodeForHTML(doc.firstName)
// fix it by replacing the above with another template variable that is used for
// the context of a URL in a link header
// doc.firstNameSafeString = ESAPI.encoder().encodeForURL(urlInput)
// doc.doc.firstNameSafeURLString = ESAPI.encoder().encodeForURL(urlInput)

return res.render("profile", doc);
});
Expand Down
2 changes: 2 additions & 0 deletions app/views/profile.html
View file
Expand Up @@ -68,6 +68,8 @@ <h3 class="panel-title">Edit Profile</h3>
<input type="hidden" name="_csrf" value="{{csrftoken}}" />
<button type="submit" class="btn btn-default" name="submit">Submit</button>

<!-- @FIXME use a properly escaped variable that matches the URL context, for example
refer to a firstNameSafeURLString field on the doc object set by the controller for this template -->
<a href="{{firstNameSafeString}}">Google search this profile by name</a>
</form>
</div>
Expand Down
91 changes: 72 additions & 19 deletions app/views/tutorial/a3.html
View file
Expand Up @@ -18,7 +18,9 @@
<h3 class="panel-title">Description</h3>
</div>
<div class="panel-body">
XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victims' browser, which can access any cookies, session tokens, or other sensitive information retained by the browser, or redirect user to malicious sites.
XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping.
XSS allows attackers to execute scripts in the victims' browser, which can access any cookies, session tokens,
or other sensitive information retained by the browser, or redirect user to malicious sites.
</div>
</div>

Expand All @@ -32,11 +34,14 @@ <h3 class="panel-title">Attack Mechanics</h3>
</p>

<ol>
<li>Reflected XSS: The malicious data is echoed back by the server in an immediate response to an HTTP request from the victim.</li>
<li>Stored XSS: The malicious data is stored on the server or on browser (using HTML5 local storage, for example), and later gets embedded in HTML page provided to the victim.</li>
<li>Reflected XSS: The malicious data is echoed back by the server in an immediate response to an HTTP
request from the victim.</li>
<li>Stored XSS: The malicious data is stored on the server or on browser (using HTML5 local storage,
for example), and later gets embedded in HTML page provided to the victim.</li>
</ol>

<p>Each of reflected and stored XSS can occur on the server or on the client (which is also known as DOM based XSS), depending on when the malicious data gets injected in HTML markup.</p>
<p>Each of reflected and stored XSS can occur on the server or on the client (which is also known as DOM
based XSS), depending on when the malicious data gets injected in HTML markup.</p>
</div>
</div>

Expand All @@ -47,10 +52,13 @@ <h3 class="panel-title">How Do I Prevent It?</h3>
<div class="panel-body">
<ol>
<li>
<p><b> Input validation and sanitization:</b> Input validation and data sanitization are the first line of defense against untrusted data. Apply white list validation wherever possible.</p>
<p><b> Input validation and sanitization:</b> Input validation and data sanitization are the first
line of defense against untrusted data. Apply white list validation wherever possible.</p>
</li>
<li>
<p> <b> Output encoding for correct context: </b>When a browser is rendering HTML and any other associated content like CSS, javascript etc., it follows different rendering rules for each context. Hence <i>Context-sensitive output encoding</i> is absolutely critical for mitigating risk of XSS.</p>
<p> <b> Output encoding for correct context: </b>When a browser is rendering HTML and any other associated
content like CSS, javascript etc., it follows different rendering rules for each context. Hence
<i>Context-sensitive output encoding</i> is absolutely critical for mitigating risk of XSS.</p>
Here are the details about applying correct encoding in each context:
<table class="table table-bordered table-hover">
<tbody>
Expand All @@ -75,15 +83,17 @@ <h3 class="panel-title">How Do I Prevent It?</h3>
<td>HTML Attribute Encoding</td>
<td>&lt;input type="text" name="fname" value="
<span style="color:red;">UNTRUSTED DATA</span>"&gt;</td>
<td>Except for alphanumeric characters, escape all characters with the HTML Entity &amp;#xHH; format, including spaces. (HH = Hex Value)
<td>Except for alphanumeric characters, escape all characters with the HTML Entity &amp;#xHH;
format, including spaces. (HH = Hex Value)
<br/>
</td>
</tr>
<tr>
<td>URI Encoding</td>
<td>&lt;a href="/site/search?value=
<span style="color:red;">UNTRUSTED DATA</span>"&gt;clickme&lt;/a&gt;</td>
<td>Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the HTML Entity &amp;#xHH; format, including spaces. (HH = Hex Value)
<td>Except for alphanumeric characters, escape all characters with ASCII values less
than 256 with the HTML Entity &amp;#xHH; format, including spaces. (HH = Hex Value)
<br/>
</td>
</tr>
Expand All @@ -94,30 +104,41 @@ <h3 class="panel-title">How Do I Prevent It?</h3>
<br>&lt;script&gt;someFunction('
<span style="color:red;">UNTRUSTED DATA</span>');&lt;/script&gt;
</td>
<td>Ensure JavaScript variables are quoted. Except for alphanumeric characters, escape all characters with ASCII values less than 256 with \uXXXX unicode escaping format (X = Integer), or in xHH (HH = HEX Value) encoding format.
<td>Ensure JavaScript variables are quoted. Except for alphanumeric characters, escape
all characters with ASCII values less than 256 with \uXXXX unicode escaping format
(X = Integer), or in xHH (HH = HEX Value) encoding format.
</td>
</tr>
<tr>
<td>CSS Encoding</td>
<td>&lt;div style="width:
<span style="color:red;">UNTRUSTED DATA</span>;"&gt;Selection&lt;/div&gt;</td>
<td>Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the \HH (HH= Hex Value) escaping format.
<td>Except for alphanumeric characters, escape all characters with ASCII values less
than 256 with the \HH (HH= Hex Value) escaping format.
</td>
</tr>
</tbody>
</table>
</li>
<li>
<p><b>HTTPOnly cookie flag:</b> Preventing all XSS flaws in an application is hard. To help mitigate the impact of an XSS flaw on your site, set the HTTPOnly flag on session cookie and any custom cookies that are not required to be accessed by JavaScript.
<p><b>HTTPOnly cookie flag:</b> Preventing all XSS flaws in an application is hard. To help mitigate
the impact of an XSS flaw on your site, set the HTTPOnly flag on session cookie and any custom
cookies that are not required to be accessed by JavaScript.
</p>
</li>
<li>
<p><b>Implement Content Security Policy (CSP):</b> CSP is a browser side mechanism which allows creating whitelists for client side resources used by the web application, e.g. JavaScript, CSS, images, etc. CSP via special HTTP header instructs the browser to only execute or render resources from those sources. For example, the CSP header below allows content only from example site's own domain (mydomain.com) and all its sub domains.
<p><b>Implement Content Security Policy (CSP):</b> CSP is a browser side mechanism which allows creating
whitelists for client side resources used by the web application, e.g. JavaScript, CSS, images,
etc. CSP via special HTTP header instructs the browser to only execute or render resources from
those sources. For example, the CSP header below allows content only from example site's own
domain (mydomain.com) and all its sub domains.
<pre>Content-Security-Policy: default-src 'self' *.mydomain.com</pre>

</p>
</li>
<li> <b>Apply encoding on both client and server side: </b> It is essential to apply encoding on both client and server side to mitigate DOM based XSS attack, in which untrusted data never leaves the browser.
<li> <b>Apply encoding on both client and server side: </b> It is essential to apply encoding on both
client and server side to mitigate DOM based XSS attack, in which untrusted data never leaves the
browser.
</ol>
<p>Source: XSS Prevention Cheat Sheet[1]
</p>
Expand All @@ -129,7 +150,9 @@ <h3 class="panel-title">Source Code Example</h3>
</div>
<div class="panel-body">
<p>
The demo web application is vulnerable to stored XSS attack on profiles form. On form submit, the first and last name field values are submitted to the server, and without any validation get saved in database. The values are then sent back to the browser without proper escaping to be shown at the top right menu.
The demo web application is vulnerable to stored XSS attack on profiles form. On form submit, the first and last name field
values are submitted to the server, and without any validation get saved in database. The values are
then sent back to the browser without proper escaping to be shown at the top right menu.
</p>
<iframe width="560" height="315" src="//www.youtube.com/embed/KvZ5jdg083M?rel=0" frameborder="0" allowfullscreen></iframe>

Expand Down Expand Up @@ -159,27 +182,57 @@ <h3 class="panel-title">Source Code Example</h3>
</pre>
</li>
</ol>
There were no additional contexts that needed encoding on the demo page; otherwise, it is necessary to encode for correct context depending on where data get placed at.
There were no additional contexts that needed encoding on the demo page; otherwise, it is necessary to encode for correct
context depending on where data get placed at.

</div>
</div>

<div class="panel panel-info">
<div class="panel-heading">
<h3 class="panel-title">Output Encoding Context</h3>
</div>
<div class="panel-body">
<p>
An important observation when handling output encoding to prevent XSS is the notion of context.
</p>

<p>
When output encoding is performed, it must match the context in which it is being injected to. For example, if a user input
is being injected to an HTML element then it will require different encoding semantics to escape malicious
input than if it were injected to say an HTML attribute or a JavaScript context altogether (such as in
a script tag).
</p>

<p>
An example for how to take advantage and exploit this mis-understanding exists on the profile page. See code references in
<code>profile.js</code> and <code>profile.html</code>
</p>
</div>
</div>

<div class="panel panel-info">
<div class="panel-heading">
<h3 class="panel-title">Further Reading</h3>
</div>
<div class="panel-body">
<ol>
<li>
<a href="https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet">XSS Prevention Cheat Sheet</a>
<a href="https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet">XSS Prevention
Cheat Sheet</a>
</li>
<li>
<a href="https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting#Server_XS">Types of Cross-Site Scripting</a>
<a href="https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting#Server_XS">Types of Cross-Site
Scripting
</a>
</li>
<li>
<a href="https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#STYLE_sheet ">XSS Filter Evasion Cheat Sheet</a>
<a href="https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#STYLE_sheet ">XSS Filter
Evasion Cheat Sheet</a>
</li>
<li>
<a href="https://www.owasp.org/images/c/c5/Unraveling_some_Mysteries_around_DOM-based_XSS.pdf ">Unraveling some of the Mysteries around DOM-based XSS</a>
<a href="https://www.owasp.org/images/c/c5/Unraveling_some_Mysteries_around_DOM-based_XSS.pdf ">Unraveling
some of the Mysteries around DOM-based XSS</a>
</li>
</ol>
</div>
Expand Down

0 comments on commit 5b88848

Please sign in to comment.