CSP reports for WebSocket connections are missing blocked-uri information

RESOLVED FIXED in Firefox 65

Status

()

defect
P2
normal
RESOLVED FIXED
6 months ago
4 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)

(Reporter)

Description

6 months ago
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 :-(
(Assignee)

Comment 2

5 months ago
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]
(Assignee)

Comment 3

5 months ago
Hey April, any chance I could convince you to apply the patch and actually test if it works correctly?
Attachment #9024823 - Flags: review?(april)
(Reporter)

Comment 4

5 months ago
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.  :)
(Assignee)

Comment 5

5 months ago
(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?
(Assignee)

Comment 6

5 months ago
Just to make sure everything else is fine with that patch as well:
 https://treeherder.mozilla.org/#/jobs?repo=try&revision=b73bcb13c031b57bbe7715e2de5ccc02f1454ba1
(Reporter)

Comment 7

5 months ago
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!
(Reporter)

Updated

5 months ago
Attachment #9024823 - Flags: review?(april) → review+
(Assignee)

Updated

5 months ago
Keywords: checkin-needed

Comment 8

5 months ago
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

Comment 9

5 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/2e69bd4775a5
Status: ASSIGNED → RESOLVED
Last Resolved: 5 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.