CSP reports for eval() and inline script are identical

[kravietz]

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.

The solution might be either sending some kind of generic blocked-urlvalue - 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.

[mikewest]

Well, that's easy: you should allow neither. :)

Point taken, though. Would you be willing to relay this suggestion to public-webappsec@w3.org?

[devd]

Also, while we fix this properly, you might find it useful right now to use script-src * 'unsafe-eval' and script-src * 'unsafe-inline' in two separate report-only headers for getting this telemetry.

[kravietz]

@devd This might be an option if you're fine-tuning a single website's policy, but I'm trying to do this on larger scale on http://cspbuilder.info/ so the CSP report processing is fully automatic. I'm currently working around the report identity problem by a simple heuristic - if the policy had unsafe-inline then the report was caused by eval() and vice-versa...

[oreoshake]

I highly support this. A blank blocked-uri is nothing short of confusing. I don't think it should ever be blank but I digress.

[kravietz]

This problem is actually even more visible as eval-like functions are going mainstream in Cascading Style-Sheets, so "empty blocked-uri" reports can be now generated by 4 classes of events.

[mozfreddyb]

eval-like functions are going mainstream in Cascading Style-Sheets, so "empty blocked-uri" reports can be now generated by 4 classes of events.

I don't follow. What eval is going into CSS? Could you elaborate all four classes?

[kravietz]

Instances of CSS dynamic computations (like @font-size-large: ceil((@font-size-base * 1.25));) seem to be reported under the unsafe-eval category. The "four classes" refer to types of events where browser report a CSP violation with empty blocked-uri:

• script-src for inline JavaScript code
• script-src for JavaScript eval()
• style-src for inline CSS
• style-src for dynamic CSS functions

While you can obviously distinguish between style-src and script-src by looking at violated-directive or effective-directive, there's no practical way to distinguish between these events within the same content type.

Actually, I've seen object-src reported with empty blocked-uri - an example below:

{
  "effective-directive": "object-src",
  "document-uri": "http://wiki.ms.agh.edu.pl/sklepy/spo%C5%BCywcze",
  "referrer": "https://www.google.pl/",
  "line-number": 4,
  "column-number": 2642,
  "violated-directive": "object-src 'none' ",
  "original-policy": "report-uri //cspbuilder.info/report/071889361198407050/; connect-src 'none' ; child-src 'none' ; font-src 'none' ; form-action 'none' ; frame-ancestors 'none' ; frame-src 'none' ; img-src 'self' ; media-src 'none' ; object-src 'none' ; script-src 'self' 'unsafe-inline' ; style-src 'self' 'unsafe-inline' ; default-src 'none' ; reflected-xss filter; referrer origin-when-cross-origin;",
  "blocked-uri": "",
  "status-code": 200,
  "source-file": "http://ajax.googleapis.com"
}

Not sure how to interpret this one, but I've seen quite a lot of them.

[oreoshake]

Not to derail the current conversation...

The "four classes" refer to types of events where browser report a CSP violation with empty blocked-uri: script-src for inline JavaScript code script-src for JavaScript eval() style-src for inline CSS style-src for dynamic CSS functions

And event handlers and <a href="javascript:alert()">

https://csp-inline-fingerprint.herokuapp.com/