Zum Hauptinhalt springen

10. Security Considerations (Sicherheitsüberlegungen)

Das Design des WebSocket-Protokolls berücksichtigt mehrere Sicherheitsbedrohungen. Dieses Kapitel beschreibt die wichtigsten Sicherheitsüberlegungen und empfohlene Abhilfemaßnahmen.

10.1 Non-Browser Clients (Nicht-Browser-Clients)​

Das WebSocket-Protokoll kann von jedem Client verwendet werden, nicht nur von Webbrowsern. Nicht-Browser-Clients haben nicht den Schutz der Same-Origin-Policy des Browsers.

Risiken:

  • Können Origin-Header fälschen
  • Können CORS-Beschränkungen umgehen
  • Können zahlreiche Verbindungen initiieren

Abhilfe:

  • Server müssen (MUST) zusätzliche Authentifizierung implementieren
  • Token-Validierung verwenden (z.B. JWT)
  • Rate-Limiting implementieren
  • Alle Eingabedaten validieren

10.2 Origin Considerations (Origin-Überlegungen)​

Der Origin-Header ist ein kritischer Sicherheitsmechanismus.

Empfohlene Praktiken:

  1. Origin validieren: Server sollten (SHOULD) den Origin-Header validieren
  2. Whitelist-Ansatz: Whitelists statt Blacklists verwenden
  3. Dynamische Origins: Datenbankonfiguration verwenden, falls dynamische Origins benötigt werden

Hinweis: Nicht-Browser-Clients können Origin fälschen, daher nicht allein auf Origin-Validierung verlassen.

10.3 Attacks On Infrastructure (Angriffe auf Infrastruktur)​

Cache-Poisoning-Angriffe​

WebSocket verwendet Maskierungsmechanismus zur Verhinderung von Cache-Poisoning:

  • Alle Client-zu-Server-Frames MÜSSEN maskiert sein
  • Server-zu-Client-Frames DÜRFEN NICHT maskiert sein
  • Zufällige Maskierungsschlüssel verwenden

Man-in-the-Middle-Angriffe​

Abhilfe:

  • wss:// verwenden (TLS-Verschlüsselung)
  • Serverzertifikate überprüfen
  • Certificate Pinning implementieren

10.4 Implementation-Specific Limits (Implementierungsspezifische Grenzen)​

Implementierungen sollten (SHOULD) vernünftige Grenzen setzen, um Ressourcenerschöpfungsangriffe zu verhindern.

Empfohlene Grenzen​

1. Nachrichtengrößenbegrenzung 2. Verbindungsanzahlbegrenzung 3. Nachrichtenratenbegrenzung

10.5 WebSocket Client Authentication (WebSocket-Client-Authentifizierung)​

Authentifizierungsmethoden​

  1. Cookie-Authentifizierung während des Handshakes
  2. Token in URL-Parametern
  3. Erste-Nachricht-Authentifizierung
  4. Benutzerdefinierte Handshake-Header

10.6 Connection Confidentiality and Integrity (Verbindungsvertraulichkeit und -integrität)​

TLS/SSL-Anforderungen​

Produktionsumgebungen müssen (MUST) wss:// verwenden:

✅ TLS-Vorteile:

  • Verschlüsselt alle übertragenen Daten
  • Verhindert Abhören
  • Verhindert Datenmanipulation
  • Server-Authentifizierung

❌ ws://-Risiken:

  • Klartextübertragung
  • Leicht abzufangen
  • Kann Server-Identität nicht verifizieren

10.7 Handling of Invalid Data (Umgang mit ungültigen Daten)​

Implementierungen müssen (MUST) ungültige Daten korrekt behandeln, um Sicherheitslücken zu verhindern.

Ungültiger UTF-8-Text​

Protokollverletzungen​

Wenn Protokollverletzungen erkannt werden, MUSS die Verbindung geschlossen werden.

10.8 Use of SHA-1 by the WebSocket Handshake (Verwendung von SHA-1 beim WebSocket-Handshake)​

Der Handshake verwendet den SHA-1-Hash-Algorithmus. Obwohl SHA-1 bekannte Kollisionsangriffe hat, ist er im Handshake-Kontext sicher.

Sicherheitscheckliste​

Bei der Implementierung von WebSocket-Diensten prüfen:

  • wss:// (TLS) statt ws:// verwenden
  • Origin-Header validieren
  • Authentifizierung und Autorisierung implementieren
  • Nachrichtengrößenbegrenzungen festlegen
  • Verbindungsanzahlbegrenzungen festlegen
  • Rate-Limiting implementieren
  • Alle Eingabedaten validieren
  • Protokollverletzungen korrekt behandeln
  • Sicherheitsereignisse protokollieren
  • TLS-Konfiguration regelmäßig aktualisieren
  • Abnormale Verbindungsmuster überwachen
  • Timeout-Mechanismen implementieren
Letztes Update am