AW: [CSP] different perspective on Report-Only

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<mailto: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<mailto: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<mailto: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<tel:%2B49%20%28228%29%207636%20-%20204>
> F +49 (228) 7636 - 100<tel:%2B49%20%28228%29%207636%20-%20100>
> M +49 (172) 81 40 733<tel:%2B49%20%28172%29%2081%2040%20733>
>
> Sven.Ludwig@senacor.com<mailto:Sven.Ludwig@senacor.com>
> www.senacor.com<http://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.