We should define websocket first before exploring websocket hijacking. While similar to HTTP in concept, applications using websocket necessitate a two-way, persistent connection between their endpoints. During that time, the connection between the client and server remains stable, allowing data to be passed back and forth between them without the need for continuous polling.
To know more about the websocket basic please visit my previous blog:
When a websocket connection is established, it will only do so through the use of http when the client makes an update to the request. However, throughout the upgrade process, neither authentication or authorization will take place. Additionally, communication that is established through a websocket connection will not be encrypted. This will increase the risk of attackers inserting themselves onto the server, and in the event that malware is installed onto the server, anything might take place.
Different ways to exploit websocket hijacking
The client initiates the process of establishing a Websocket connection by sending a request to the server to do so. The server then provides the client with a one-of-a-kind session ID that may be used to identify the connection that exists between the client and the server. The client and the server will begin exchanging data after this session id has been produced and the connection to the Websocket has been established. Let us investigate the methods that attackers use to try to take advantage of this:
Session fixation is a sort of vulnerability that most commonly occurs in web applications. This type of vulnerability allows an attacker to set the legitimate user id and take control of the legitimate user’s session. An attacker can take over a legitimate user’s account and use their session id if they are aware of a legitimate user’s session. This attack may also be carried out…