Dipl.-Inform. Carsten Eilers

Für WebSocket-Verbindungen gilt das gleiche wie für alle Netzwerkverbindungen: Die Kommunikationspartner müssen ggf. authentifiziert werden, und bei der Übertragung sensitiver Daten muss die Verbindung verschlüsselt werden.

Die Authentifizierung des Clients durch den Server erfolgt bei WebSockets über normale HTTP-Authentifizierungsmechanismen wie Cookies, die HTTP-Authentifizierung oder die TLS-Authentifizierung. Für die Verschlüsselung steht TLS (Transport Layer Security) zur Verfügung. Während eine herkömmliche WebSocket-Verbindung über HTTP aufgebaut wird, wird bei einer geschützten Verbindung HTTPS verwendet. Die Unterscheidung erfolgt anhand des URI-Schemas:

• Normale Verbindung: ws://{Host}:{Port}/{Pfad zum Server}
• Geschützte Verbindung: wss://{Host}:{Port}/{Pfad zum Server}

Unabhängig von einer durchgeführten Authentifizierung und/oder Verschlüsselung der Daten gilt auch für WebSockets der altbekannte Grundsatz "Traue nie dem Client": Alle empfangenen Daten müssen vom Server geprüft werden, der Client könnte ja unter der Kontrolle eines Angreifers stehen. Und wie bei den Cross Origin Requests muss der Server gegebenenfalls anhand des 'Origin'-Headers prüfen, ob eine Verbindungsanfrage von einer erwünschten Domain stammt. Wie üblich kann ein Angreifer diesen Header auch fälschen.

Kommen wir nun zum Nachteil der WebSockets:

WebSockets und die Same Origin Policy

In manchen Beschreibungen des WebSocket APIs liest man, dass für WebSocket-Verbindungen die Same Origin Policy. gilt. Aber ist das wirklich so, und soll das überhaupt so sein? Anscheinend gibt es da einige Unklarheiten.

Das WebSocket-Protokoll

Im Standard für das WebSocket-Protokoll, RFC 6455 – The WebSocket Protocol, steht dazu unter anderem Folgendes im Abstract: "The security model used for this is the origin-based security model commonly used by web browsers." Folgendes steht in der Einführung, die aber nicht standardrelevant ist:

"1.6. Security Model

_This section is non-normative._

The WebSocket Protocol uses the origin model used by web browsers to restrict which web pages can contact a WebSocket server when the WebSocket Protocol is used from a web page. Naturally, when the WebSocket Protocol is used by a dedicated client directly (i.e., not from a web page through a web browser), the origin model is not useful, as the client can provide any arbitrary origin string."

Außerdem wird auf den RFC 6454, The Web Origin Concept, verwiesen, in dem die Same Origin Policy beschrieben wird.

In der eigentlichen Definition des Protokolls wird dann definiert, dass Webbrowser etc. beim Verbindungsaufbau einen 'Origin'-Header mitschicken müssen, unabhängige Clients das aber auch bleiben lassen können. Im Abschnitt 10, "Security Considerations", wird entsprechend auch darauf hingewiesen, dass der 'Origin'-Header nur vor Angriffen von bösartigen JavaScript-Code in einem Webbrowser schützen kann (da der Header dann vom Browser und nicht vom JavaScript-Code geschickt wird) und die Server davon ausgehen sollten, dass der 'Origin'-Header unter Umständen gefälscht sein kann. Da auch eigenständige WebSocket-Clients den Header senden können, ist er nicht einmal ein Hinweis darauf, dass die Verbindungsanfrage von einem Webbrowser stammt.

Zwischenfazit

Daraus ergibt sich zusammenfassend, dass die Webbrowser zwar einen 'Origin'-Header an den Server senden müssen, die Same Origin Policy aber nicht anzuwenden ist. Denn dann wäre ja der 'Origin'-Header obsolet, die Verbindungsanfrage würde vom Browser sowieso nur abgeschickt, wenn sie zur Origin des aufbauenden JavaScript-Codes ginge.

Das WebSocket API

Betrachten wir nun die Definition des WebSocket API. Auch darin gibt es keinen Hinweis auf die Same Origin Policy. Würde sie gelten, müsste in der API-Definition ja angegeben sein, dass über WebSockets nur Verbindungen zur Origin des JavaScript-Codes möglich sind, und auch eine entsprechende Fehlermeldung wäre angebracht. Auch laut Definition des WebSocket API gilt die Same Origin Policy also nicht.

Zwischenfazit

Auch die Definition des WebSocket API verlangt nicht die Einhaltung der Same Origin Policy. Ganz im Gegenteil: Alles deutet darauf hin, dass sie gerade nicht gilt. Auch wenn das so ausdrücklich nirgends ausgesagt wird.

Der praktische Einsatz

Kommen wir zu guter Letzt zum praktischen Einsatz des WebSocket API am Beispiel des Portscanners JS-Recon der Attack and Defense Labs und dessen Demo: Der baut über die WebSockets Verbindungen zu beliebigen IP-Adressen auf, verstößt also massiv gegen die Same Origin Policy.

Fazit

Womit festzustellen bleibt, dass die Anwendung der Same Origin Policy weder vom Protokoll selbst noch vom API verlangt wird. Auch in der Praxis wird sie nicht beachtet.

"WebSockets considered harmful!"

Was letztendlich darauf hinaus läuft, dass JavaScript-Code WebSocket-Verbindungen zu beliebigen Servern aufbauen kann. Es ist Aufgabe der Server, ggf. auf unerwünschte Verbindungsanfragen entsprechend zu reagieren.

Das gilt auch dann, wenn der JavaScript-Code beispielsweise über eine XSS-Schwachstelle eingeschleust wurde. In diese Fall könnte der Code dann eine Verbindung zum Server des Angreifers aufbauen (der diese natürlich akzeptieren würde) und dem Angreifer darüber den Zugriff auf den Browser des Opfers erlauben. Wie das funktioniert, zeigt "Waldo", ein Proof-of-Concept der Qualys Security Labs, der eine Backdoor implementiert.

WebSockets unterlaufen also effektiv die Same Origin Policy. Zwar kann JavaScript-Code nicht auf die Inhalte anderer Origins zugreifen, aber in eine Webseite eingeschleuster JavaScript-Code kann eine Verbindung zu jedem beliebigen (WebSocket-)Server aufbauen. Das kann ja wohl kaum im Sinne des Erfinders sein. Zumindest nicht in der des Erfinders der Same Origin Policy.

Und Gegen- bzw. Schutzmaßnahmen gibt es nicht, es gilt die alte Atari-Ausrede "It's not a bug, it's a feature". Sie können nur WebSockets im Webbrowser generell ausschalten, sofern Sie sie nicht benötigen (und eine Anleitung für ihren Browser finden). Die werde ich hier noch nachtragen.

Mehr zum sicheren Einsatz von WebSockets erfahren Sie in meinem auf deutsch und englisch erhältlichen eBook "HTML5 Security". In der nächsten Folge geht es um die Sicherheit der postMessage()-Methode.

Übersicht über alle Artikel zum Thema

HTML5 Security - Eine Einführung

HTML5 Security - SVG und Resident XSS

HTML5 Security - Formulare auf Abwegen

HTML5 Security - Gift für den Application Cache

HTML5 Security - Der Local Storage

HTML5 Security - Die SQL-Datenbank

HTML5 Security - Cross Origin Requests

HTML5 Security - Gefährliche WebSockets

HTML5 Security - postMessage() sicher nutzen