1

I can't understand why SOP (same-origin policy) cannot block Cross-Origin WebSocket Hijacking, I just read this article and I can't understand from where WebSocket requests comes from.

From where does WebSocket requests comes from, that SOP cann't block attacks related to it ?

Improve this question
3
  • See blog.securityevaluators.com/… for an excellent write-up on why same-origin policy does not apply to WebSockets. stackoverflow.com/questions/23674199/… is also helpful.
    – mti2935
    Jul 18, 2020 at 22:48
  • Websockets have a kind of better SOP. Instead of a policy, the server actually checks the origin.
    – user253751
    Jul 21, 2020 at 19:00
  • @user253751: Except it doesn't. Got here trying to deal with a wss://127.0.0.1 messing up a non-HTTPS server.
    – Joshua
    Mar 29, 2022 at 20:43

2 Answers 2

Reset to default
3

Same-origin policy considers all of these origins to be different:

http://example.com
https://example.com
ws://example.com
wss://example.com

So if browsers were to apply SOP rules to WebSockets, if a page at https://example.com tried to connect to a WebSocket at wss://example.com it would fail.

In theory WebSockets could have been designed to use CORS headers during the initial HTTP handshake, but these two technologies were developed at roughly the same time.

Improve this answer
2
  • Are you sure that SOP will block a WebSocket webpage, because WebSocket doesn't even have a SOP Application, no ?
    – user226295
    Jul 18, 2020 at 23:14
  • @nakE It won't in reality, I was talking about the hypothetical scenario if browsers were to use SOP for WebSockets.
    – Alexander O'Mara
    Jul 18, 2020 at 23:15
3

Consider a case where a user browses a page at evil.com, and scripting in the page served by evil.com attempts to make a cross-site websockets request to bank.com in an attempt to access the user's sensitive banking information.

The websockets connection begins with a handshake to bank.com using https protocol. Because SOP does not apply to websockets, the scripting in the page served by evil.com will be able to access the response headers of the https handshake from bank.com, and send these response headers back to evil.com - but these are unlikely to contain any sensitive information. After the https handshake, the connection upgrades to ws or wss protocol. If bank.com does not support ws or wss protocol, then the connection will fail at that point. So, websockets cannot be used (abused) in the same way that XHR or Ajax can be used (abused) to attempt to access sensitive cross-site information by making standard https requests across sites.

If bank.com does support websockets protocol, then the onus is on bank.com to prevent unauthorized cross-site requests. In the websockets request to bank.com, the browser will send an origin header containing the origin of the page making the request (evil.com), and it is up to bank.com to validate the request based on the origin.

Improve this answer

You must log in to answer this question.