1596889 - Missing Origin for Websockets created in webextension frame

Status: RESOLVED DUPLICATE of bug 1257989

(WebExtensions :: General, defect)

Description

[glacambre]

Attachment: reproducer.tar

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

Tried to create a websocket from an iframe the document of which resides in webextension storage on Firefox Nightly.

Actual results:

The Origin field of the websocket header was missing.

Expected results:

The Origin field should have been there and set to the webextension's id, like it currently is for Firefox Stable.

Comment 1

[glacambre]

Note: an easy way to reproduce this is to run nc -l -p 12345 in your shell, load the reproducer in about:debugging and then opening a new tab to e.g. http://example.org.

Comment 2

[Andrew Halberstadt [:ahal]]

Looks like it may have been intentional. Tom can you confirm if this is expected? For context this extension relies on this header.

Comment 3

[glacambre]

I guess I could do without the origin header - Firenvim also generates a random 32-bit number which it passes to the native process by using the native messaging API. The native process then makes sure that the random number is present in the websocket's headers, so it's not crucial to have the origin header - I just much prefer to also have it as it can't be forged by websites/malicious extensions while the random number could be.

Comment 4

[Tom S]

I can see this being useful for local resources, but in general I really don't want to expose such a strong fingerprint. I think we could change the Origin to moz-extension://null so at least spoofing from a website is impossible.

Comment 5

[glacambre]

we could change the Origin to moz-extension://null

This would be better than nothing (and also make Firefox match the spec a bit more closely, as websockets servers should be able to expect an Origin field ("The |Origin| header field [RFC6454] is used to protect against unauthorized cross-origin use of a WebSocket server by scripts using the WebSocket API in a web browser.", https://tools.ietf.org/html/rfc6455#section-1.3)).

However, this still isn't very satisfying from my point a view. A more satisfying change for my specific use case would be to keep sending the Origin header untouched if the websocket server is located on 127.0.0.1 - I think it is reasonable to assume that any attacker that manages to open a port on 127.0.0.1 wouldn't need a webextension id to track their victims.

I tried to implement a workaround that wouldn't require any change on Firefox's side by adding an Access-Control-Allow-Origin field set to the webextension's id in the server's websocket handshake answer but this wasn't enough to make websocket connections originating from a non-webextension context fail. Am I misunderstanding what Access-Control-Allow-Origin does and how it works or is there a bug in Firefox?