W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2014

RE: CSP reports on eval() and inline

From: Hill, Brad <bhill@paypal.com>
Date: Thu, 4 Sep 2014 16:11:01 +0000
To: Mike West <mkwst@google.com>, Pawel Krawczyk <pawel.krawczyk@hush.com>, Dan Veditz <dveditz@mozilla.com>
CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E5EB19F6E@DEN-EXDDA-S12.corp.ebay.com>
We don’t say anything normative about that right now, but putting non-uris in that field might make folks unhappy, yes.

Don’t the source-file, line-number and column-number fields in the example full report below give what is needed to make the inline/eval distinction?  It’s not something you can easily parse out with a script, perhaps, but seems like it would make short work of a manual investigation, at least.

From: Mike West [mailto:mkwst@google.com]
Sent: Thursday, September 04, 2014 8:25 AM
To: Pawel Krawczyk; Dan Veditz; Hill, Brad
Cc: public-webappsec@w3.org
Subject: Re: CSP reports on eval() and inline


This seems pretty reasonable. My only concern is that existing parsers wouldn't appreciate invalid URLs in the 'blocked-uri' field.

This might be small enough to sneak into CSP2 at the last minute. WDYT Dan, Brad?

-mike
On Sep 4, 2014 2:12 PM, "Pawel Krawczyk" <pawel.krawczyk@hush.com<mailto:pawel.krawczyk@hush.com>> wrote:
A small issue we have just discussed at GitHub https://github.com/w3c/webappsec/issues/52:



CSP violation reports sent when browser blocks eval() and inline script are identical in their contents, which makes it difficult to determine what really caused them.

In both cases the fields violated-directive will be set to script-scr and blocked-uri will be empty. So when I'm trying to analyse received reports I can't really say what I should allow - unsafe-eval or unsafe-inline. Sample fields extracted from such reports:

"blocked-uri":""

"violated-directive":"script-src 'none’"
The solution might be either sending some kind of meaningful blocked-url value - such as self-eval or self-inline, or adding an additional field to the report, such as blocked-feature set to eval or inline respectively.
Sample full report:

1.     {"csp-report":{"document-uri":"http://webcookies.info/","referrer":"<http://webcookies.info/%22,%22referrer%22:%22>","violated-directive":"script-src 'none'","original-policy":"base-uri http://webcookies.info<http://webcookies.info/>; connect-src 'none'; font-src 'none'; form-action 'none'; frame-ancestors 'none'; child-src 'none'; default-src 'none'; frame-src 'none'; img-src 'none'; media-src 'none'; object-src 'none'; script-src 'none'; style-src 'none'; report-uri http://new.cspbuilder.info:8080/report/9018643792216450862","blocked-uri":"","source-file":"http://pagead2.googlesyndication.com","line-number":101,"column-number":236,"status-code":200}}


--
Pawel Krawczyk
pawel.krawczyk@hush.com<mailto:pawel.krawczyk@hush.com> +44 7879 180015<tel:%2B44%207879%20180015>
CISSP, OWASP


Received on Thursday, 4 September 2014 16:11:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:06 UTC