- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Fri, 30 Mar 2012 09:02:56 -0700
- To: Adam Barth <w3c@adambarth.com>
- CC: "Hill, Brad" <bhill@paypal-inc.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On 3/27/12 3:06 PM, Adam Barth wrote: > Let's number the use cases for easy reference (from Brad's message): > > 1) Support static documents loaded by file: , data: or other non-HTTP methods Not a common case. A more compelling "web" use-case is for situations where authors are given space for content but no control over the headers served (example: blog hosting services, the old Geocities). At Mozilla we were sad to give this case up when we decided policy-uri was safer than a <meta> tag. > A) Support only use cases (1) and (2) and require user agents to > ignore <meta http-equiv> element outside the head. Doesn't the HTML5 spec already require this? Although case 3) is a bad idea you can still do quite a bit of processing in the <head> if you left the <meta> CSP to the last. > B) Support use case (3) via another mechanism. For example, we can > add a DOM (like document.contentSecurityPolicy) that can be used to > add a policy at run time. This takes us even further down the road from a declarative security policy to a dynamic one. > C) Suppose use cases (1), (2), and (3) using a non-http-equiv <meta> element. http-equiv or not, why does case (3) require such late application of the security policy? Putting a security mechanism intended to combat content-injection inside content presumably vulnerable to injection seems sketchy to start. The <head> is dangerous enough but the actual <body> is where the bulk of the injection attacks occur. The whole argument against policy-uri came down to "people might unknowingly do something slow" but in-content policy is a foot-gun where people might unknowingly do something stupidly insecure. It also gives attackers a new tool to use against old content that isn't likely to be sanitizing their content against this feature, something similar to the script-disabling attacks against the early version of the IE XSS filter. It's especially sad when a security feature is used to make a page less secure. -Dan Veditz
Received on Friday, 30 March 2012 16:03:41 UTC