W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2012

RE: CSP 1.0: Are UAs permitted to implement reporting as opt-in?

From: Erlend Oftedal <eoftedal@gmail.com>
Date: Tue, 16 Oct 2012 22:04:32 -0700
Message-ID: <-4661244533470598113@unknownmsgid>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 17 October 2012 05:05:01 GMT