Open
Bug 1506992
Opened 7 years ago
Updated 3 years ago
Sending a CSP report doesn't send cookies
Categories
(Core :: DOM: Security, defect, P3)
Tracking
()
NEW
People
(Reporter: rover.bugfinder, Unassigned)
Details
(Whiteboard: [domsecurity-backlog2])
Attachments
(1 file)
|
7.97 KB,
application/zip
|
Details |
User Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20170401 Firefox/56.0
Steps to reproduce:
Firefox 63.0.1 running in safe mode (issue was present at least in v62 as well).
Open a page which:
- has a Content-Security-Policy header with the report-uri parameter set,
- sets any cookie,
- violates its own Content Security Policy,
with the intent for the CSP report to be sent.
Actual results:
A request with the CSP violation report was prepared and sent, but WITHOUT the cookie, even though the host/website matches. Following requests to "regular" pages correctly send the cookie again, though.
Expected results:
A request with the CSP violation report should have been prepared and sent WITH the cookie for the host/website.
See also:
- https://www.w3.org/TR/CSP/ (doesn't mention cookies at all),
- https://www.w3.org/TR/CSP2/, which says "If the origin of report URL is not the same as the origin of the protected resource, the block cookies flag MUST also be set", but since the condition is not met, the "block cookies flag" should not be sent, and according to https://www.w3.org/TR/html5/infrastructure.html#fetching-resources, 2.6.2, step 12, cookies should be processed as usual, I guess.
Maybe I'm misinterpreting the standards, but this issue has 2 outcomes:
- minor problem: the website which receives the report can't connect the CSP violation e.g. to a user session,
- major problem: if the website which receives the report is protected by cookies which are needed to access ANY resource (some hostings have this), including the CSP report receiver, the report will NOT be received by the website (it will be bounced back at the proxy/frontend server, without even reaching the target site).
Attached:
- a simple PHP page which demonstrates the problem (just modify the report-uri as appropriate),
- 2 sample network dumps from the browser's developer tools (the domain is local, it's not reachable from the Internet, so you must test e.g. on some local Apache server).
This may be somehow or may not by in any way related to:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1470038
- https://bugzilla.mozilla.org/show_bug.cgi?id=1482905
- https://bugzilla.mozilla.org/show_bug.cgi?id=1487666
as found by Bugzilla as "similar" bugs, but since I don't know the tests' details, I can't be sure.
| Reporter | ||
Updated•7 years ago
|
Component: Untriaged → Security
Updated•7 years ago
|
Component: Security → DOM: Security
Product: Firefox → Core
Comment 1•7 years ago
|
||
The working version of the spec ("CSP3") makes no mention of cookies with reporting, not even in the section of what's different between CSP2 and 3: https://w3c.github.io/webappsec-csp/
This is probably an oversight, something that dropped when the spec was rewritten in the new style. Especially given there are WPT that appear to test for this behavior. We should file an issue to get that back into the spec.
The non-deprecated "report-to" references the reporting spec, but that doesn't talk about cookies either.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Whiteboard: [domsecurity-backlog2]
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•