Was sind WebSockets und WebSocket-Schwachstellen?

WebSockets ermöglichen eine dauerhafte, bidirektionale Verbindung zwischen Client und Server. Nach einem HTTP-Handshake können beide Seiten jederzeit Nachrichten senden. Das eignet sich für Chats, Börsendaten, Spiele und Statusupdates, bedeutet aber auch: Klassische Schutzmechanismen eines einzelnen HTTP-Requests müssen auf Verbindungs- und Nachrichtenebene bewusst umgesetzt werden.

Wie funktioniert der Handshake?

GET /socket HTTP/1.1
Host: app.example.test
Upgrade: websocket
Connection: Upgrade
Origin: https://app.example.test
Sec-WebSocket-Key: RANDOM_VALUE
Sec-WebSocket-Version: 13
Cookie: session=SESSION_VALUE

Der Server antwortet bei erfolgreichem Wechsel mit Status 101 Switching Protocols. Browser senden vorhandene Cookies automatisch. Prüft der Server den Origin-Header nicht, kann eine fremde Website unter Umständen eine authentifizierte Verbindung öffnen: Cross-Site WebSocket Hijacking (CSWSH). Das ähnelt CSRF, ermöglicht aber häufig auch das Lesen empfangener Nachrichten.

Unsichere und sichere Verbindungsprüfung

// Unsicher: jede Origin wird akzeptiert
const wss = new WebSocketServer({ server });

// Besser: Origin und Authentifizierung vor dem Upgrade prüfen
server.on('upgrade', (request, socket, head) => {
  const allowed = new Set(['https://app.example.test']);
  if (!allowed.has(request.headers.origin)) {
    return socket.destroy();
  }

  const user = authenticateSession(request.headers.cookie);
  if (!user) return socket.destroy();

  wss.handleUpgrade(request, socket, head, (ws) => {
    ws.user = user;
    wss.emit('connection', ws, request);
  });
});

Zusätzlich muss jede Nachricht autorisiert werden. Eine einmal authentifizierte Verbindung berechtigt nicht automatisch zum Lesen jedes Chatrooms oder Ändern jedes Objekts. Payloads benötigen Schema-Validierung, Größenlimits und fachliche Berechtigungsprüfungen.

Typische WebSocket-Schwachstellen

• CSWSH:
  Fremde Origins nutzen automatisch gesendete Cookies.
• Broken Access Control:
  Objekt- oder Kanalberechtigungen fehlen pro Nachricht.
• Injection:
  Nachrichten erreichen SQL, Templates, Shells oder Browser ohne kontextgerechte Behandlung.
• Denial of Service:
  Unbegrenzte Verbindungen, Nachrichtengrößen oder Frequenzen binden Ressourcen.
• Token-Lebenszyklus:
  Abgelaufene oder widerrufene Sitzungen bleiben in langlebigen Verbindungen aktiv.

Wie werden WebSockets abgesichert?

• - Ausschließlich wss:// einsetzen und gemischte Inhalte verhindern.
• - Erlaubte Origins exakt vergleichen; null, Wildcards und bloße Suffixvergleiche vermeiden.
• - Authentifizierung beim Upgrade und Autorisierung für jede Aktion prüfen.
• - JSON-Schemas, maximale Nachrichten- und Queuegrößen, Rate Limits sowie Timeouts verwenden.
• - Logout, Rollenänderungen und Tokenablauf auch für offene Verbindungen durchsetzen.
• - Sicherheitsrelevante Ereignisse loggen, aber keine kompletten vertraulichen Nachrichten oder Tokens.

Nützliche Open-Source-Werkzeuge

OWASP ZAP besitzt einen WebSocket-Inspector und kann Nachrichten verändern und wiederholen. websocat ist ein schlanker Kommandozeilen-Client für reproduzierbare Handshakes und Nachrichten. mitmproxy unterstützt die Analyse in automatisierbaren Flows. Kein Tool ersetzt die Prüfung von Objektberechtigungen und Zustandswechseln der konkreten Anwendung.