3. Secure Websockets

🔐 Sicherer Einsatz von WebSockets

1. wss:// verwenden (WebSockets über TLS)

• Was ist das?

  • ws:// ist unverschlüsselt (wie HTTP).
  • wss:// ist verschlüsselt (wie HTTPS).

• Warum wichtig?

  • Schützt vor Man-in-the-Middle-Angriffen (z. B. Abhören im WLAN oder durch kompromittierte Router).
  • Ohne TLS könnten Angreifer Nachrichten oder sogar den Handshake manipulieren.

• Praxis:

  • Server mit TLS-Zertifikat betreiben.
  • Client immer nur wss://-URLs verwenden.

---

2. WebSocket-URL hardcoden – keine Benutzereingaben übernehmen

• Problem:

  • Wenn der Client die URL dynamisch z. B. aus Query-Parametern oder Cookies zusammenbaut, könnte ein Angreifer die URL manipulieren.

  • Beispiel:

    var ws = new WebSocket("wss://" + location.search.split("=")[1]); → Angreifer hängt ?url=evil.com an → Verbindung geht zu seiner Domain.

• Warum wichtig?

  • Damit verhinderst du, dass Angreifer deinen Client auf fremde, manipulierte WebSockets umleiten.

• Praxis:

  • URL fest im Code oder in einer sicheren Config-Datei definieren.
  • Keine Benutzereingaben oder unsichere Quellen für die Endpoint-URL zulassen.

---

3. Handshake gegen CSRF absichern (Schutz vor Cross-Site WebSocket Hijacking)

• Problem:

  • Standardmäßig hängen Browser beim Handshake automatisch die Session-Cookies an.
  • Ohne Schutz kann ein Angreifer über eine eigene Webseite eine Verbindung im Kontext des Opfers aufbauen.

• Lösung:

  • Wie bei normalen HTTP-Anfragen → CSRF-Token einbauen, die nur die legitime Anwendung kennen kann.
  • Origin-Header streng prüfen → Verbindungen nur von eigenen Domains akzeptieren.

• Praxis:

  • Beispiel:
    • Client holt sich erst ein CSRF-Token per HTTPS.
    • Schickt es zusätzlich im Handshake (z. B. als URL-Parameter oder Custom-Header).
    • Server prüft: passt Token zu Session? Wenn nein → Verbindung ablehnen.

---

4. Alle Daten als untrusted behandeln (beidseitig!)

• Problem:

  • WebSocket-Kommunikation ist bidirektional.
  • Server bekommt Daten vom Client → kann Angriffe enthalten (SQL Injection, Command Injection).
  • Client bekommt Daten vom Server → könnte XSS oder Script Injection enthalten.

• Warum wichtig?

  • WebSockets sind ein Transportweg – alle bekannten Input-basierenden Schwachstellen können hier auftreten.

• Praxis:

  • Server:

    • Eingaben validieren, escapen, Parameterized Queries nutzen.

  • Client:

    • Daten niemals ungefiltert mit .innerHTML rendern.
    • Immer escapen oder DOM-sicher einfügen (.textContent).

✅ Zusammenfassung

Um WebSockets sicher zu betreiben: 1. Immer verschlüsseln (wss://). 2. Endpoint-URL festlegen – keine dynamischen Quellen. 3. CSRF-Schutz im Handshake → Token + Origin-Prüfung. 4. Datenhygiene → Eingaben und Ausgaben strikt validieren und escapen.