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)

54 Branch
defect
Not set
normal

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
Component: Untriaged → DOM: Security
Product: Firefox → Core
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.