0

i read every available hijacking websocket guide/explanation there is in the wild but i still don't understand one thing.

In a CSWSH it is possible to custom requests to the server and retrieve sensitive information that an attacker can steal, also perform sensitive state-changing actions like a normal CSRF.

But, is it possible to send the normal/default request to the server and change the server's response?

Lets say a website that uses websockets to receive prices of items,

a sample request would be:

{Price: apple}

A simple response would be

Price apple: 100

i want to know if it would be possible just to change the response from the server and say that apple is worth 5 or 500 instead of 100, without changing the request to the server... just the response

  • 3
    sockets don't work on request/response cycles like http does. any behavior is going to be defined by the code running on the server, and it's much less structured than with form responses. – dandavis Feb 11 '20 at 18:08
  • 2
    "i read every available hijacking websocket guide/explanation there is in the wild" - either prove this or don't claim such things. And the information is mostly useless anyway since it does not say what you've actually read. And I don't understand your attack idea: CSWSH is done by including a websocket connection to some cross-origin server which gets used with the victims credentials into the attackers page - why should the attacker care about getting a different response from the server if they are able to modify the response after it got retrieved? – Steffen Ullrich Feb 11 '20 at 20:22
  • @SteffenUllrich why do you answer all the questions aggressively? and how do you want me to prove this? by pasting all the 10 links i read about?? come on man... Also "why should the attacker care about getting a different response from the server" i already explained in the first comment, if you trick the victim into thinking a item is woth 5 dolars instead of 50 or that an item is worth 500 dolars instead of 10 you trick them into buying or not buying staff – Mr. ToxicMan Feb 13 '20 at 0:34
  • @SteffenUllrich i think the answer to my question is no, you can make requests to the websocket, retrieve responses to steal information but you can't actually change the responses... i just wanted to be sure since i couldn't find anywhere someone actually explaining this – Mr. ToxicMan Feb 13 '20 at 0:37
  • 2
    @Mr.ToxicMan: "... and how do you want me to prove this?"* - actually I don't want to. I want instead that you don't make such ridiculous claims in the first place which don't add relevant information to your question anyways. Instead describe what you know and when you are in doubt of your knowledge maybe where specifically this knowledge comes from. – Steffen Ullrich Feb 13 '20 at 1:37
1

No, it's not possible to change the servers WS channel response (if you use WSS).

WSS is websocket with TLS security, its a thing. As with all things transport security related, the answer is TLS.

It's not possible to change the response when you use WSS.


If you design your system to use plain old WS, you must expect that it is possible.

Being TCP based, injection into a TCP stream has the same challenges all TCP connections have (which is hard to find, maybe a separate question?). It's much simpler with a machine in the middle attack.

The regular WS protocol wasn't designed to be secure. That's probably because they knew people would use TLS if they wanted security.

In the RFC, there is a description of an obscure kind of attack, that a proxy unaware of WS might fall for - see https://tools.ietf.org/html/rfc6455#section-10.3.

  • 1
    The question basically answers if a man in the middle attack against Websockets is possible. The answer to this is not wrong (it is basically the same with WS/WSS as with HTTP/HTTPS). But the answer does not address the CSWSH context given by the OP, since CSWSH is not a man in the middle attack. It is not clear though if the OP actually restricted its question to CSWSH or if he asked about attacks against Websockets in general or if he thought that CSWSH is a man in the middle attack. Therefore it might be helpful to make the relation to CSWSH clear in the answer. – Steffen Ullrich Feb 13 '20 at 2:05
  • I'm good at spotting red herrings. OP says "In a CSWSH it is possible to custom requests... but is it possible to send the normal...". In addition, the title makes the question quite clear: "Hijacking Websocket", as well as the last half of the question-post that comes after "but". – Todd Feb 14 '20 at 1:03
  • "....the title makes the question quite clear: "Hijacking Websocket", ..." - which in my opinion exactly refers to CSWSH, which means Cross Site Websocket Hijacking. There is no mention of man in the middle in the question at all. Instead the OP refers multiple times to this hijacking only. – Steffen Ullrich Feb 14 '20 at 6:00
  • I added another answer to make it clearer: CSWSH by nature cannot be used for changing the WS channel messages to the client. But that still leaves WS channel injection (MITM) which is what this answer is about. – Todd Feb 15 '20 at 4:56
1

No, it's not possible, if you're only talking about a CSWSH style of hijacking.

In CSWSH, the user is on an attacker-website and the attack happens on the user's browser while on the attacker-website.

For a WebSocket, for the ability to "write" something to the server, or "read" some private information back, the WS security mechanism must be cookie-driven, and the writable remote messaging functions need to be vulnerable (don't require additional unique information) for "write" attacks.

A "write" attack of CSWSH could change the price of an apple, if the server's pricing functions are vulnerable. The user would need to be authorised to make the price change, or the server functions would need to be unsecured. The attacker would need to know the right messages to send. But this isn't mutating data coming back through the WS channel itself.

It isn't possible to change the server-data coming from the websocket itself. CSWSH operates on the browser side on the receiving end of server communications, not in the middle in between the legitimate side and the server - that requires a MITM attack of some sort that is stopped by TLS.

Being on the attacker-website, naturally, the attacker-website cannot change the data being returned from the WebSocket channel itself. However, it could receive a value from the server and present a different value to the user. That occurs by throwing away the server value after it arrives in the browser from the WebSocket. But there is little or no value for this, the attacker-website is already a fraud and can display incorrect information without waiting for a WebSocket message from the server.

Regardless of what happens on the client-side, server functions need to be defined to validate input. Even on the legitimate site, if the client-side can assert their own apple price in an order, it's not secure in general anyway. The server should lookup the price of the apple from the product-id in the order when charging the user's credit card.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.