Quel est le danger de XSS?
Je suis ingénieur logiciel et j'ai regardé beaucoup de vidéos sur XSS.
Mais je n'arrive pas à comprendre en quoi il est dangereux s'il s'exécute côté client et ne s'exécute pas côté serveur qui contient les bases de données et de nombreux fichiers importants.
Voici les actions qu'un attaquant peut effectuer s'il existe une vulnérabilité XSS.
- Ad-Jacking - Si vous parvenez à stocker XSS sur un site Web, injectez-y simplement vos annonces pour gagner de l'argent;)
- Click-Jacking - Vous pouvez créer une superposition cachée sur une page pour détourner les clics de la victime pour effectuer des actions malveillantes.
Détournement de session - Les cookies HTTP sont accessibles par JavaScript si l'indicateur HTTP UNIQUEMENT n'est pas présent dans les cookies.
Content Spoofing - JavaScript a un accès complet au code côté client d'une application web et vous pouvez donc l'utiliser pour afficher/modifier le contenu souhaité.
Credential Harvesting - La partie la plus amusante. Vous pouvez utiliser un popup fantaisie pour récolter les informations d'identification. Le firmware WiFi a été mis à jour, entrez à nouveau vos informations d'identification pour vous authentifier.
Téléchargements forcés - Donc, la victime ne télécharge pas votre lecteur flash malveillant depuis absolument-safe.com? Ne vous inquiétez pas, vous aurez plus de chance d'essayer de forcer un téléchargement à partir du site Web de confiance que votre victime visite.
Crypto Mining - Oui, vous pouvez utiliser le CPU de la victime pour extraire du bitcoin pour vous!
Contourner CSRF protection - Vous pouvez faire POST requêtes avec JavaScript, vous pouvez collecter et soumettre un token CSRF avec JavaScript, de quoi d'autre avez-vous besoin?
Keylogging - Vous savez ce que c'est.
Enregistrement audio - Il nécessite une autorisation de l'utilisateur mais vous accédez au microphone de la victime. Merci à HTML5 et JavaScript.
Prendre des photos - Cela nécessite l'autorisation de l'utilisateur mais vous accédez à la webcam de la victime. Merci à HTML5 et JavaScript.
Géolocalisation - Il nécessite une autorisation de l'utilisateur mais vous accédez à la géolocalisation de la victime. Merci à HTML5 et JavaScript. Fonctionne mieux avec les appareils avec GPS.
Vol de données de stockage Web HTML5 - HTML5 a introduit une nouvelle fonctionnalité, le stockage Web. Désormais, un site Web peut stocker des données dans le navigateur pour une utilisation ultérieure et, bien sûr, JavaScript peut accéder à ce stockage via le navigateur et le système window.localStorage () et window.webStorage ().
Fingerprinting - JavaScript est un jeu d'enfant pour trouver le nom, la version, les plugins installés et leurs versions de votre navigateur, votre système d'exploitation, l'architecture, l'heure du système, la langue et la résolution d'écran.
Analyse résea - Le navigateur de la victime peut être utilisé abusivement pour analyser les ports et les hôtes avec JavaScript.
Crashing Browsers - Oui! Vous pouvez planter le navigateur en les inondant de… .stuff.
Vol d'informations - Récupérez les informations de la page Web et envoyez-les à votre serveur. Facile!
Redirection - Vous pouvez utiliser javascript pour rediriger les utilisateurs vers une page Web de votre choix.
Tabnapping - Juste une version sophistiquée de la redirection. Par exemple, si aucun événement de clavier ou de souris n'a été reçu pendant plus d'une minute, cela peut signifier que l'utilisateur est afk et vous pouvez remplacer sournoisement la page Web actuelle par une fausse.
Capture Captures d'écran - Merci à nouveau à HTML5, vous pouvez maintenant prendre une capture d'écran d'une page Web. Les outils de détection aveugles XSS l'ont fait avant qu'il ne soit cool.
Effectuer des actions - Vous contrôlez le navigateur,
Peut-être qu'un exemple concret aiderait à comprendre à quel point une faille de sécurité apparemment mineure, comme XSS, peut être dangereuse.
Dans le cadre d'une évaluation de la sécurité, mon entreprise a été chargée d'essayer d'accéder aux e-mails personnels du PDG.
J'ai réussi à obtenir son adresse e-mail personnelle via OSint, maintenant on pouvait opter pour un spear phishing avec une version personnalisée de l'un des nombreux logiciels malveillants de vol d'informations mais j'ai prolongé la phase de collecte d'informations un peu plus longtemps.
Il s'est avéré que le PDG aimait les bateaux et qu'il vendait l'un des leurs sur un site de vente de bateaux.
Le site semble assez amateur, je me suis inscrit et je me suis un peu amusé. Et qu'ai-je trouvé?
Le site vous permet de gérer votre mot de passe en remplissant un champ de mot de passe par celui actuel, stimulé par cela. J'examine un peu plus le site.
Je suis tombé sur une vulnérabilité XSS stockée: lorsque vous répondez à une offre, vous pouvez y mettre du code HTML arbitraire, y compris des scripts, et il sera exécuté dans le navigateur du lecteur!
Semble assez "inoffensif", non? Et si vous le combiniez avec la mauvaise gestion du mot de passe?
J'ai donc créé un script qui a récupéré la page de mot de passe (c'est une demande intra-domaine, SOP est satisfait), extrait le mot de passe et les informations client (UA, OS et similaire) et l'envoyer à un C&C à moi.
Ensuite, il a incité le PDG à écrire un e-mail les informant de mon "intention" d'acheter.
Après une journée, j'ai reçu le mot de passe utilisé pour se connecter au site des bateaux.
Comme prévu, c'était le même mot de passe que celui utilisé pour leur e-mail (il n'y avait pas de 2FA, je ne me souviens pas encore si c'était une chose) et j'ai pu accéder au webmail (les informations client ont été utilisées pour simuler un accès légitime, au cas où il serait nécessaire de garder un profil bas).
Pour faire court, une attaque n'est pas une seule étape atomique, elle est faite de petites conquêtes. Si vous donnez à votre adversaire une marge de manœuvre, vous ne saurez jamais ce qu'il peut faire à partir de là. Un XSS est une pièce pour l'attaquant, comme vous en avez vu beaucoup.
Le code contrôlé par l'attaquant, qui s'exécute dans le contexte de l'application Web côté client, a un contrôle total sur ce que fait le client et peut également lire le DOM de la page HTML, etc.
Cela signifie qu'il peut à la fois voler des secrets à l'intérieur de cette page (mots de passe, etc.) et faire des choses en tant que client connecté (comme acheter quelque chose, envoyer des menaces de bombe dans un client de messagerie, etc.). Notez que ce type d'activité peut souvent être caché au client afin qu'il ne se rend pas compte qu'il est actuellement attaqué.
Une attaque XSS n'est pas un danger pour le serveur. C'est un danger pour la raison pour laquelle vous avez un serveur. Pas dans un sens technique mais bien humain, car toute sorte d'attaque XSS provenant de votre site se termine généralement par votre réputation dans les toilettes. Quelques cas de test:
- Quelqu'un redirige votre site vers une fausse page de connexion. Vous avez maintenant une violation de sécurité de masse potentielle des comptes d'utilisateurs sur votre site.
- Quelqu'un met un cryptominer sur votre site. Cela fera travailler les machines de vos visiteurs au fil du temps et, une fois repéré, vous fera paraître un homme extrêmement gourmand et/ou extrêmement incompétent. Ni l'un ni l'autre n'est un bon coup d'oeil.
- Quelqu'un redirige le trafic de votre site vers un concurrent. Je ne devrais pas avoir à expliquer pourquoi c'est mauvais.
- Quelqu'un y met du javascript qui rend votre site inutilisable ou même bloque les navigateurs. Encore une fois, il devrait être évident pourquoi cela est mauvais.
- Quelqu'un met du code DDOS dans votre site pour essayer de supprimer votre site ou un tiers. Si vous visez, il devrait être évident pourquoi c'est mauvais. S'il vise quelqu'un d'autre et que votre site est jugé coupable, votre hébergeur peut vous interrompre si vous ne corrigez pas votre site pour rupture de contrat.
- Quelqu'un remplace vos annonces par les leurs. Si vous comptez sur les revenus publicitaires, ils volent ces revenus.
- Quelqu'un l'utilise pour espionner vos utilisateurs. Hel-lo, violation du RGPD.
Lorsque XSS a d'abord été largement connu dans la communauté de la sécurité des applications Web, certains testeurs de pénétration professionnels étaient enclins à considérer XSS comme une vulnérabilité "boiteuse"
source: Manuel des pirates d'applications Web
XSS est une injection de commande du côté client, comme l'a souligné l'autre utilisateur, il peut entraîner toute action pouvant être effectuée par l'utilisateur. La plupart du temps, XSS est utilisé pour le détournement de session où l'attaquant utilisant javascript oblige la victime à transmettre des cookies de session à un serveur contrôlé par l'attaquant et à partir de là, l'attaquant peut effectuer une "session de session".
Mais XSS peut également entraîner une prise de contrôle complète de l'application. Considérez un scénario dans lequel vous injectez du javascript et il est stocké. L'administrateur charge ensuite cela dans un navigateur Web (généralement des journaux ou un CMS). Si un XSS est présent, vous avez maintenant les jetons de session d'administration. C'est pourquoi XSS peut être très dangereux.
La plupart des conséquences possibles des vulnérabilités XSS affectent l'utilisateur, pas votre serveur. Donc, si vous ne vous souciez pas que votre utilisateur obtienne des comptes sur votre site Web compromis ou que vos utilisateurs voient du contenu sur votre site Web qui ne provient pas de votre serveur, bien sûr, ignorez ces vulnérabilités.
Mais si vos utilisateurs ont des droits d'administrateur, une vulnérabilité XSS peut facilement conduire à des actions d'administration involontaires. Un cas classique de cela est une visionneuse de journaux dans votre zone d'administration qui n'est pas à l'épreuve XSS. Certains extraits de code javascript dans vos journaux d'accès peuvent être exécutés par vos administrateurs et effectuer des actions administratives sous leur compte. C'est pourquoi vous voyez parfois des extraits de javascript dans les en-têtes HTTP des bots qui tentent de pirater votre site Web.
Pour vous donner un exemple concret où XSS a été utilisé pour reprendre directement le serveur lors d'un incident il y a environ 10 ans (bien que j'aie oublié le nom du site (petit/sans importance) et que je doute qu'il existe plus):
Signaler au webmaster: "Il existe une vulnérabilité XSS sur votre site Web. Vous devez résoudre ce problème. Comment dois-je vous envoyer les détails?"
Réponse du webmaster en herbe: "Montrez-moi comment vous en abuseriez. Mon serveur est super sécurisé! Essayez-le si vous voulez mais vous n'aurez aucune chance."
Réponse du journaliste: "Alors jetez un œil à ma page de profil sur votre site."
Le webmaster a fait cela et soudain, tout le site Web était mort. Qu'est-il arrivé? Le journaliste a utilisé une vulnérabilité XSS pour insérer du code JavaScript sur sa page de profil.
Le code JavaScript (en cours d'exécution dans le navigateur et la session du webmaster) a envoyé des requêtes au serveur à:
- ajouter un nouveau compte avec les droits les plus élevés (à des fins de démonstration)
- pour renommer les fichiers PHP et les tables SQL sur le serveur (le site Web avait une section d'administration qui permettait cela à des fins d'administration comme les mises à jour ou l'installation de widgets similaires à de nombreux systèmes CMS)
Des dommages supplémentaires auraient pu être causés en envoyant une demande à l'hébergeur pour annuler l'abonnement du serveur et du domaine et transférer de l'argent depuis son compte bancaire (à condition que le webmaster soit connecté à l'hébergeur/registraire de domaine/banque et qu'il n'ait pas CSRF-protection qui n'était pas si rare il y a 10 ans).
N'oubliez pas non plus les vers XSS comme le MySpace-worm Samy qui se répandent sur toutes les pages de profil et pourraient DDOS votre serveur ou nuire à vos utilisateurs.
Il semble que vous recherchiez un danger pour le serveur (y compris SQL, etc.), pas pour le client, donc de nombreux dangers ne s'appliquent pas.
Mais il y a un danger pour le serveur de ce que le client est autorisé à faire sur le serveur. Si le client est autorisé à modifier la base de données, un attaquant peut le faire également. Et il en va de même pour tout ce qu'un client a l'autorisation de faire sur le serveur.
XSS lui-même est dangereux dans le sens suivant:
- L'identifiant de session/cookie peut être volé pour avoir un accès complet aux comptes des victimes.
- Dégradation temporaire du site Web. Exécution de scripts JS malveillants (mineur, voleur de données de carte, enregistreur de frappe, etc.)
- L'utilisation de frameworks d'exploitation tels que Beef, un attaquant peut effectuer certains appels de système d'exploitation, tels que l'ouverture de webcams à distance, la désactivation du microphone, la redirection de tous les sites Web vers des sites Web malveillants, etc.
- Parfois, XSS peut être utilisé pour voler des jetons secrets aux victimes, des jetons CSRF (contrefaçon de demande intersite), des clés API, puis une exploitation ultérieure peut être effectuée, comme des attaques CSRF.
Ce blog et celui-ci montre comment l'attaque XSS est utilisée pour effectuer l'injection SQL dans une application Web.
Vous avez d'autres réponses une très bonne liste de raisons techniques pour lesquelles XSS est un problème. Je vais donner une autre perspective.
XSS est une vulnérabilité assez facile à intégrer dans votre code et détectable par les scanners. C'est probablement l'une des raisons pour lesquelles cela est relativement bien conn pour le "grand public", y compris les journalistes (dans le sens de "j'en ai entendu parler").
Si vous en avez un accessible au public, il peut alors être décrit comme
Sai Kumar LLC a un site extrêmement vulnérable, car il a un XSS. XSS est une vulnérabilité très dangereuse. Très. C'est.
Il permet de voler toutes vos données. Cela fait. The͟ ̨da҉t͘a̵ ͢haś ̴al͞r̀ead́y ͠b̷e̷e̶n̨ s͝t͜o̢l͝e͜n. Il a.
Vous pouvez ensuite faire toutes sortes de danse du ventre en expliquant que ce n'est pas la vulnérabilité, l'erratum sera affiché en police 3 pt à la page 74, grisé.
C'est pourquoi j'augmente systématiquement le CVSS des résultats XSS sur mes sites Web publics (lorsqu'ils sont révélés par un pentest, un scan ou d'autres tests).
Les scripts intersites stockés sont très risqués pour diverses raisons: la charge utile n'est plus visible pour le filtre XSS du navigateur. Les utilisateurs peuvent par hasard déclencher la charge utile s'ils se rendent sur la page affectée, tandis qu'une URL spécialement conçue ou des entrées de formulaire précises seraient nécessaires pour exploiter le XSS reflété.