Closed Bug 1204989 Opened 9 years ago Closed 8 years ago

The violated-directive in CSP reports is malformed when both CSP and CSPRO headers are present.

Categories

(Core :: DOM: Security, defect)

40 Branch
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: bugzilla, Unassigned)

Details

(Whiteboard: [domsecurity-backlog])

Attachments

(3 files)

Attached image firefox-bug-2.png
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2503.0 Safari/537.36

Steps to reproduce:

Issue a CSP and CSPRO header on a site. 
Create a violation on the page that triggers a violation in both policies. 
The resulting violation of the CSPRO contains the violated-directive string for both the CSP and CSPRO headers joined together.

The CSP: 

Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval' https://scotthelme.co.uk; upgrade-insecure-requests; block-all-mixed-content; report-uri https://test.report-uri.io/report/ScottHelme"

The CSPRO:  

Content-Security-Policy-Report-Only "default-src https: data: 'unsafe-inline' 'unsafe-eval'; report-uri https://test.report-uri.io/report/ScottHelme"

The violating asset: 

<img src="ftp://example.com/profile.png">

The CSP contains "https://scotthelme.co.uk" in the default-src directive to distinguish between the policies. 

The resulting CSP violation report (determined by the presence of "https://scotthelme.co.uk" in the original policy): 

{"csp-report":{"blocked-uri":"ftp://example.com/profile.png","document-uri":"https://scotthelme.co.uk/csp-test/","original-policy":"default-src https: data: 'unsafe-inline' 'unsafe-eval' https://scotthelme.co.uk; report-uri https://test.report-uri.io/report/ScottHelme","referrer":"","violated-directive":"default-src https: data: 'unsafe-inline' 'unsafe-eval' https://scotthelme.co.uk"}}

The resulting CSPRO violation report (determined by the lack of "https://scotthelme.co.uk" in the original policy): 

{"csp-report":{"blocked-uri":"ftp://example.com/profile.png","document-uri":"https://scotthelme.co.uk/csp-test/","original-policy":"default-src https: data: 'unsafe-inline' 'unsafe-eval'; report-uri https://test.report-uri.io/report/ScottHelme","referrer":"","violated-directive":"default-src https: data: 'unsafe-inline' 'unsafe-eval' https://scotthelme.co.ukdefault-src https: data: 'unsafe-inline' 'unsafe-eval'"}}

Note in the violated-directive of the CSPRO violation that it also contains the string from the CSP violation which should not be present.


Actual results:

The violated-directive string for the CSPRO report contains the string you would expect to see and the violated-directive string from the CSP report that should not be present.


Expected results:

The violated-directive string for the CSPRO report contains just the expected string.
Attached image firefox-bug-3.png
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:45.0) Gecko/20100101 Firefox/45.0 
Nightly 45.0a1 Build ID:201512020030228
 AND Firefox 42.0

Are you still able to reproduce this in the latest version ?
Flags: needinfo?(scotthelme)
Yes, this is reproducible in the latest build, 42.0

I have setup a demo page: 

https://scotthelme.co.uk/csp-test

Which loads a violating asset: 

<img src="ftp://example.com/profile.png">

Using the following headers:

add_header Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval' ; upgrade-insecure-requests; block-all-mixed-content; report-uri https://report-uri.io/report/ScottHelme" always;
add_header Content-Security-Policy-Report-Only "default-src https: 'unsafe-inline' 'unsafe-eval' https://scotthelme.co.uk; report-uri https://report-uri.io/report/ScottHelme/reportOnly" always;

Resulting in the following CSP reports:

CSP: 
{
    "csp-report": {
        "blocked-uri": "ftp://example.com/profile.png",
        "document-uri": "https://scotthelme.co.uk/csp-test/",
        "original-policy": "default-src https: data: 'unsafe-inline' 'unsafe-eval'; upgrade-insecure-requests; report-uri https://report-uri.io/report/ScottHelme",
        "referrer": "",
        "violated-directive": "default-src https: data: 'unsafe-inline' 'unsafe-eval'"
    }
}

CSPRO:
{
    "csp-report": {
        "blocked-uri": "ftp://example.com/profile.png",
        "document-uri": "https://scotthelme.co.uk/csp-test/",
        "original-policy": "default-src https: 'unsafe-inline' 'unsafe-eval' https://scotthelme.co.uk; report-uri https://report-uri.io/report/ScottHelme/reportOnly",
        "referrer": "",
        "violated-directive": "default-src https: data: 'unsafe-inline' 'unsafe-eval'default-src https: 'unsafe-inline' 'unsafe-eval' https://scotthelme.co.uk"
    }
}


As you can see, the "violated-directive" of the CSPRO report contains the value from the CSP report first and then the expected value of the CSPRO appended after it.
Flags: needinfo?(scotthelme)
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Component: Untriaged → DOM: Security
Product: Firefox → Core
Resolution: --- → DUPLICATE
I don't believe that this bug is a duplicate of the one linked. 

This bug outlines the issue that the violated-directive of a report from a CSPRO is malformed when issued alongside a CSP. 

The issue that this is marked as a duplicate of is about the original-policy value of a report not being an accurate representation of the policy that was delivered to the browser.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Nightly 46.0a1 Build ID:20151229030213.

The issue is reproducible and demo page is given by the reporter.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Matt, Kamil, can we still reproduce this?
Flags: needinfo?(mwobensmith)
Flags: needinfo?(kjozwiak)
Whiteboard: [domsecurity-backlog]
QA Contact: kjozwiak
Attached file poc.php
Reproduced the original issue using the above examples with the following build:
* https://archive.mozilla.org/pub/firefox/releases/40.0/

Received the following CSP report:

{
    "csp-report": {
        "blocked-uri": "http://example.com/profile.png",
        "document-uri": "http://localhost:8000/poc.php",
        "original-policy": "default-src https: 'unsafe-inline' 'unsafe-eval' https://scotthelme.co.uk; report-uri https://report-uri.io/report/kamiljoz/reportOnly",
        "referrer": "",
        "violated-directive": "default-src https: data: 'unsafe-inline' 'unsafe-eval'default-src https: 'unsafe-inline' 'unsafe-eval' https://scotthelme.co.uk"
    }
}

Went through verification using the following builds:
* https://archive.mozilla.org/pub/firefox/nightly/2016/03/2016-03-17-03-02-35-mozilla-central/
* https://archive.mozilla.org/pub/firefox/nightly/2016/03/2016-03-17-00-40-16-mozilla-aurora/
* https://archive.mozilla.org/pub/firefox/candidates/46.0b2-candidates/build3/
* https://archive.mozilla.org/pub/firefox/releases/45.0.1/

Results:

* fx48.0a1 - PASSED
* fx47.0a2 - PASSED
* fx46.0b2 - PASSED
* fx45.0.1 - PASSED

Received the following CSP report:

{
    "csp-report": {
        "blocked-uri": "http://example.com",
        "document-uri": "http://localhost:8000/poc.php",
        "original-policy": "default-src https: 'unsafe-inline' 'unsafe-eval' https://scotthelme.co.uk; report-uri https://report-uri.io/report/kamiljoz/reportOnly",
        "referrer": "",
        "violated-directive": "default-src https: 'unsafe-inline' 'unsafe-eval' https://scotthelme.co.uk"
    }
}

Received the following CSP error via the browser console:

* Content Security Policy: The page's settings observed the loading of a resource at http://example.com/profile.png ("default-src https: 'unsafe-inline' 'unsafe-eval' https://scotthelme.co.uk"). A CSP report is being sent.

Chris, looks like this isn't an issue anymore. I managed to reproduced the problem with fx40.0 and couldn't reproduce the problem using fx48.0a1, fx47.0a2, fx46.0b2 and fx45.0.1.
Flags: needinfo?(mwobensmith)
Flags: needinfo?(mozilla)
Flags: needinfo?(kjozwiak)
(In reply to Kamil Jozwiak [:kjozwiak] from comment #8)
> Chris, looks like this isn't an issue anymore. I managed to reproduced the
> problem with fx40.0 and couldn't reproduce the problem using fx48.0a1,
> fx47.0a2, fx46.0b2 and fx45.0.1.

Thanks Kamil. That's great!
Status: NEW → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → WORKSFORME
Flags: needinfo?(mozilla)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: