any website can grab the server connection from browser dialer on localhost

[mmmray]

When running xray's browser dialer on localhost:3000, any website can connect to ws://localhost:3000, wait for a dialing attempt, and learn about the used proxy that way.

Steps to reproduce:

1. Create some kind of websocket xray config (ws+vless, ws+vmess, does not matter), and launch it like so: XRAY_BROWSER_DIALER=127.0.0.1:3000 ./xray
2. the port 3000 can be changed to something else as well
3. have something connect to the xray instance and initiate connections to the internet -- it does not matter if they are successful or whether an actual dialer browser is running
4. open http://mmmray.github.io/dialer-detector in a browser -- browser may use a proxy, but must not route localhost connections through it
5. the website initiates a full port scan, and will print the xray server's hostname when successful

The idea is that a domestic website could use this to detect whether somebody is connecting through xray, and through which server, then ban that server. It does not matter if the website itself has been accessed through xray, so the geosite:cn best-practice does nothing.

Some notes:

• I am reporting this publicly because I think this is at most a minor security issue with no people impacted, and because it is not actively exploited and only theoretical. I could not find a security contact.
• The port scanner is very slow and naive. It can be optimized easily, for example it could attempt common ports like 3000 first.

Any one of these changes to xray could fix the issue:

• Xray could reject the websocket connection if Origin is wrong, and ideally log a warning
• some kind of CSRF token in the browser dialer which is passed from xray to the browser via HTML, and passed from the browser to xray when opening the websocket connection.
• dialer is not hosted on / but some secret, user-defined subpath

Users who use the browser dialer (are there any?) can defend against this today without code changes by:

• Turn off websockets entirely in their browser, and use a separate browser instance as dialer
• Run xray's browser dialer on a different IP address than 127.0.0.1, or for example in a docker container. Then the attacker website would have to scan many IPs...

[Fangliding]

In fact, malicious JavaScript can obtain much more information than this, so I don't think that's a big problem (

[mmmray]

can you elaborate? I don't think this is true, or shouldn't be.

…

-------- Original Message --------

On 11 Apr 2024, 11:13, 风扇滑翔翼 wrote: Closed [#3236](#3236) as completed. — Reply to this email directly, [view it on GitHub](#3236 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/BB3PZEFLQLXB76NNOITZSQTY4ZH4VAVCNFSM6AAAAABFZUN6WOVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJSGQZTGNRTGIZTOMA). You are receiving this because you authored the thread.Message ID: ***@***.***>

[Fangliding]

can you elaborate? I don't think this is true, or shouldn't be.
…
-------- Original Message --------
On 11 Apr 2024, 11:13, 风扇滑翔翼 wrote: Closed #3236 as completed. — Reply to this email directly, [view it on GitHub](#3236 (comment)), or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

Browser exposure of local web services is indeed a security issue
I recommend reporting this question to Google and Mozilla

[mmmray]

please refer to https://stackoverflow.com/a/37837709 yes, it is very problematic behavior of browsers, but it is intentional. Websockets are old and stable, and it is unlikely to be fixed in browsers either way. I think it is x-ray's responsibility to prevent attacks like this. At the same time I do respect the decision to not work on this in the case of browser dialer. My point is that if there are other configs (not using browser dialer) that leak like this, it should be fixed. -------- Original Message --------

…

On 11 Apr 2024, 11:20, 风扇滑翔翼 wrote: > can you elaborate? I don't think this is true, or shouldn't be. > […](#) > -------- Original Message -------- > On 11 Apr 2024, 11:13, 风扇滑翔翼 wrote: Closed #3236 as completed. — Reply to this email directly, [view it on GitHub]([#3236 (comment)](#3236 (comment))), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/BB3PZEFLQLXB76NNOITZSQTY4ZH4VAVCNFSM6AAAAABFZUN6WOVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJSGQZTGNRTGIZTOMA). You are receiving this because you authored the thread.Message ID: @.***> Browser exposure of local web services is indeed a security issue I recommend reporting this question to Google and Mozilla — Reply to this email directly, [view it on GitHub](#3236 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/BB3PZECAS7N43YUITQAVQ3LY4ZIW3AVCNFSM6AAAAABFZUN6WOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBZGI3TKNRUHE). You are receiving this because you authored the thread.Message ID: ***@***.***>

[dyhkwong]

Isn't it expected behavior for popular browsers? There are so many legit use cases. If you do care about this, just add https://github.com/uBlockOrigin/uAssets/blob/master/filters/lan-block.txt to your ad-blocker. Also https://wicg.github.io/private-network-access/ is currently only a draft. Adding some authentication functions are enough.

[mmmray]

(I am not sure if you are responding to me or Fangliding) blocking local IPs in ublock is also a good mitigation, but i think xray can fix this problem and be secure out of the box. yes the browser vendors say it is expected behavior. the suggested mitigations (validation of origin header) do not affect other usecases. unless there is a usecase to run the browser dialer JS code from a non-local IP somehow? The draft is interesting!

[mmmray]

I'm arguing too much, here's a possible fix for the issue: #3295