Re: CSP reports on eval() and inline

Unfortunately, in case of inline scripts and eval() typical CSP violation reports don’t seem to be very verbose - for example, this is what Chrome sends (in both cases report is identical):

"referrer": "",
  "original-policy": "base-uri 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';",
  "violated-directive": "script-src 'none'",
  "blocked-uri": "",
  "status-code": 200,
  "document-uri": "http://webcookies.info/"



On 4 Sep 2014, at 17:11, Hill, Brad <bhill@paypal.com> wrote:

> 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> 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":"","violated-directive":"script-src 'none'","original-policy":"base-uri 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-urihttp://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 +44 7879 180015
> CISSP, OWASP
> 
> 
>  


-- 
Pawel Krawczyk
pawel.krawczyk@hush.com +44 7879 180015
CISSP, OWASP