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