Link Search Menu Expand Document

Cross-Site WebSocket Hijacking

Play SecureFlag Play Labs on this vulnerability with SecureFlag!

  1. Cross-Site WebSocket Hijacking
    1. Description
    2. Impact
    3. Prevention
    4. Testing
    5. References

image

Description

Cross-Site WebSocket Hijacking (CSWH) happens when an endpoint exposing a WebSocket is not guarded against Cross-Site Request Forgery (CSRF), e.g., it merely checks the cookies that come with the request to authenticate the client. This is particularly worrisome since, unlike regular CSRF, WebSockets are not subject to the Same-Origin Policy (SOP). In the case of Websockets, an attacker can only initiate a blind action on behalf of the authenticated user; however, in the case of a CSWH, the attacker can gain full access (full-duplex communication) on the WebSocket channel.

Impact

The impact depends on how the web application uses the WebSocket. For example, it could be the vector employed by the web application to notify some minor events, or it could be used as a unified way to issue sensitive commands to the backend.

Prevention

Depending on the scenario, there are two effective ways to prevent CSWH exposure:

  • The usual CSRF prevention may be implemented for the endpoint that serves the WebSocket (e.g., introducing a CSRF token);

  • The WebSocket server may be instructed to only accept requests originating from an allow list of domains.

Testing

Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality.

References

PortSwigger - Cross-site WebSocket hijacking


Table of contents