1192684 - Content Security Policy reports should include "effective-directive" and "status-code"

Status: RESOLVED FIXED

(Core :: DOM: Security, defect, P3)

Description

[tollmanz]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.107 Safari/537.36

Steps to reproduce:

1. Set a Content Security policy of `default https://www.example.com; report-uri https://www.example.com/csp-report` for an HTML document.
2. Have the HTML document attempt to load an image with src of "http://www.anotherdomain.com/test.jpg".


Actual results:

A report is issued with a JSON payload that does not include the "effective-directive" and "status-code" properties.


Expected results:

A report should be issued with:

"effective-directive": "img-src",
"status-code": 200

From the CSP2 spec regarding "effective-directive":

"The name of the policy directive that was violated. This will contain the directive whose enforcement triggered the violation (e.g. "script-src") even if that directive does not explicitly appear in the policy, but is implicitly activated via the default-src directive."

And "status-code":

"The status-code of the HTTP response that contained the protected resource, if the protected resource was obtained over HTTP. Otherwise, the number 0."

Comment 1

[Mike Hoye [:mhoye]]

Thanks tollmanz - moving to DOM::Security.

Comment 2

[Scott Helme]

I have confirmed this behaviour in 40.0.3 and the values are missing from the reports.

Appropriate parts of the spec:

https://w3c.github.io/webappsec/specs/content-security-policy/#violation-report-effective-directive

https://w3c.github.io/webappsec/specs/content-security-policy/#violation-report-status-code

Examples of a report from Chrome (Version 47.0.2508.0 dev-m 64-bit) and Firefox 40.0.3 attached.

Comment 3

[Scott Helme]

Attachment: firefox missing report values.png

Comment 4

[Scott Helme]

Issue confirmed as still present in 43.0.1

This makes it incredibly difficult to normalise CSP reports on collection as there is no effective-directive value to categorise incoming reports.

Comment 5

[Matt Robenolt]

Adding in my "+1" here since this definitely makes it hard to do any sensible aggregation of CSP reports. Right now, we choose to completely disregard any reports that don't include an `effective-directive` value, which means, we get nothing from Firefox at the moment.

But this is an acceptable tradeoff at the moment in my opinion, until Firefox is sending the expected data.

Comment 6

[Christoph Kerschbaumer [:ckerschb]]

I know we are not setting the 'effective-directive' and also don't report the status-code. So that needs to be fixed and incorporated in the JSON report, somewhere around here:
http://mxr.mozilla.org/mozilla-central/source/dom/security/nsCSPContext.cpp#756

Comment 7

[Reed Loden [:reed]]

Note that several CSP reporting tools (Sentry being one of them) are actively rejecting all Firefox CSP reports currently due to lack of these fields.

Comment 8

[Scott Helme]

(In reply to Reed Loden [:reed] (use needinfo?) from comment #7)
> Note that several CSP reporting tools (Sentry being one of them) are
> actively rejecting all Firefox CSP reports currently due to lack of these
> fields.

This is something I considered for https://report-uri.io but in the end I decided to add specific handling for Firefox. I parse the effective-directive out of violated-directive but this does introduce additional problems. When the block was a fallback to default-src I end up with an effective-directive of default-src, which makes filtering in the GUI a pain. I could try and be smarter and detect the actual effective-directive, but decided how I currently do it is a good balance between dropping all Firefox reports and manually trying to identify the actual effective-directive.

Comment 11

[janghou]

I doubt bug 1363326 is a duplicate:

https://w3c.github.io/webappsec-csp/#report-violation.

It seems CSP3 suggests different reporting for `report-to` and `report-uri`

Comment 12

[Scott Helme]

Yeah, there's quite a shift in reporting for CSP3 but I think this bug is still relevant for the report payload.

Comment 13

[Andrea Marchesini [:baku]]

Attachment: part 1 - report correct directive name

This first patch makes CSP to report the effective directive, following what the spec says.

Comment 14

[Andrea Marchesini [:baku]]

Attachment: part 2 - inline directive

Probably this is not the right approach. We should implement the algorithms

https://w3c.github.io/webappsec-csp/#should-directive-execute
https://w3c.github.io/webappsec-csp/#directive-fallback-list
https://w3c.github.io/webappsec-csp/#effective-directive-for-inline-check

but this is a big refactoring of the current CSP implementation.

Comment 15

[Andrea Marchesini [:baku]]

Comment on attachment 9004472 [details] [diff] [review]
part 1 - report correct directive name

I'm not happy about these 2 patches. removing the review flag.

Comment 16

[Tom Schuster (MoCo)]

Attachment: Bug 1192684 - Content Security Policy reports should include "effective-directive" and "status-code". r?freddyb

Comment 17

[Tom Schuster (MoCo)]

We have bug 1779369 for always using the correct effective directive as per CSP 3.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7c8188d658dd
Content Security Policy reports should include "effective-directive" and "status-code". r=freddyb,webidl,smaug

Comment 19

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/7c8188d658dd

Comment 20

[Brian Thomas Smith [bsmth]]

Documentation changes for this can be tracked in the following issue on GitHub -> https://github.com/mdn/content/issues/22907

Comment 21

[Brian Thomas Smith [bsmth]]

Relnote has been added in https://github.com/mdn/content/pull/23404/files and the CSP page includes more info on the payload details: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#violation_report_syntax

Can I get confirmation on whether browser compat data updates are needed as it looks like the CSPViolationReportBody API is not supported: https://searchfox.org/mozilla-central/search?q=CSPViolationReportBody&path=.webidl&case=true&regexp=false