CSP reports for WebSocket connections are missing blocked-uri information

RESOLVED FIXED in Firefox 65

Status

()

defect
P2
normal
RESOLVED FIXED
9 months ago
7 months ago

People

(Reporter: April, Assigned: ckerschb)

Tracking

61 Branch
mozilla65
Points:
---
Bug Flags:
qe-verify -

Firefox Tracking Flags

(firefox65 fixed)

Details

(Whiteboard: [domsecurity-active])

Attachments

(1 attachment)

One of the problems I've had with Laboratory is generating correct Content Security Policies when it comes to the use of web sockets.

If a resource is blocked, it will generate the following error in the console:

> Content Security Policy: The page’s settings observed the loading of a resource at
> wss://live.github.com/_sockets/VjI6MzQ31Dg2NTUwOmNjOGY5MTU5ed320032 (“connect-src”).
> A CSP report is being sent.

However, the CSP report it generates looks like this:

>{
>  "blocked-uri": "wss",
>  "document-uri": "https://github.com/",
>  "original-policy": "default-src 'none'; connect-src http: https:; ... stuff here ...; report-uri https://github.com/laboratory-fake-csp-report",
>  "referrer": "https://github.com/sessions/two-factor",
>  "violated-directive": "connect-src"
>}

"blocked-uri" should contain "wss://live.github.com/_sockets/VjI6MzQ31Dg2NTUwOmNjOGY5MTU5ed320032", and not just "wss".
Over-restrictive whitelist :-(
Yes, that seems like a bug, we should fix that here:
https://searchfox.org/mozilla-central/source/dom/security/nsCSPContext.cpp#817

I'll do it :-)
Assignee: nobody → ckerschb
Status: NEW → ASSIGNED
Priority: -- → P2
Whiteboard: [domsecurity-active]
Hey April, any chance I could convince you to apply the patch and actually test if it works correctly?
Attachment #9024823 - Flags: review?(april)
I'll do you one better, I'll give you an easy way to test it:

1) Install Laboratory: https://addons.mozilla.org/en-US/firefox/addon/laboratory-by-mozilla/
2) Go to: http://www.websocket.org/echo.html
3) Click the Laboratory icon, and select "Record this site"
4) Refresh the page
5) Click the Connect button
6) Open the Laboratory panel and check the CSP policy it generates.

If it has connect-src ws:, then the patch doesn't work and it's using my workaround code. If it shows connect-src ws://echo.websocket.org/, then the patch works.  :)
(In reply to April King [:April] from comment #4)
> If it has connect-src ws:, then the patch doesn't work and it's using my
> workaround code. If it shows connect-src ws://echo.websocket.org/, then the
> patch works.  :)

Seems to work from the browser side of things:
   default-src 'none';
=> connect-src ws://echo.websocket.org/?encoding=text;
   font-src 'self' https://fonts.gstatic.com;
   ...

I guess you have to update Laboratory to remove everything after the '?', right?
Just to make sure everything else is fine with that patch as well:
 https://treeherder.mozilla.org/#/jobs?repo=try&revision=b73bcb13c031b57bbe7715e2de5ccc02f1454ba1
Hmm, yep, must be a bug with parsing those URLs. I'll poke at that today and push out an update. But glad to see that things are otherwise working!
Attachment #9024823 - Flags: review?(april) → review+
Keywords: checkin-needed
Pushed by aciure@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2e69bd4775a5
CSP - Do not strip blockedURI in reports for WebSocket. r=april
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/2e69bd4775a5
Status: ASSIGNED → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
Flags: qe-verify-
You need to log in before you can comment on or make changes to this bug.