Si vous êtes un gourou des tests de sécurité et que vous participez une ou deux fois à des programmes de primes de grandes sociétés informatiques et que le nombre de XSS que vous avez trouvé se chiffre à des dizaines, voire des centaines, vous pouvez ignorer cet article en toute sécurité. Si vous êtes nouveau sur le sujet et que vous commencez tout juste à vous intéresser à la recherche de vulnérabilités, bienvenue sous cat.
Définition
XSS (Cross-Site Scripting) est une vulnérabilité assez courante que l'on retrouve dans de nombreuses applications Web. Son essence est assez simple: un attaquant parvient à injecter du code JavaScript dans la page qui n'a pas été fourni par les développeurs. Ce code sera exécuté à chaque fois que les victimes (utilisateurs réguliers) visitent la page de l'application où ce code a été ajouté. Et puis il y a plusieurs scénarios de développement.
Tout d'abord, un attaquant pourra obtenir les informations d'identification de l'utilisateur et se connecter à son compte.
Deuxièmement: l'attaquant peut, sans que la victime le remarque, le rediriger vers une autre page de clonage. Cette page peut sembler complètement identique à celle sur laquelle l'utilisateur s'attendait à être. Mais cela appartiendra à l'intrus. Si l'utilisateur ne remarque pas la substitution et entre des données sensibles sur cette page, c'est-à-dire des données personnelles, l'attaquant les aura.
Le troisième ... oui, en général, vous pouvez penser à beaucoup plus. Presque tout ce que JavaScript peut faire est mis à la disposition d'un attaquant. Ci-dessous, nous examinerons de plus près l'un de ces exemples. En attendant, essayons de discuter un peu plus en détail du fonctionnement de la vulnérabilité. Et pourquoi un attaquant parvient-il à injecter son code dans l'application de quelqu'un d'autre sans accéder à sa source.
Un petit avertissement. Toutes les informations ci-dessous sont présentées à titre informatif uniquement. Le testeur doit être capable de tester son application Web pour les vulnérabilités. Cependant, il est illégal d'exploiter les vulnérabilités XSS sur les ressources d'autres personnes.
Si nous parlons de la législation russe actuelle, lorsqu'un chercheur teste le produit de quelqu'un d'autre pour des vulnérabilités ou entre sur le réseau de quelqu'un d'autre à l'insu du propriétaire et sans son consentement, ses actions peuvent être considérées comme illégales.
Mais revenons à XSS.
Comment fonctionne la vulnérabilité?
Tout d'abord, comment réussissez-vous exactement à injecter du code JavaScript dans une page qui n'existait pas auparavant? Et comment distribuez-vous ce code aux autres utilisateurs?
Par exemple, vous pouvez ajouter du code JavaScript à un champ de saisie, dont le texte est enregistré et affiché ultérieurement sur la page pour tous les utilisateurs. Cela peut être un champ pour saisir des informations vous concernant sur une page de profil de réseau social ou des commentaires sur un forum.
L'attaquant entre du texte (et pour un code malveillant), qui est enregistré sur la page. Lorsque d'autres utilisateurs visitent la même page, ils téléchargeront le JavaScript de l'attaquant avec le texte. Au moment du chargement, ce code fonctionnera. Bien sûr, la vulnérabilité ne fonctionnera que si le texte n'est pas sécurisé lors de l'enregistrement. Nous parlerons un peu plus tard de la manière de procéder et des raisons pour lesquelles les développeurs l'oublient parfois.
Ceci n'est que l'exemple le plus simple et le plus évident de l'endroit où une vulnérabilité peut être cachée. Ci-dessous, nous examinerons un exemple plus intéressant sur une page de démonstration spécialement préparée.
Jusque-là, passons à autre chose.
Pourquoi de telles erreurs sont-elles souvent trouvées sur les projets Web?
L'essentiel est que le navigateur ne peut pas faire la distinction indépendamment entre le texte brut et le texte qui est du code CSS, HTML ou JavaScript. Il essaiera de traiter tout ce qui se trouve entre les balises <script> comme du code JavaScript. Tout ce qui se trouve entre les balises <style> est considéré comme CSS. Et tout ce qui ressemble à une balise est considéré comme du code HTML.
Si un développeur souhaite qu'un texte ne ressemble qu'à du code, mais qu'il ne l'est pas (c'est-à-dire qu'il n'a pas été traité par le navigateur, mais affiché tel quel), ce texte doit être spécialement traité avant de le donner au navigateur. Ce traitement est appelé «blindage».
En train d'échapper au texte de ce texte, toutes les promotions. les caractères sont remplacés par leurs «équivalents», et le navigateur sait déjà avec certitude qu'il ne s'agit que de texte. Le plus important est de traiter le texte qui vient de l'utilisateur, car tout utilisateur peut se révéler être un intrus et envoyer du code avec le texte. Hélas, les développeurs oublient parfois de s'échapper à certains endroits dans une application Web et le texte s'affiche sans aucun traitement. Il peut y avoir plusieurs raisons à cela.
Par exemple, le programmeur ne garde pas toujours à l'esprit tous les endroits où le texte spécifié par l'utilisateur apparaît sur la page. De plus, parfois différentes parties du site peuvent être créées à des moments différents et / ou par des personnes différentes. Dans ce cas, la probabilité d'erreur augmente.
Une autre raison peut être que la vulnérabilité ne se trouve pas dans le code du développeur lui-même, mais dans le code de la bibliothèque qu'il utilise. Il s'agit généralement de cadres prêts à l'emploi pour la création de services Web. Dans ce cas, le développeur, bien sûr, ne peut même pas soupçonner qu'en connectant ce framework au projet, il y connecte automatiquement une vulnérabilité toute faite.
Il y a toujours un tel risque. Néanmoins, écrire une application entièrement à partir de zéro, sans utiliser aucune bibliothèque du tout, est aujourd'hui long et coûteux. Toutes les entreprises ne peuvent pas se permettre de développer ce niveau.
Dans ce cas, tout espoir est pour les testeurs.
Pourquoi une vulnérabilité XSS est-elle dangereuse?
Parlons encore une fois plus en détail des dangers d'une vulnérabilité XSS. La vulnérabilité elle-même n'est pas dangereuse. Cela devient dangereux lorsqu'un intrus le trouve et commence à l'utiliser à ses propres fins. L'exploitation d'une vulnérabilité est appelée «vecteur d'attaque». Dans le cas de XSS, il existe de nombreux vecteurs d'attaque.
L'exemple le plus simple est le vol de cookies d'autorisation aux utilisateurs d'une application Web. Le plus souvent, le site sur lequel il y a autorisation distingue l'utilisateur autorisé par le soi-disant cookie de session. Si ce n'est pas là, alors l'utilisateur n'est pas autorisé. Et si c'est le cas, alors par la valeur de ce cookie, le serveur peut distinguer un utilisateur d'un autre.
Tous les cookies sont stockés sur l'ordinateur de l'utilisateur. Si je me connecte en tant qu'utilisateur, je verrai la valeur de mon cookie. Et je ne peux tout simplement pas découvrir la signification d'un étranger.
Il en va de même pour le code JavaScript qui s'exécute dans le navigateur de l'utilisateur. Ce code JavaScript verra la valeur du cookie de l'utilisateur dans le navigateur duquel il est exécuté et uniquement cet utilisateur.
Supposons maintenant qu'un attaquant réussisse à injecter du code JavaScript dans une page d'application Web. Tout utilisateur qui visite maintenant cette page verra le code JavaScript exécuté dans le navigateur. Il lira la valeur du cookie de cet utilisateur (maintenant la victime). Il ne reste plus qu'à transmettre cette valeur à l'attaquant - et le travail est terminé. Mais comment passer la valeur, puisque le code malveillant est exécuté dans le navigateur de la victime?
C'est assez simple. Le même code JavaScript peut créer une requête AJAX vers le serveur distant. Par exemple, à l'URL suivante: www.zloy-site.ru/stolen= { victim_cookie_value }
Le domaine zloy-site appartient à l'attaquant de notre exemple. Toutes les demandes qui arrivent dans ce domaine sont enregistrées dans la base de données. En regardant les paramètres d'URL, l'attaquant apprend les valeurs de cookie de la victime et peut les utiliser pour accéder à ses comptes.
Comme nous l'avons vu ci-dessus, ce n'est pas la seule chose qui rend une vulnérabilité XSS dangereuse. Donc, pour des raisons de sécurité et pour protéger vos utilisateurs, vous devez être en mesure de trouver et de fermer ces vulnérabilités dans vos projets.
Où puis-je trouver XSS? Comment y faire face? Page de démonstration avec exemple
Tout d'abord, il convient de vérifier les vulnérabilités XSS des endroits du site dans lesquels un utilisateur ordinaire a la possibilité d'influencer le contenu. S'il peut ajouter du texte quelque part, il peut également essayer d'ajouter du code JavaScript.
Regardons cela avec un exemple spécifique. J'ai préparé un bac à sable très simple où la vulnérabilité XSS était cachée. Je suggère d'essayer de le trouver ensemble.
Ouverture du bac à sable: https://playground.learnqa.ru/demo/xss Voyons d'
abord comment fonctionne la page. Il s'agit essentiellement d'un catalogue de livres très simple qui peut être recherché. Si nous saisissons «Ray Bradbury» dans la requête, nous verrons tous les livres qui se trouvent dans ce répertoire de cet auteur.
Un utilisateur attentif a déjà remarqué que le texte que nous avons saisi dans le champ de recherche s'est immédiatement retrouvé dans l'URL. Ce moment nous est encore utile.
Pour l'instant, essayons d'insérer des absurdités dans le champ de recherche: «fwefewf».
Nous verrons que dans ce cas, rien n'a été trouvé sur la page. Et le texte de la demande a été répété dans le texte d'erreur:
Donc, vous et moi avons trouvé l'endroit où le texte que nous avons entré apparaît. Par conséquent, il s'agit d'un site potentiel pour une vulnérabilité XSS. Essayons d'insérer le code JavaScript le plus populaire pour vérifier s'il existe une vulnérabilité.
<script> alert (123) </script>
Si la page est vulnérable, après avoir saisi ce code, la fenêtre suivante apparaîtra sur la page:
Cela signifie que notre code JavaScript a été exécuté et que nous avons trouvé une vulnérabilité XSS.
Donc, nous entrons le code et voyons l'avertissement suivant:
Le formulaire ne nous permet pas de rechercher par une telle valeur, car le formulaire est validé et ne veut fonctionner qu'avec des lettres et des chiffres. À première vue, il semble que le développeur a tout pris en compte et protégé la page de XSS, mais ce n'est pas tout à fait vrai.
Rappelez-vous, juste au-dessus, nous avons remarqué que le texte que nous saisissons dans le champ de recherche est affiché dans l'URL dans le paramètre dit GET? Le nom de ce paramètre est «q» et la valeur correspond à ce que nous saisissons dans le champ de recherche. Ceci est fait pour que vous puissiez copier l'URL avec cette chaîne de recherche et ouvrir immédiatement la page avec les bons auteurs.
Par exemple, cette URL ouvrira immédiatement une page avec uniquement les livres de Ray Bradbury: terrain de jeu.learnqa.ru/demo/xss?q=Ray+Bradbury
Contrairement au formulaire, le développeur ne pouvait pas faire de validation d'URL - tout utilisateur peut entrer n'importe quelle URL dans son navigateur tout ce qu'il veut, y compris avec n'importe quelle valeur du paramètre GET. La tâche du développeur dans ce cas est de ne pas oublier de prendre en compte toutes les options et d'écrire le bon gestionnaire pour la valeur de ce paramètre GET.
Vérifions si notre développeur a oublié de tout prendre en compte ici. Essayons de remplacer le même code JavaScript dans le paramètre "q" GET: https://playground.learnqa.ru/demo/xss?q= <script> alert (123) </script>
Après avoir cliqué sur cette URL, nous voyons que une fenêtre est apparue sur la page avec la valeur 123. Mais pourquoi?
C'est assez simple. Rappelez-vous, lorsqu'un site ne peut pas trouver les livres dont il a besoin pour une requête de recherche donnée, il affiche le texte de cette requête de recherche dans le texte d'une erreur? Comme, n'a rien trouvé pour la requête "bla bla". Au lieu de ce "bla bla", nous avons maintenant un code JavaScript avec une alerte. Le développeur a écrit une validation pour le champ de saisie et a décidé que c'était ainsi qu'il protégeait le site contre l'inclusion de JavaScript dans la requête de recherche. Et il n'a pas échappé au texte d'erreur. Nous avons réussi à contourner la validation d'URL en modifiant la valeur de la requête de recherche.
Par souci d'intérêt, nous pouvons maintenant afficher la valeur de notre cookie de session, pour cela, au lieu de <script> alert () </script>, vous devez remplacer un autre code dans l'URL: <script> alert (document.cookie) </script>
Je vous laisse jouer avec ceci toi même. :)
Après avoir trouvé un bogue, vous devez contacter les développeurs - ils le corrigeront.
Il existe de nombreuses façons de fermer l'erreur. Le texte qui s'échappe n'est pas le seul. Vous pouvez également empêcher JavaScript lui-même de voir certains cookies. Pour cela, le cookie a un paramètre spécial «http uniquement». S'il est défini sur TRUE, JavaScript ne pourra pas du tout savoir qu'un tel cookie est défini et ne pourra pas le lire et le transférer à un attaquant même s'il peut trouver XSS sur votre projet.
Tout cela n'est qu'une petite liste, loin d'être complète, de manipulations pour éviter les vulnérabilités XSS. Comme indiqué ci-dessus, si XSS est détecté pendant les tests, il est préférable de parler aux programmeurs.
Si vous souhaitez en savoir plus sur les tests de sécurité, vous souhaitez mieux comprendre la structure de l'architecture client-serveur, comprendre et affiner les moyens les plus efficaces pour trouver des vulnérabilités dans une vraie application Web, venez à mon cours «Tests de sécurité». Toutes les informations dont vous avez besoin se trouvent dans mon profil.
Vous ne trouverez qu'une théorie utile et nécessaire sans eau et un grand nombre d'exemples et de tâches pratiques. Vous explorerez de nombreuses pages Web remplies de nombreuses vulnérabilités. Le travail final consistera en une vaste étude de votre projet de travail ou de l'une des applications Web de géants tels que Google, Facebook, Twitter, etc.