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.
>
>
>