W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2013

RE: Agenda for January 29 Teleconference

From: Fred Andrews <fredandw@live.com>
Date: Wed, 30 Jan 2013 03:28:18 +0000
Message-ID: <BLU002-W1406058F5D6B3249267421DAA1E0@phx.gbl>
To: Daniel Veditz <dveditz@mozilla.com>
CC: Web Application Security Working Group <public-webappsec@w3.org>
Dear Dan,

CSP allows both the author's policy and an injected policy to leak all the
resources loaded from a document to anywhere on the web, even with
scripts disabled.  This is not something the user would expect,
particularly with scripts disabled.  I am glad that Mozilla limit the
destinations to which a report can be sent, but it is not really enough.

It may well cause less leaks if the reports were restricted to
only be returned to the server that serves each violating resource.

For example, consider server A sending a content page with
resources that are loaded from third party servers B,C,D.  Using
CSP, server A can request reports of the loading of resources from
servers B,C,D to be reported back to server A or an agent for
server A anywhere on the web.  This information could well be used
to discriminate against the user in a way that would not have been
possible without CSP reporting, and might leak state the user wishes
to secure.

I accept that with scripting enabled, or perhaps even using CSS,
it is probably possible to leak this state anyway.  However if the user
makes an attempt to secure their state, by disabling scripting, then
it does not seem to me to be acceptable that CSP allow such state
to be leaked.

CSP is really a reporting regime that is designed to outsource security
to the cloud.  As much as interest groups try to shoehorn security
to the cloud the foot just does not fit.

cheers
Fred 

> Date: Tue, 29 Jan 2013 15:22:40 -0800
> From: dveditz@mozilla.com
> To: neilm@twitter.com
> CC: neil@matatall.com; imelven@mozilla.com; public-webappsec@w3.org; ekr@rtfm.com
> Subject: Re: Agenda for January 29 Teleconference
> 
> On 1/29/2013 2:55 PM, Neil Matatall wrote:
> >> If an attacker can inject a policy what data can be sent where?
> >
> > Is this a threat that we should keep in mind? If you can inject a
> > policy, I would think you likely have bigger issues. And if you're
> > over http://, you have no guarantees whatsoever.
> 
> It's not a threat that keeps me up at night but I don't want a security 
> feature like CSP to be used to make a bad situation (MITM) worse.
> 
> So yeah, your site is over http:// and can't be trusted, but it's just a 
> blog and you don't care. However, you use a 3rd party comment system 
> that uses secure requests for SSO. You don't use CSP yourself (see 
> "don't care" above). Can an injected policy leak information about the 
> SSO credentials or details?
> 
> This is not idle speculation, an earlier version of Firefox put enough 
> details in the CSP reports that an evil site (or an injected header) 
> could compromise a visitor's OAuth 2.0 credentials.
> 
> Another scenario: your site is securely sent over TLS, but it has an 
> HTML injection flaw (i.e. "XSS"). Extremely common, that's why we 
> invented CSP. Can an injected <meta> CSP policy leak sensitive 
> information to a remote attacker? Currently we protect against this 
> attack by not allowing <meta> policies to specify a report URL, and we 
> don't honor <meta> policies if there's already a policy specified in 
> HTTP headers. There are people who chafe at both of those restrictions 
> so we do need to worry about this scenario at least a little.
> 
> -Dan Veditz
> 
 		 	   		  
Received on Wednesday, 30 January 2013 03:28:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 03:28:46 GMT