RE: CSP - 'unsafe-inline' for 'style-src' directive, actually unsafe?

Forgive me if this was already discussed; I am new to the group and did not find this in the archives.

Following the uncertainty sec_ext@fb.com brings up, I have a suggestion on clarification we could provide. To help me explain my thought process behind the clarification itself, I'd like to borrow a CSS snippet from on OWASP: 

background-url : 'javascript:alert(1)'
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values

In this situation:
Document uses CSP with 'style-src' = 'unsafe-inline' and 'script-src' = 'none'.
Document contains <element style="background-url : 'javascript:alert(1)'; "/>

My interpretation of the CSP is that the useragent applies the attribute due to 'style-src', but the javascript url fails due to 'script-src'.

Another situation that I interpret the CSP where the useragent applies the attribute due to 'style-src', but the javascript url fails due to 'script-src':
Document uses CSP with 'style-src' = 'self' and 'script-src' = 'self'
Referenced CSS document from the same host contains "inlineScriptClass { background-url : 'javascript:alert(1)'; }"
Document contains <element class="inlineScriptClass"/>

Mirroring this, I would interpret the CSP where the useragent does not execute the javascript url in these situations either:
Document uses CSP with 'script-src' = 'self' and 'style-src' = 'self'
Referenced JS document from same host contains:
	exampleElementHandle.setAttribute('style', "background-url : 'javascript:alert(1)';");' //Expected to fail because 'style-src' setting doesn't include  'unsafe-inline'? 
	exampleElementHandle.style.backgroundImage = "url('javascript:alert(1)')"; //Expected to fail because 'script-src' setting doesn't include 'unsafe-inline'? 



If we decide that these interpretations are correct, perhaps we could include clarifications along the line of: 
	Attributes assigned dynamically are subject to the URI restrictions relevant for those attributes, where "dynamically" includes attributes assigned from CSS (unsafe-inline or otherwise) and script (unsafe-inline or otherwise). 

Cory Carson



-----Original Message-----
From: Adam Barth [mailto:w3c@adambarth.com] 
Sent: Monday, March 19, 2012 3:26 PM
To: sec_ext
Cc: public-webappsec@w3.org
Subject: Re: CSP - 'unsafe-inline' for 'style-src' directive, actually unsafe?

On Mon, Mar 19, 2012 at 2:48 PM, sec_ext <sec_ext@fb.com> wrote:
> In the CSP specification, it states "authors should not include 
> 'unsafe-inline' in their CSP policies if they wish to protect 
> themselves against XSS."
>
> It is not entirely clear how allowing inline CSS ('style-src
> 'unsafe-inline';) can lead to XSS if you are blocking inline and 
> external JS (script-src none;)
>
> Will 'script-src none' not block JS attempts in CSS?

CSP forbids any JavaScript from being included in CSS, regardless of what policy you use.

> Does it depend on how the spec is implemented (per browser basis)?

As far as I know, all modern browsers have already removed the ability to run script from CSS.

> Or, does the spec need to be
> re-worded to mention that the aforementioned sentence is only 
> applicable to the script-src directive?

There is a security risk to letting folks inject CSS into your document, albeit a smaller risk than letting them inject script.
There was a nice talk at Black Hat a couple years ago that talked about the kinds of things an attacker can do by injecting only CSS.
For example, using attribute selectors and background images, the attacker might be able to learn the value of form fields, including password fields.

It's mostly a question of your risk tolerance.  There's a large security benefit to locking down script-src and object-src.  There's a smaller security benefit to locking down style-src.  We should update the spec to have some more nuanced text on this topic.

Adam

Received on Tuesday, 20 March 2012 08:12:41 UTC