New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CSP reports for eval() and inline script are identical #52

Open
kravietz opened this Issue Sep 2, 2014 · 8 comments

Comments

Projects
None yet
6 participants
@kravietz
Copy link

kravietz commented Sep 2, 2014

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

This comment has been minimized.

Copy link
Member

mikewest commented Sep 3, 2014

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

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

@mikewest mikewest added this to the CSP 3 milestone Sep 3, 2014

@devd

This comment has been minimized.

Copy link
Contributor

devd commented Sep 3, 2014

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

This comment has been minimized.

Copy link

kravietz commented Sep 3, 2014

@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

This comment has been minimized.

Copy link

oreoshake commented Sep 3, 2014

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.

@hillbrad hillbrad added the CSP label Oct 27, 2014

@kravietz

This comment has been minimized.

Copy link

kravietz commented Feb 19, 2015

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

This comment has been minimized.

Copy link
Contributor

mozfreddyb commented Feb 20, 2015

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

This comment has been minimized.

Copy link

kravietz commented Feb 20, 2015

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

This comment has been minimized.

Copy link

oreoshake commented Feb 20, 2015

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/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment