- From: Mike West <mkwst@google.com>
- Date: Mon, 29 Dec 2014 16:58:37 +0100
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: "Ludwig, Sven" <Sven.Ludwig@senacor.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAKXHy=cDbqVXkjgszDCeCJD2nuTHMPOVZCDxu15w-1rEVfEn3Q@mail.gmail.com>
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