Insecure WebSockets requests not blocked by mixed-content checks for potentially trustworthy origins
Categories
(Core :: DOM: Security, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox120 | --- | fixed |
People
(Reporter: valedv99, Assigned: jewilde)
References
(Blocks 1 open bug)
Details
(Whiteboard: [domsecurity-active])
Attachments
(1 file)
Hi all,
As part of a research project at TU Wien, we observed an inconsistency on Firefox affecting websockets and mixed content policy restrictions.
In particular, connections to insecure websockets (ws://...) are not blocked by the mixed content policy when the WebSocket is created from a potentially trustworthy origin via blob: or by a Worker loaded via a data: URI. We provide the following payloads to test this behavior:
-
To test a Worker loaded via
data:URI, you can executenew Worker("data:text/javascript,new WebSocket('ws:example.com')");from a potentially trustworthy origin (e.g., https://example.com). -
To test
blob:URI, execute the script below from a potentially trustworthy originwindow.open( URL.createObjectURL( new File( [`<!DOCTYPE html> <script>new WebSocket("ws://example.com");</script> `], 'test.html', {type: 'text/html'} ) ) );
The Worker script (1) triggers a connection request in Firefox, while Chromium and Safari block it with a mixed-content exception:
Mixed Content: The page at 'data:text/javascript,new WebSocket('ws:example.com')' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://example.com/'. This request has been blocked; this endpoint must be available over WSS.
Similarly, the blob example (2) does not cause any error on Firefox but it is blocked on Chromium and Safari:
Mixed Content: The page at 'blob:https://example.com/d81594fc-508d-48a2-969c-7abf0703f2be' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://example.com/'. This request has been blocked; this endpoint must be available over WSS.
From our understanding of the specs (https://html.spec.whatwg.org/multipage/webappapis.html#secure-contexts and https://www.w3.org/TR/mixed-content/#blockable-mixed-content), a WebSocket request is blockable and, as such, insecure websocket requests must be forbidden when initiated from a potentially trustworthy origin, including a Worker or a blob created from an https page.
We noticed a similar issue in an older version of Chromium concerning Workers and data: URIs created from secure contexts (https://bugs.chromium.org/p/chromium/issues/detail?id=1325494), resulting in mixed-content blocks not being enforced. We also found bug#1787323 that could be somehow related to this issue.
|
||
Updated•2 years ago
|
|
|
||
Comment 1•2 years ago
|
||
We should already enforce this, are we getting the trustworthiness of the blob origin (in the window.open) itself wrong?
June: could you take a look?
|
|
||
Updated•2 years ago
|
|
|
||
Comment 2•2 years ago
|
||
Should we treat this as a hidden "security" bug? Blocking these requests (as opposed to upgrading) doesn't protect users so much as it forces web developers to code their page more securely, and given the prevalence of chromium browsers that will happen whether Firefox has this bug or not
|
Assignee | |
Comment 3•2 years ago
|
||
|
|
Assignee | |
Comment 4•2 years ago
|
||
It looks like we either aren't considering trustworthiness for blob and data origins in the mixed content check in WebSocketImpl::IsSecure or our isSecure bool is being overwritten before we take it into consideration.
I'm fairly certain it's the former, but I'm not entirely sure what the correct check would be
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
||
Comment 7•2 years ago
|
||
| bugherder | ||
Description
•