Closed
Bug 1363326
Opened 7 years ago
Closed 7 years ago
csp-report reports wrong violated directive, should not fall back to default-src
Categories
(Core :: DOM: Security, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1192684
People
(Reporter: janghou, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0 Build ID: 20170418123315 Steps to reproduce: open https://dev.webonomic.nl/demos/csp_bug.php open developer tools and inspect csp reports in network tab Two csp request are made: one for a img and one for a script. Actual results: Two csp-report report: 1 blocked-uri "https://dev.webonomic.nl/demos/yoga2.svg" ... violated-directive "default-src none:" 2 blocked-uri "https://dev.webonomic.nl/demos/evil.js" ... violated-directive "default-src none:" Expected results: It should report 1 blocked-uri "https://dev.webonomic.nl/demos/yoga2.svg" ... violated-directive:"img-src" 2. blocked-uri "https://dev.webonomic.nl/demos/evil.js" ... violated-directive:"script-src" Although a directive falls back to default-src, the script-src and image-src directives are actually violated. An directive that does not explicitly appear in the policy is still the directive that is violated. Also I wonder if the directive should contain sources e.g. `none:`, IMHO a directive is just script-src or img-src. The source will show up in the `blocked- uri` I think Chromium does it right here. USE-CASE This all is important for parsing csp-reports automatically, reports that fall back to default-src does not give valuable info. Based on Firefox reports, its suggests a fix for showing the image is adjusting default-src, while this will allow the evil-script too. Also in Firefox 53/ Developer 54 / Firefox Android
Updated•7 years ago
|
Component: Untriaged → DOM: Security
Product: Firefox → Core
Comment 1•7 years ago
|
||
From https://w3c.github.io/webappsec-csp/2/#example-violation-report The protected resource loaded an image from http://evil.example.com/image.png, violating the policy. { "csp-report": { "document-uri": "http://example.org/page.html", "referrer": "http://evil.example.com/haxor.html", "blocked-uri": "http://evil.example.com/image.png", "violated-directive": "default-src 'self'", "effective-directive": "img-src", "original-policy": "default-src 'self'; report-uri http://example.org/csp-report.cgi" } } According to that our violated-directive is correct. We are not be sending the "effective-directive" though.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
I read the specs different: https://w3c.github.io/webappsec-csp/#report-violation effectiveDirective : violation’s effective directive violatedDirective : violation’s effective directive Note: Both effectiveDirective and violatedDirective are the same value. This is intentional to maintain backwards compatibility. So for report-url (deprecated), it should send the effective-directive value for violated-directive For the new report-to you are probably right, in the example I used report-uri And your right that the effective directive is missing, but this is a different bug. (or an CSP2/CSP3 issue)
You need to log in
before you can comment on or make changes to this bug.
Description
•