La formation d'attaque XSS. Vulnérabilité XSS - Qu'est-ce que c'est? Exemples de vulnérabilités XSS. Données de formulaires remplis
Script d'intersype (XSS) est une vulnérabilité qui consiste à mettre en œuvre le code exécutable du côté client (JavaScript) de la page Web que d'autres utilisateurs sont apportés.
La vulnérabilité découle en raison d'un filtrage insuffisant des données, que l'utilisateur envoie à insérer dans une page Web. Il est beaucoup plus facile de comprendre exemple spécifique. Rappelez-vous tout livre d'or - Ce sont des programmes destinés à accepter des données de l'utilisateur et de l'affichage ultérieur. Imaginez que le livre d'or ne vérifie aucune façon et ne filtre pas les données entrées, mais les affiche simplement.
Vous pouvez goûter votre propre script plus simple (Il n'y a rien de plus facile que d'écrire de mauvais scripts sur PHP - cela est très impliqué dans cela). Mais il y a déjà beaucoup d'options prêtes à l'emploi. Par exemple, je propose de commencer une connaissance avec Dojo et Owasp Mutillidae II. Il y a un exemple similaire. Dans l'environnement de Dojo autonome, allez au navigateur par référence: http: //localhost/mutillidae/index.php? Page \u003d Add-à-votre-blog.php
Si une personne des utilisateurs est entrée:
Cette page Web affichera:
Hey! Comme votre site.
Et si l'utilisateur entre dans ceci:
Hey! Comme votre site.
Qui sera affiché comme ceci:
Les navigateurs gardent un ensemble de cookies grand nombre des sites. Chaque site peut obtenir des cookies seulement sauvegardés. Par exemple, le site Web d'exemple.com a conservé des cookies dans votre navigateur. Vous êtes le crash sur le site d'un autre.com, ce site (scripts client et serveur) ne peut pas accéder aux cookies que le site Web d'Exemple.com a été enregistré.
Si le site Exemple.com est vulnérable à XSS, cela signifie que nous pouvons en une manière ou une autre pour implémenter le code JavaScript dans celui-ci et ce code sera exécuté pour le compte de l'exemple de site.com! Ceux. Ce code recevra, par exemple, l'accès à l'exemple de site de Cookis.
Je pense que tout le monde se souvient que JavaScript est exécuté dans les navigateurs d'utilisateurs, c'est-à-dire Avec la présence de XSS, intégré code malicieux Accède aux données de l'utilisateur qui a ouvert la page du site Web.
Le code incorporé est capable de tout ce que JavaScript peut, à savoir:
- accès aux cookies du site Vue
- peut apporter des changements dans apparence pages
- accès au tampon d'échange
- peut implémenter des programmes sur JavaScript, par exemple, Ki-Loggers (intercepteurs de touches poussées)
- touchez sur le boeuf.
- et etc.
L'exemple le plus simple Avec Cookiz:
En fait, alerte. Utilisé uniquement pour détecter les XSS. Real Malware Libre des charges cachées. Il est caché de se lier à un serveur d'intrusion distant et transmet des données volées dessus.
Types de XSS.
La chose la plus importante est que vous devez comprendre les types de XSS ce qu'ils se produisent:
- Stocké (constant)
- Réfléchie (non permanent)
Exemple de permanent:
- Un attaquant a introduit un message spécialement formé au livre d'or (commentaire, message du forum, profilé) qui est stocké sur le serveur, chargé à partir du serveur chaque fois que les utilisateurs demandent l'affichage de cette page.
- L'attaquant a reçu l'accès aux données du serveur, par exemple via une injection SQL et introduit aux données appelées utilisées pour le code JavaScript malveillant (avec ki-enregistreurs ou avec du bœuf).
Échantillon de non-permanent:
- Le site a une recherche, qui, avec les résultats de la recherche, montre quelque chose comme "que vous recherchiez: [String de recherche]", tandis que les données ne sont pas filtrées correctement. Étant donné qu'une telle page ne s'affiche que pour avoir un lien avec elle, tandis que l'attaquant n'enverra pas le lien vers d'autres utilisateurs du site, l'attaque ne fonctionnera pas. Au lieu d'envoyer une référence à la victime, vous pouvez utiliser le placement d'un script malveillant sur un site neutre visitant la victime.
Toujours se démarquer (certains comme une sorte de vulnérabilités XSS non permanente, certains disent que cette espèce peut être une variété de XSS constants):
- Modèle DOM
Caractéristiques XSS basées sur DOM
Si vous êtes tout à fait simple, le code malveillant du code XSS non permanent ne peut être vu si vous ouvrez le code HTML. Par exemple, le lien est formé de cette manière:
Http://example.com/search.php?q\u003d "/\u003e
Et lors de l'ouverture du code HTML d'origine, nous voyons quelque chose comme ceci:
Et DOM XSS change la structure DOM formée dans le navigateur à la volée et voir le code malveillant que nous ne puissions que lors de la visualisation de la structure DOM formée. HTML ne change pas. Prenons ce code par exemple:
Que dans le navigateur, nous verrons:
Code source de page:
Formulons l'adresse comme suit:
Http: //localhost/tests/xss/dom_xss.html#input\u003dtokenalex.;
Maintenant, la page ressemble à ceci:
Mais regardons la source HTML:
Il n'y avait absolument rien changé. À propos de cela, j'ai dit, nous devons regarder le document Dom Structure pour identifier le code malveillant:
Voici un prototype de travail XSS, pour une attaque réelle, nous avons besoin d'une charge utile plus complexe impossible en raison du fait que l'application cesse de lire immédiatement après un point avec une virgule et quelque chose du genre alerte (1); alerte (2) N'est plus possible. Cependant, grâce à unescape () Dans les données retournées, nous pouvons utiliser la charge utile comme celle-ci:
Http: //localhost/tests/xss/dom_xss.html#input\u003dtokenalex.;
Où nous avons remplacé le symbole ; Sur l'équivalent codé dans l'URI!
Nous pouvons maintenant écrire un logiciel malveillant de JavaScript et faire un lien pour envoyer la victime, comme cela est fait pour les scripts standard non permanents.
Auditeur XSS
DANS Google Chrome. (ainsi que dans l'opéra, qui utilise maintenant le moteur Google Chrome), j'attendais une telle surprise:
dOM_XSS.HTML: 30 L'Auditeur XSS a refusé d'exécuter un script dans "http: //localhost/tests/xss/dom_xss.htm#input\u003dToken \u003cscript\u003e alerte (1)"Parce que son code source a été trouvé dans la demande. L'auditeur a été activé en tant que serveur envoyé ni une en-tête" X-XSS-Protection "Ni" Content-Security-Policy ".
Ceux. Maintenant, dans le navigateur, il y a un auditeur XSS qui essaiera de prévenir les XSS. Il n'y a pas de cette fonctionnalité de ce type dans Firefox, mais je pense que c'est une question de temps. Si la mise en œuvre des navigateurs réussira, nous pouvons alors parler d'une difficulté significative d'utiliser des XSS.
Il est utile de se rappeler que navigateurs modernes Prenez des mesures pour limiter le niveau de fonctionnement des problèmes tels que XSS non permanents et basé sur DOM XSS. Y compris qu'il est nécessaire de rappeler lorsque vous testez des sites Web à l'aide d'un navigateur - il se peut que l'application Web soit vulnérable, mais vous ne voyez pas de confirmation contextuelle pour la raison pour laquelle le navigateur le bloque.
Exemples d'exploitation de XSS.
Les malfaiteurs, l'intention d'utiliser des vulnérabilités de script intersiteite, devraient approcher chaque classe de vulnérabilités de différentes manières. Voici les vecteurs d'attaques pour chaque classe.
Avec les vulnérabilités XSS, le boeuf peut être utilisé dans des attaques, ce qui élargit l'attaque du site Web à l'environnement local des utilisateurs.
Exemple d'attaque avec des XSS non permanents
1. Alice visit souvent un site Web spécifique qui héberge Bob. Le site Web BOB permet à Alice de se connecter avec le nom de l'utilisateur / du mot de passe et de conserver des données sensibles, telles que les informations de paiement. Lorsque l'utilisateur exerce une entrée, le navigateur conserve les cookies d'autorisation qui ressemblent à des caractères sans signification, c'est-à-dire. Les deux ordinateurs (client et serveur) se souviennent qu'il est entré.
2. Malories note que le site Web de BOB contient une vulnérabilité de XSS non permanente:
2.1 Lors de la visite de la page de recherche, nous entrons une ligne à rechercher et cliquez sur le bouton Envoyer si les résultats ne sont pas trouvés, la page affiche la chaîne de recherche entrée, suivie des mots "non trouvés" et de l'URL. http://bobssite.org?q\u003dyu requête de recherche
2.2 avec une requête de recherche normale comme le mot " chienchien»Page Affiche simplement" chienchien Non trouvé "et URL http://bobssite.org?q\u003d chienchienQuel est le comportement tout à fait normal.
2.3 Néanmoins, quand une requête de recherche anormale est envoyée à la recherche :
2.3.1 Un message d'avertissement apparaît (qui dit "XSS").
2.3.2 Affichages de page pas trouvé Avec un message d'erreur avec le texte "XSS".
2.3.3 URL adaptée à l'opération http://bobssite.org?q\u003d.
3. Malories conçoit l'URL pour exploiter la vulnérabilité:
3.1 elle fait l'URL http://bobssite.org?q\u003dpuppies.
3.2 Elle envoie un e-mail à un membre sans méfiance du site Bob, en disant: "Vérifiez les chiens cool."
4. Alice reçoit une lettre. Elle aime les chiens et clique sur le lien. Elle va sur le site Bob dans la recherche, elle ne trouve rien, il affiche les "chiens non trouvés", et au milieu de la balise, la balise est démarrée avec un script (il est invisible à l'écran), Charges et exécute le programme Malory authstealer.js (attaque XSS). Alice oublie à ce sujet.
5. Le programme AuthStealer.js commence dans le navigateur Alice comme si sa source est le site Web de BOB. Elle capture une copie des cookies d'autorisation d'Alice et envoie au serveur de Malory, où les malories les suppriment.
7. Maintenant que les Malories à l'intérieur, il va sur le site Web du site Web, looke et voler une copie du numéro de carte de crédit Alice. Puis elle va et change le mot de passe, c'est-à-dire Maintenant, Alice ne peut même pas aller.
8. Elle décide de passer la prochaine étape et envoie une référence à Bob lui-même de la même manière, et reçoit donc des privilèges administratifs du site BOB.
Attaque avec des XSS constants
- Malories a un compte sur le site Bob.
- Malory note que le site Web de BOB contient une vulnérabilité XSS constante. Si vous allez à nouvelle section, Placez un commentaire, puis il affiche qu'il ne serait pas imprimé. Mais si le texte de commentaire contient des balises HTML, ces balises seront affichées comme elles sont, et toutes les balises de script sont lancées.
- Malay lit un article dans la section des nouvelles et écrit un commentaire dans la section des commentaires. Dans le commentaire, il insère le texte:
- Dans cette histoire, j'ai tellement aimé les chiens. Ils sont si gentils!
Faites attention auxquelles les codes du code HTML tombent votre code intégré. Voici un exemple d'un champ de saisie de champ typique ( contribution):
Notre charge utile ira à l'endroit où le mot «taies d'oreiller» est maintenant. Ceux. se transformer en étiquette contribution. Nous pouvons éviter cela - fermez une citation double, puis la balise elle-même avec "/>
"/>
Essayons-la pour certains sites:
Excellente vulnérabilité
Programmes de recherche et de recherche de la vulnérabilité XSS
Probablement toutes les scanneurs d'applications Web ont un scanner de vulnérabilité XSS intégré. Ce sujet est awkhangeing, il est préférable de se familiariser avec chacun de ce scanner séparément.
Le script inter-sites (Abréviated XSS) est une vulnérabilité généralisée affectant de nombreuses applications Web. Il permet à un attaquant de mettre en œuvre du code malveillant dans un site Web de telle sorte que le navigateur d'utilisateur qui soit entré dans le site exécutera ce code.
Habituellement, une certaine interaction avec l'utilisateur est tenue d'exploiter cette vulnérabilité: elle est attirée sur un site infecté avec un ingénierie sociale ou juste attendre jusqu'à ce qu'il visite lui-même sur ce site. Par conséquent, les développeurs ne sont souvent pas perçus sérieusement XSS-Vulnérabilité.
Mais s'ils ne sont pas éliminés, cela peut être une menace de sécurité grave.
Imaginez que nous sommes dans le panneau Admin WordPress, ajoutez de nouveaux contenus. Si nous utilisons un plugin vulnérable à XSS, le navigateur peut créer un nouvel administrateur, modifier le contenu et effectuer d'autres actions malveillantes. Le script de cross-sites fournit un attaquant avec un contrôle presque complet sur le plus important logiciel De nos jours - Navigateur.
XSS: Vulnérabilité d'injection
Tout site Web ou application comporte plusieurs sites de saisie de données - formes à l'URL elle-même. L'exemple le plus simple des données d'entrée est lorsque nous entrons le formulaire de nom d'utilisateur et de mot de passe:
Notre nom sera stocké dans la base de données de site pour une interaction ultérieure avec nous. Sûrement, lorsque vous avez passé une autorisation sur n'importe quel site, vous avez vu un message d'accueil personnel dans le style de "Bienvenue, Ilya".
C'est à ces fins que les noms d'utilisateur sont stockés dans la base de données.
L'injection s'appelle une procédure lorsque, au lieu d'un nom ou d'un mot de passe, une séquence spéciale de symboles qui rend le serveur ou un navigateur répondent à certains, l'attaquant souhaité est entré.
Un script intersight s'appelle une injection qui implémente le code qui effectuera des actions dans le navigateur pour le compte du site Web. Il peut se produire à la fois avec la notification de l'utilisateur et dans mode de fond, sans sa connaissance.
Attaques Traditionnelles XSS:
Réfléchie (non permanent).
L'attaque XSS réfléchie est déclenchée lorsque l'utilisateur passe à un lien spécialement préparé.
Ces vulnérabilités apparaissent lorsque les données fournies par le client Web sont le plus souvent dans les paramètres de requête HTTP ou sous la forme de HTML sont exécutées directement par des scripts de serveur à l'analyse syntaxique et affichent la page de résultats de ce client, sans traitement correct.
Stocké (constant).
Les XSS stockés sont possibles lorsqu'un attaquant parvient à mettre en œuvre un code malveillant sur le serveur, en cours d'exécution dans le navigateur chaque fois lors de l'accès à la page d'origine. L'exemple classique de cette vulnérabilité est des forums sur lesquels il est autorisé à laisser des commentaires au format HTML.
Vulnérabilités causées par le code du côté du client (JavaScript, Visual Basic, Flash, etc.):
Également connu sous le nom de modèles DOM:
Réfléchie (non permanent).
Les mêmes que dans le cas du serveur, uniquement dans ce cas, l'attaque est possible en raison du fait que le code est traité par le navigateur.
Stocké (constant).
Semblable au stockage de XSS sur le côté serveur, uniquement dans ce cas, le composant malveillant est enregistré du côté du client à l'aide du stockage du navigateur.
Exemples de vulnérabilités XSS.
Fait intéressant, dans la plupart des cas, cette vulnérabilité est décrite, nous sommes effrayés par le code suivant:
Http://www.site.com/page.php?var\u003d
Il existe deux types de vulnérabilités XSS - passif et actif.
Vulnérabilité active Plus dangereux, comme un attaquant n'a pas besoin d'attirer le sacrifice sur un lien spécial, il suffit à lui de mettre en œuvre le code dans la base ou dans un fichier sur le serveur. Ainsi, tous les visiteurs du site deviennent automatiquement des victimes. Il peut être intégré, par exemple, en incorporant le code SQL (injection SQL). Par conséquent, vous ne devez pas faire confiance aux données stockées dans la base de données, même si dans l'insert, ils ont été traités.
Exemple vulnérabilité passive Vous pouvez voir au tout début de l'article. Il existe déjà des ingénieurs sociaux, par exemple, une lettre importante de l'administration du site vous demandant de vérifier les paramètres de votre compte, après la récupération de la sauvegarde. En conséquence, vous devez connaître l'adresse de la victime ou simplement organiser une lettre d'information sur le spam ou placer un poste sur un forum, et pas encore le fait que les victimes soient naïves et vont à votre lien.
De plus, des vulnérabilités passives peuvent être soumises à la fois au poste et à obtenir des paramètres. Avec des paramètres post-paramètres, il sera compris, vous devrez faire des astuces. Par exemple, la redirection du site intrus.