AW: [CSP] different perspective on Report-Only

> Does that distinction address your concerns?

Yes.

> If so, is there something specific we could add to the spec to make that distinction more clear?

Yes, in http://w3c.github.io/webappsec/specs/content-security-policy/#content-security-policy-report-only-header-field right after the sentence “The Content-Security-Policy-Report-Only header field lets servers experiment with policies by monitoring (rather than enforcing) a policy.” it could be added that:

“Any policies delivered in Content-Security-Policy headers are enforced and neither their declarations nor their enforcement are affected in any way by Content-Security-Policy-Report-Only headers. In other words, enforcement and monitoring-only are treated as separate concerns.”

Kind Regards,
Sven


Von: Mike West [mailto:mkwst@google.com] 
Gesendet: Dienstag, 30. Dezember 2014 09:41
An: Ludwig, Sven
Cc: public-webappsec@w3.org
Betreff: Re: [CSP] different perspective on Report-Only

The spec talks about `Content-Security-Policy` headers in terms of "enforcement", and `Content-Security-Policy-Report-Only` headers in terms of "monitoring". Those are two separate categories; changes to a page's enforcement behavior does not effect the policies it monitors, and vice-versa.

Does that distinction address your concerns? If so, is there something specific we could add to the spec to make that distinction more clear?


--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Mon, Dec 29, 2014 at 11:29 PM, Ludwig, Sven <Sven.Ludwig@senacor.com> wrote:
But, to stress my main point:
 
The spec must make it clear to users and browser implementors that Content-Security-Policy headers have always precedence over Content-Security-Policy-Report-Only headers,
 
so that an attacker cannot deactivate a policy that is in place by adding Content-Security-Policy-Report-Only headers.
 
Kind Regards,
Sven
 
 
Von: Mike West [mailto:mkwst@google.com] 
Gesendet: Montag, 29. Dezember 2014 16:59
An: Martin Thomson
Cc: Ludwig, Sven; public-webappsec@w3.org
Betreff: Re: [CSP] different perspective on Report-Only
 
We currently intentionally allow multiple reporting endpoints (even in a single directive), and I believe folks are using at least the ability to specify one "prod" endpoint for the `Content-Security-Policy` header, and one "testing" endpoint for the `Content-Security-Policy-Report-Only` header. I've had conversations with folks interested in testing multiple levels of report-only (e.g. "Here's what we think we can do next, and here's what we'd like to be doing."), but I don't know if anyone has put that into practice. We could certainly add metrics to Chrome and Firefox to see how widespread that is. I suspect not very. :)
 
Given that report-only functions only when delivered as a response header, it seems that an attacker capable of injecting headers could do significantly better for herself than CSP-RO, especially given the limitations of cross-origin reporting (no paths, no cookies, etc).
 
-mike


--
Mike West <mkwst@google.com>, @mikewest
 
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
 
On Sun, Dec 28, 2014 at 5:42 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
Perhaps the right interpretation is "report to no-one but X".  That
would cause two conflicting directives to turn into "don't report to
anyone".

(If you think of each directive as narrowing scope, then logically the
absence of a -report-only directive is to report to everyone, but I
think we can handle that.)

On 26 December 2014 at 17:40, Ludwig, Sven <Sven.Ludwig@senacor.com> wrote:
> Hi,
>
>
>
> following the excellent talk https://www.youtube.com/watch?v=pocsv39pNXA by
> Adam Barth, CSP supports setting multiple policies (i.e. multiple
> Content-Security-Policy headers) in a response, which then all must be
> fulfilled. One reason for this principle as mentioned in the talk is that an
> attacker might somehow be able to add his own CSP header to the response,
> however without replacing existing headers coming from the server. In this
> case the attack does not open up security, because additional
> Content-Security-Policy headers can only introduce more restrictions.
>
>
>
> Having said that, the header Content-Security-Policy-Report-Only could be
> considered by an attacker to add, to open up security.
>
>
>
> Right now I am not sure if this could be an issue.
>
>
>
> If any Content-Security-Policy headers have precedence over any
> Content-Security-Policy-Report-Only headers, the attacker would still not be
> able to open up security in the above mentioned way. Actually, I expect it
> to work like that. This should be mentioned in the section
> http://www.w3.org/TR/CSP2/#content-security-policy-report-only

>
>
>
> Kind Regards,
>
> Sven
>
>
>
>
>
> Sven Ludwig
> ______________________________
> Senacor Technologies AG
> Joseph-Schumpeter-Allee 1
> 53227 Bonn
>
> T +49 (228) 7636 - 204
> F +49 (228) 7636 - 100
> M +49 (172) 81 40 733
>
> Sven.Ludwig@senacor.com
> www.senacor.com
>
>
> Senacor Technologies Aktiengesellschaft - Sitz: Schwaig b. Nbg. -
> Amtsgericht Nbg.- Reg.-Nr.: HRB 23098
> Vorstand: Matthias Tomann, Marcus Purzer - Aufsichtsratsvorsitzender:
> Mathias J. Lindermeir
>
> Diese E-Mail inklusive Anlagen enthält vertrauliche und/oder rechtlich
> geschützte Informationen. Wenn Sie
> nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten,
> informieren Sie bitte den  Absender
> und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte
> Weitergabe dieser  E-Mail ist
> nicht gestattet.
>
> This e-mail including any attachments may contain confidential and/or
> privileged information. If you are
> not the intended recipient (or have received this e-mail in error) please
> notify the sender immediately and
> destroy this e-mail. Any unauthorized copying, disclosure or distribution of
> the materials in this e-mail is
> strictly forbidden.

Received on Tuesday, 30 December 2014 15:06:25 UTC