On 3/12/10 3:18 PM, Devdatta wrote: > (below is my understanding of the decision) > > CSP tries to be robust against an attacker who is able to inject HTTP > Headers. Thus the choice of intersecting multiple policies - thus an > attacker can not reduce the security that a correct policy aims to > provide.
This is not completely true. While adding a CSP header can't loosen a policy, this is specified as such for legit uses, not for attack scenarios. CSP is intended to protect from content flaws, not a mid-stream network attacker. Attackers who can inject HTTP headers have quite a bit more power than a simple XSS vulnerability (and these attacks are probably less common). Furthermore, it's likely that an attacker who can inject a HTTP header can also change existing ones (or delete them). > In report mode, there is a concern that CSP might leak > sensitive data (cookies/capabilities). If both report and policy is > allowed, then an attacker could reduce the security of an application > by adding a (report-only) header which leaks information, which > doesn't sit well with how the rest of CSP aims to work. This is actually stopped by restrictions on where reports can be sent. An attacker who injects a "report-uri" can't learn anything about the victims unless he controls the server where the reports are sent -- which must be on the same public suffix and base host. Having said all that, I can see the use-case of having both headers, but it does make the implementation quite a bit more complex; i.e., we potentially have to keep two policies in parallel, and subject the content to both policies. As far as I can remember, we ignore the report-only header to make things easier on whoever implements the feature. Maybe we should start talking about supporting both at the same time, and the semantics for doing so? -Sid _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
