Introduction détaillée sur la façon de contrôler entièrement la session ? Examinons l'explication détaillée du code graphique du piratage intersite WebSocket.

WebSockets est une fonctionnalité HTML5 qui fournit un canal full-duplex pour une seule connexion TCP. Sa fonction de connexion continue permet de construire des applications temps réel en mode B/S. Les Websockets sont souvent utilisés dans les applications WEB dotées de fonctions de chat.

L'image suivante illustre de très près les websockets utilisés dans une attaque APT :

Science populaire :

Stratégie de même origine (Même origine politique) : La même origine signifie que le nom de domaine, le protocole et le port sont les mêmes, c'est-à-dire que le navigateur vérifiera différents onglets du même navigateur et que les scripts avec la même origine peuvent être exécutés dans tous les onglets.

Champ Origine : Le navigateur peut ajouter un champ Origine lors de l'envoi d'une requête POST. Ce champ Origine est principalement utilisé pour identifier l'endroit où la requête initiale a été initiée. Si le navigateur ne parvient pas à déterminer où se trouve l'origine, la valeur du champ Origine dans la requête envoyée sera vide.

IronWASP : Une plateforme de test WEB open source où les utilisateurs peuvent personnaliser les analyses de sécurité et définir le système de plug-in à l'aide de python/ruby. Pour une introduction connexe, voir : //m.sbmmt.com/

ZAP (Zed Attack Proxy) : il s'agit d'un cadre de test d'intrusion qui intègre divers outils et peut découvrir des vulnérabilités dans les applications WEB. introduction, voir : //m.sbmmt.com/

Évaluation de la sécurité WebSocket

Récemment, nous avons mené une évaluation de la sécurité sur une application WEB avec des options et des fonctions de menu complexes. La plupart des opérations de cette application utilisent des web-sockets, ce qui signifie que la plupart de ses actions ne seront pas enregistrées dans le journal du proxy http.

Tout d'abord, après avoir ouvert la page d'accueil, le site Web chargera une page Web statique avec des scripts JS et des fichiers CSS. Après cela, toute l'interaction de communication passera en mode Websockets et une connexion Websocket sera établie entre le navigateur et le serveur pour charger toutes les ressources HTML visibles sur le site Web. Lorsque vous cliquez sur un lien ou soumettez un formulaire, le navigateur envoie des messages WebSocket au serveur. Une fois que le serveur a traité ces messages, il fera un retour via WebSocket, puis le navigateur client affichera le nouveau contenu HTML.

À l'heure actuelle, lorsque les messages Websocket interagissent, la quantité de communication est très énorme. Il y a une interaction de paquets de détection de rythme cardiaque entre eux chaque seconde. Cependant, les outils existants ne répondaient pas à mes besoins, j'ai donc dû ajouter un dispositif d'analyse de messages Websocket et un client WebSocket à IronWASP afin qu'il puisse identifier les Websockets et tenter de contourner ses vulnérabilités. Vous pouvez en savoir plus ici.

En testant cette application, j'ai découvert qu'elle présentait une vulnérabilité de WebSocket Hijacking intersites WebSocket (initiée par Christian Schneider). Bien entendu, je vous expliquerai l’impact de cette vulnérabilité avant de vous présenter la méthode de test. Avant de tester les applications Websockets associées, nous devons d'abord nous préparer.

Préparation de l'expérience de vulnérabilité de piratage intersites WebSocket

Tout le monde doit comprendre que la politique de même origine (SOP) ne sera pas appliquée aux websockets via le navigateur (sous le même navigateur, pages protégées SSL, ne permettra pas le passage de WebSocket non SSL). L'application que nous avons testée utilise des cookies http comme authentification de session. Les messages envoyés par WebSocket via le navigateur n'auront pas d'ID de session ni de paramètres aléatoires.

De cette façon, si un utilisateur se connecte à une application WEB vulnérable puis ouvre //m.sbmmt.com/ (le site de l'attaquant) dans le même navigateur, http:/ /www.php .cn/ peut essayer d'établir une connexion WebSocket avec le serveur de l'application via cette application vulnérable, puis envoyer un paquet de requête avec un ID de session d'authentification valide via le navigateur. Par conséquent, la connexion WebSocket établie par le site Web de l'attaquant aura les mêmes autorisations que l'application elle-même.

Étant donné que l'ensemble de l'application fonctionne sur des websockets, pirater des WebSockets équivaut à pirater la session de l'utilisateur. Cette vulnérabilité est donc essentiellement la même qu’une vulnérabilité de script intersite stockée.

Si vous pensez que c'est mauvais, serez-vous encore plus surpris lorsque vous apprendrez que dans certains cas, les scripts intersites WebSocket peuvent même permettre l'exécution de code à distance sur le système de l'utilisateur ? Voir l'exemple IPython Notebook ?

Avant de tester, la première chose à faire est de confirmer si les WebSockets existent dans l'application. Heureusement, cela est très simple. Il vous suffit de connaître les trois points suivants :

1. Les connexions URL WebSocket commencent généralement par ws:// ou wss://.

2. L'en-tête Origin de la connexion doit être détecté. La page Web peut être un lien WebSocket établi via le champ Origin.

3. A partir des messages envoyés entre le navigateur et le serveur, nous pouvons vérifier les caractéristiques des connexions WebSocket ordinaires.

L'image ci-dessous vous montrera : comment obtenir la valeur du champ Origine et la valeur de l'URL de WebSocket via le journal IronWASP.

Une fois que vous disposez de ces informations, vous pouvez utiliser des méthodes spéciales pour détecter les vulnérabilités de piratage WebSocket intersites. Je vais donner ici trois exemples simples :

Utilisez un logiciel proxy (tel que Burpsuite) :

Il faut mentionner ici que burpsuite peut capturer et enregistrer des messages WebSockets. ZAP et IronWASP sont les logiciels que je connais qui peuvent rejouer les requêtes Websocket.

Dans burpsuite, nous ne pouvons pas relire les messages websockets, mais nous pouvons toujours détecter si le package de prise de contact WebSocket réussit dans des conditions limitées. Pour les tests, nous devons analyser les paquets de demande de mise à niveau du websocket : ils sont envoyés via http ou https et peuvent donc être relus.

La capture d'écran suivante est un enregistrement du replayer burpsuite (onglet Répéter), qui montre la demande et la réponse effectives de la connexion websocket :

Pour les tests Pour cette vulnérabilité, nous devons envoyer un autre paquet de requête avec un en-tête Origin refait. S'il y a une marque « 101 Web Socket Protocol Handshake » dans notre paquet de réponse, cela signifie que le WebSocket a été établi avec succès.

Si la connexion n'est pas établie avec succès, cela signifie que l'application ne présente pas cette vulnérabilité car elle rejettera les connexions WebSocket externes. Une fois l'établissement réussi, nous pouvons commencer l'étape suivante de test pour voir si l'application présente une vulnérabilité de piratage intersite WebSocket. Cela doit être expliqué ici : même si la connexion a été établie, elle doit être comme une connexion normale depuis Origin. Ce n'est qu'après avoir confirmé que le serveur répond au message WebSocket que l'application peut être prouvée comme vulnérable. En effet, les développeurs peuvent activer simultanément la détection d'origine et l'authentification de l'autorité de connexion. Par conséquent, la situation suivante peut se produire dans nos expériences : la connexion établie peut être maintenue pour toujours, mais Origins avec des sources externes ne passera pas l'authentification.

ZAP peut relire les messages WebSocket, mais d'après ce que je comprends, cela ne modifie pas l'en-tête Origin. La méthode présentée ci-dessous peut vous donner des informations scientifiques populaires sur la façon d'obtenir plus de choses via CSWSH (WebSocket cross-site hijacking).

Utilisez l'outil de test en ligne pour le piratage intersite WebSocket

Ouvrez l'application WEB qui doit être testée et connectez-vous, puis ouvrez un nouvel onglet dans le même navigateur et visitez http:/ /www.php .cn/ (site Web de pirate informatique simulé), entrez l'adresse URL du WebSocket, puis cliquez sur le bouton Connecter de la page Web. Une fois la connexion établie, vous pouvez envoyer des messages au serveur WebSocket via cette page. Nous devons rejouer les messages envoyés par la session valide, puis vérifier le paquet de réponse du serveur.

Si la réponse du serveur est la même que le paquet normal envoyé par la session valide précédente, cela signifie que l'application peut présenter une vulnérabilité de piratage intersite WebSocket.

Utiliser IronWASP

IronWASP peut faire plus, en fournissant des scripts automatisés, même pour les examens de détection les plus élémentaires.

Utilisez le client WebSocket d'IronWASP

Le serveur utilisé dans la méthode de test d'Origin ci-dessus est //m.sbmmt.com/, si vous souhaitez définir la valeur Origin de manière plus flexible, vous peut utiliser la fonctionnalité client d'IronWASP. Il vous permet de personnaliser la valeur Origin pour tester les connexions WebSocket.

Les fonctions client peuvent être utilisées dans les circonstances suivantes :

1. L'application autorise les connexions WebSocket depuis Open Origin

2. Le l'application autorise les valeurs du champ Origin à partir de l'adresse IP de l'hôte local et de l'intranet

Cette approche vise à faciliter les développeurs et les tests internes des applications. En utilisant le client IronWASP, vous pouvez essayer si l'adresse IP intranet ou l'hôte local comme origine peut prendre effet. Si vous le pouvez, vous pouvez peut-être utiliser quelques astuces pour exploiter cette vulnérabilité dans un environnement réel. Par exemple, si une application autorise http://127.0.0.1:8080 comme champ Origine, alors nous pouvons faire ceci : Si la victime dispose d'une application WEB exécutée sur le port local 8080 et qu'elle dispose d'une connexion intersite. vulnérabilité de script. Si ces conditions sont remplies, le hacker peut dans un premier temps mener une attaque cross-site sur l'application WEB, puis établir une connexion WebSocket vers le serveur d'application cible :

Utiliser l'outil IronWASP API WebSocket Détection automatisée

Si vous devez utiliser l'adresse IP localhost ou intranet pour tester l'en-tête Origin, l'utilisation de scripts clients pour la détection automatisée facilitera votre action. IronWASP vous permet d'implémenter des scripts personnalisés à l'aide de Python ou Ruby.

Le script suivant peut détecter indépendamment l'adresse IP intranet renseignée dans l'en-tête Origin et tester si le serveur la reconnaît :

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()

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!