Re: [CSP] different perspective on Report-Only

I think that's implied by the current spec.  The best solution would be to
contribute test cases to verify conformance on this.

I've added placeholders for these cases to the test assertions wiki page:
https://www.w3.org/Security/wiki/Test_Assertions_For_Content_Security_Policy

On Tue Dec 30 2014 at 7:08:27 AM Ludwig, Sven <Sven.Ludwig@senacor.com>
wrote:

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