- From: Erlend Oftedal <eoftedal@gmail.com>
- Date: Tue, 16 Oct 2012 22:04:32 -0700
- To: Dan Veditz <dveditz@mozilla.com>, Fred Andrews <fredandw@live.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Correct. CSP is a part of a defense-in-depth strategy for web apps. Because of the complex nature of some XSS bugs, and lots of malware is linked in through injected scripts, iframes, flash movies etc. it can certainly play a role. It's like DEP/Canaries for the web. These mechanisms don't stop buffer overflows from occuring in code, but do make them harder to exploit. Best regards Erlend From: Dan Veditz Sent: 17.10.2012 03:35 To: Fred Andrews Cc: public-webappsec@w3.org Subject: Re: CSP 1.0: Are UAs permitted to implement reporting as opt-in? On 10/16/12 3:36 PM, Fred Andrews wrote: > CSP 1.0 required a UA to submit a report when requested by the server > and thus that a server could depend on this. Servers can't rely on anything. The client might not support CSP at all. The client might partially support a non-standard predecessor of the approved CSP spec (e.g. Firefox 4). The user might have turned off CSP support. CSP cannot be relied on to turn an insecure site into a secure site; the site author still must strive to make their site secure. CSP provides a syntax by which a server can specify constraints it expects its content to follow so that a UA can provide some backup defense in depth in the face of bugs or attacks. But servers absolutely cannot rely on the client doing this. In the most trivial of examples: even if the client fully enforces the spec with no user modifications, if the content is not served over SSL the CSP policy itself might be stripped from the content before it reaches the client. The server should not rely on reports. -Dan Veditz
Received on Wednesday, 17 October 2012 05:05:00 UTC