WebSockets ist eine HTML5-Funktion, die einen Vollduplex-Kanal für eine einzelne TCP-Verbindung bereitstellt. Seine kontinuierliche Verbindungsfunktion ermöglicht die Erstellung von Echtzeitanwendungen im B/S-Modus. Websockets werden häufig in WEB-Anwendungen mit Chat-Funktionen verwendet.
Das folgende Bild veranschaulicht sehr genau die Websockets, die bei einem APT-Angriff verwendet werden:
Populärwissenschaft:
Same-Origin-Strategie ( Same Origin Richtlinie): Gleicher Ursprung bedeutet, dass der Domänenname, das Protokoll und der Port gleich sind. Das heißt, der Browser überprüft verschiedene Registerkarten desselben Browsers und Skripte mit demselben Ursprung können auf mehreren Registerkarten ausgeführt werden.
Ursprungsfeld: Der Browser fügt beim Senden einer POST-Anfrage möglicherweise ein Ursprungsfeld hinzu. Dieses Ursprungsfeld wird hauptsächlich verwendet, um zu identifizieren, wo die ursprüngliche Anfrage initiiert wurde. Wenn der Browser den Ursprungsort nicht ermitteln kann, ist der Wert des Feldes „Ursprung“ in der gesendeten Anfrage leer.
IronWASP: Eine Open-Source-WEB-Testplattform, auf der Benutzer Sicherheitsscans anpassen und das Plug-in-System mithilfe von Python/Ruby definieren können. Eine entsprechende Einführung finden Sie unter: http://www.php.cn/
ZAP (Zed Attack Proxy): Es handelt sich um ein Penetrationstest-Framework, das verschiedene Tools integriert und Schwachstellen in WEB-Anwendungen entdecken kann Einführung, siehe: http://www.php.cn/
WebSocket-Sicherheitsbewertung
Kürzlich haben wir eine Sicherheitsbewertung einer WEB-Anwendung mit komplexen Menüoptionen und Funktionen durchgeführt. Die meisten Vorgänge in dieser Anwendung verwenden Web-Sockets, was bedeutet, dass die meisten ihrer Aktionen nicht im HTTP-Proxy-Protokoll aufgezeichnet werden.
Nachdem wir die Homepage geöffnet haben, lädt die Website zunächst eine statische Webseite mit JS-Skripten und CSS-Dateien. Danach wechselt die gesamte Kommunikationsinteraktion in den Websockets-Modus und es wird eine Websocket-Verbindung zwischen dem Browser und dem Server hergestellt, um alle sichtbaren HTML-Ressourcen auf der Website zu laden. Wenn Sie auf einen Link klicken oder ein Formular absenden, sendet der Browser einige WebSocket-Nachrichten an den Server. Nachdem der Server diese Nachrichten verarbeitet hat, gibt er eine Rückmeldung über WebSocket und dann zeigt der Client-Browser den neuen HTML-Inhalt an.
Zu diesem Zeitpunkt, wenn Websocket-Nachrichten interagieren, ist das Kommunikationsvolumen sehr groß. Es gibt jede Sekunde eine Interaktion von Heartbeat-Erkennungspaketen zwischen ihnen. Die vorhandenen Tools entsprachen jedoch nicht meinen Anforderungen, sodass ich IronWASP ein Websocket-Nachrichtenanalysegerät und einen WebSocket-Client hinzufügen musste, damit es Websockets identifizieren und versuchen konnte, seine Schwachstellen auszuschließen. Mehr darüber erfahren Sie hier.
Beim Testen dieser Anwendung habe ich festgestellt, dass sie eine WebSocket-Cross-Site-WebSocket-Hijacking-Schwachstelle aufweist (entwickelt von Christian Schneider). Selbstverständlich werde ich die Auswirkungen dieser Sicherheitslücke erläutern, bevor ich Ihnen die Testmethode vorstelle. Bevor wir verwandte Websockets-Anwendungen testen, müssen wir zunächst Vorbereitungen treffen.
Vorbereitung eines WebSocket-Cross-Site-Hijacking-Schwachstellenexperiments
Jeder sollte verstehen, dass die Same Origin Policy (SOP) nicht über den Browser auf WebSockets durchgesetzt wird (unter demselben Browser, SSL-geschützte Seiten, lässt kein Nicht-SSL-WebSocket zu. Die von uns getestete Anwendung verwendet HTTP-Cookies als Sitzungsauthentifizierung. Die von WebSocket über den Browser gesendeten Nachrichten verfügen nicht über eine Sitzungs-ID oder zufällige Parameter.
Wenn sich ein Benutzer auf diese Weise bei einer anfälligen WEB-Anwendung anmeldet und dann http://www.php.cn/ (die Website des Angreifers) im selben Browser öffnet, http://www.php .cn/ kann versuchen, über diese anfällige Anwendung eine WebSocket-Verbindung mit dem Server der Anwendung herzustellen und dann ein Anforderungspaket mit einer gültigen Authentifizierungssitzungs-ID über den Browser zu senden. Daher verfügt die von der Website des Angreifers hergestellte WebSocket-Verbindung über dieselben Berechtigungen wie die Anwendung selbst.
Da die gesamte Anwendung auf WebSockets läuft, ist die Übernahme von WebSockets gleichbedeutend mit der Übernahme der Sitzung des Benutzers. Diese Sicherheitslücke ist also im Wesentlichen die gleiche wie eine gespeicherte Cross-Site-Scripting-Sicherheitslücke.
Wenn Sie denken, dass das schlecht ist, werden Sie dann noch mehr überrascht sein, wenn Sie hören, dass WebSocket-Cross-Site-Scripting in einigen Fällen sogar eine Remotecodeausführung auf dem System des Benutzers erreichen kann? Sehen Sie sich das IPython Notebook-Beispiel an.
Vor dem Testen müssen Sie zunächst bestätigen, ob WebSockets in der Anwendung vorhanden sind. Glücklicherweise ist dies sehr einfach. Sie müssen nur die folgenden drei Punkte kennen:
1. WebSocket-URL-Verbindungen beginnen im Allgemeinen mit ws:// oder wss://.
2. Der Origin-Header der Verbindung muss erkannt werden. Bei der Webseite kann es sich um einen über das Origin-Feld eingerichteten WebSocket-Link handeln.
3. Anhand der zwischen dem Browser und dem Server gesendeten Nachrichten können wir die Eigenschaften gewöhnlicher WebSocket-Verbindungen überprüfen.
Das Bild unten zeigt Ihnen: wie Sie den Wert des Origin-Felds und den URL-Wert von WebSocket über das IronWASP-Protokoll abrufen.
Sobald Sie über diese Informationen verfügen, können Sie einige spezielle Methoden verwenden, um standortübergreifende WebSocket-Hijacking-Schwachstellen zu erkennen. Ich werde hier drei einfache Beispiele nennen:
Verwenden Sie Proxy-Software (z. B. Burpsuite):
Hier muss erwähnt werden, dass burpsuite WebSockets-Nachrichten erfassen und aufzeichnen kann. ZAP und IronWASP sind die mir bekannte Software, die Websocket-Anfragen wiedergeben kann.
In burpsuite können wir WebSockets-Nachrichten nicht wiedergeben, aber wir können unter bestimmten Bedingungen dennoch erkennen, ob das WebSocket-Handshake-Paket erfolgreich ist. Zum Testen müssen wir die Websocket-Upgrade-Anforderungspakete analysieren: Sie werden über http oder https gesendet und können daher wiedergegeben werden.
Der folgende Screenshot ist eine Aufzeichnung des Burpsuite-Replayers (Registerkarte „Wiederholen“), die die effektive Anfrage und Antwort der Websocket-Verbindung zeigt:
Zum Testen Für diese Schwachstelle müssen wir ein weiteres Anforderungspaket mit einem neu erstellten Origin-Header senden. Wenn in unserem Antwortpaket die Markierung „101 Web Socket Protocol Handshake“ vorhanden ist, bedeutet dies, dass der WebSocket erfolgreich eingerichtet wurde.
Wenn die Verbindung nicht erfolgreich hergestellt werden kann, bedeutet dies, dass die Anwendung diese Schwachstelle nicht aufweist, da sie externe WebSocket-Verbindungen ablehnt. Nach erfolgreicher Einrichtung können wir mit dem nächsten Testschritt beginnen, um festzustellen, ob die Anwendung eine WebSocket-Schwachstelle für Cross-Site-Hijacking aufweist. Es muss hier erklärt werden: Auch wenn die Verbindung hergestellt wurde, muss sie wie eine normale Verbindung von Origin sein. Erst nachdem bestätigt wurde, dass der Server auf die WebSocket-Nachricht antwortet, kann nachgewiesen werden, dass die Anwendung anfällig ist. Dies liegt daran, dass Entwickler möglicherweise gleichzeitig die Ursprungserkennung und die Authentifizierung der Verbindungsautorität aktivieren. Daher kann in unseren Experimenten die folgende Situation auftreten: Die hergestellte Verbindung kann für immer aufrechterhalten werden, aber Ursprünge mit externen Quellen bestehen die Authentifizierung nicht.
ZAP kann WebSocket-Nachrichten wiedergeben, aber soweit ich weiß, ändert es den Origin-Header nicht. Die unten vorgestellte Methode kann Ihnen populärwissenschaftliche Informationen darüber liefern, wie Sie durch CSWSH (WebSocket Cross-Site Hijacking) mehr Dinge erreichen können.
Verwenden Sie das Online-Testtool für WebSocket-Cross-Site-Hijacking
Öffnen Sie die WEB-Anwendung, die getestet werden muss, und melden Sie sich an. Öffnen Sie dann einen neuen Tab im selben Browser und besuchen Sie http:/ /www.php .cn/ (simulierte Hacker-Website), geben Sie die URL-Adresse des WebSocket ein und klicken Sie dann auf der Webseite auf die Schaltfläche „Verbinden“. Sobald die Verbindung hergestellt ist, können Sie über diese Seite Nachrichten an den WebSocket-Server senden. Wir müssen die von der gültigen Sitzung gesendeten Nachrichten erneut abspielen und dann das Antwortpaket des Servers überprüfen.
Wenn die Antwort vom Server mit dem normalen Paket übereinstimmt, das von der vorherigen gültigen Sitzung gesendet wurde, bedeutet dies, dass die Anwendung möglicherweise eine WebSocket-Schwachstelle für Cross-Site-Hijacking aufweist.
Verwenden Sie IronWASP
IronWASP kann mehr und bietet automatisierte Skripte für selbst die grundlegendsten Erkennungsuntersuchungen.
Verwenden Sie den WebSocket-Client von IronWASP
Der in der oben genannten Methode zum Testen von Origin verwendete Server ist http://www.php.cn/. Wenn Sie den Origin-Wert flexibler festlegen möchten, sind Sie hier genau richtig kann die Client-Funktionalität von IronWASP nutzen. Sie können den Origin-Wert anpassen, um WebSocket-Verbindungen zu testen.
Client-Funktionen können unter folgenden Umständen verwendet werden:
1. Die Anwendung ermöglicht WebSocket-Verbindungen von Open Origin
2. Die Die Anwendung ermöglicht Ursprungsfeldwerte von Localhost und Intranet-IP
Dieser Ansatz soll Entwicklern und internen Tests von Anwendungen erleichtern. Mithilfe des IronWASP-Clients können Sie testen, ob die Intranet-IP oder localhost als Ursprung wirksam werden kann. Wenn Sie können, können Sie diese Schwachstelle vielleicht mithilfe einiger Tricks in einer realen Umgebung ausnutzen. Wenn eine Anwendung beispielsweise http://127.0.0.1:8080 als Ursprungsfeld zulässt, können wir Folgendes tun: Wenn auf dem lokalen Port 8080 zufällig eine WEB-Anwendung ausgeführt wird und diese über eine Cross-Site verfügt Skript-Schwachstelle. Wenn diese Bedingungen erfüllt sind, kann der Hacker zunächst einen standortübergreifenden Angriff auf die WEB-Anwendung durchführen und dann eine WebSocket-Verbindung zum Zielanwendungsserver herstellen:
Verwenden Sie IronWASPs Automatisierte Erkennung der WebSocket-API
Wenn Sie zum Testen des Origin-Headers Localhost oder Intranet-IP verwenden müssen, erleichtert die Verwendung von Client-Skripten für die automatische Erkennung Ihre Aktion. IronWASP ermöglicht Ihnen die Implementierung benutzerdefinierter Skripte mit Python oder Ruby.
Das folgende Skript kann die im Origin-Header ausgefüllte Intranet-IP-Adresse selbstständig erkennen und testen, ob der Server sie erkennt:
import clr
clr.AddReference("WebsocketClient.exe")
from WebsocketClient import *
def check_conn(origin):
print "Testing origin - " + origin
ws = SyncWebsockClient()
ws.Connect("ws://tatgetapp.com/ws", origin, "SessionID=KSDI2923EWE9DJSDS01212")
ws.Send("first message to send")
msg = ws.Read()
ws.Close()
if msg == "message that is part of valid session":
print "Connection successful!!"
return True
else:
return False
def check_nw():
for nws in ["192.168.0.0/16", "172.16.0.0/12", "10.0.0.0/8"]:
for ip in Tools.NwToIp(nws):
if check_conn("http://" + ip):
break
check_nw()Nach dem Login kopieren
Das obige ist der detaillierte Inhalt vonDetaillierte Einführung zur vollständigen Kontrolle der Sitzung? Schauen wir uns die detaillierte Erklärung des grafischen Codes des WebSocket-Cross-Site-Hijackings an. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
