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 Monday, 29 December 2014 15:59:30 UTC