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

ASSIGNED
Assigned to

Status

()

P3
normal
ASSIGNED
4 years ago
28 days ago

People

(Reporter: tollmanz, Assigned: baku)

Tracking

(Blocks: 1 bug)

39 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [domsecurity-backlog1])

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
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."
Thanks tollmanz - moving to DOM::Security.
Component: Untriaged → DOM: Security
Product: Firefox → Core

Comment 2

4 years ago
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 4

3 years ago
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

3 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Whiteboard: [domsecurity-backlog]
Priority: -- → P2
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

3 years ago
(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.
Priority: P2 → P1
Priority: P1 → P3
Whiteboard: [domsecurity-backlog] → [domsecurity-backlog1]
Duplicate of this bug: 1345101
Duplicate of this bug: 1363326

Comment 11

2 years ago
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

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

Comment 13

7 months ago
This first patch makes CSP to report the effective directive, following what the spec says.
Assignee: nobody → amarchesini
Status: NEW → ASSIGNED
Attachment #9004472 - Flags: review?(dveditz)
(Assignee)

Comment 14

7 months ago
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.
Attachment #9004473 - Flags: review?(dveditz)
(Assignee)

Comment 15

7 months ago
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.
Attachment #9004472 - Flags: review?(dveditz)
(Assignee)

Updated

7 months ago
Attachment #9004473 - Flags: review?(dveditz)
See Also: → bug 948151
You need to log in before you can comment on or make changes to this bug.