Voici ce qu'un attaquant peut faire en cas de vulnérabilité XSS.

• Ad-Jacking - Si vous parvenez à stocker du XSS sur un site Web, il suffit d’y injecter vos publicités 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.

• Usurpation de contenu - 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é.

• Récolte d'informations d'identification - La partie la plus amusante. Vous pouvez utiliser une fenêtre contextuelle sophistiquée pour collecter les informations d'identification. Le micrologiciel WiFi a été mis à jour, saisissez à nouveau vos informations d'identification pour vous authentifier.

• Téléchargements forcés - La victime ne télécharge donc pas votre lecteur Flash malveillant depuis absolument-safe.com? Ne vous inquiétez pas, vous aurez plus de chance en essayant de forcer un téléchargement à partir du site Web de confiance visité par votre victime.

• Crypto Mining - Oui, vous pouvez utiliser le processeur de la victime pour extraire du bitcoin pour vous!

• Contournement de la protection CSRF - Vous pouvez faire des requêtes POST avec JavaScript, vous pouvez collecter et soumettre un jeton CSRF avec JavaScript, de quoi avez-vous besoin d'autre?

• Keylogging - Vous savez ce que c'est.

• Enregistrement audio - Cela nécessite l'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 - Cela nécessite l'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.

• Voler les 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 window.localStorage () et window.webStorage () Browser & System

• Empreintes digitales - JavaScript facilite la recherche du nom de votre navigateur, de la version, des plug-ins installés et de leurs versions, de votre système d'exploitation, de l'architecture, de l'heure du système, de la langue et de la résolution de l'écran.

• Analyse du réseau - Le navigateur de la victime peut être utilisé de manière abusive pour analyser les ports et les hôtes avec JavaScript.

• Navigateurs en panne - Oui! Vous pouvez planter le navigateur en les inondant de… .stuff.

• Voler des informations - Récupérez des informations sur la page Web et envoyez-les à votre serveur. Simple!

• Redirection - Vous pouvez utiliser javascript pour rediriger les utilisateurs vers la 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 en colère et que vous pouvez remplacer sournoisement la page Web actuelle par une fausse.

• Capturer Captures d'écran - Merci encore à HTML5, vous pouvez maintenant prendre une capture d'écran d'une page Web. Les outils de détection Blind XSS l'ont fait avant que ce 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 sécurité, mon entreprise a été chargée d'essayer d'accéder au PDG personnel e-mails. J'ai réussi à obtenir son adresse e-mail personnelle via un OSint, maintenant on peut opter pour un spear phishing avec une version personnalisée de l'un des nombreux logiciels malveillants voleurs d'informations, mais j'ai prolongé un peu plus la phase de collecte d'informations.

Il s'est avéré que le PDG aimait les bateaux et 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 trompé. Et qu'ai-je trouvé? Le site vous permet de gérer votre mot de passe en préremplissant un champ de mot de passe avec le champ 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!

Cela semble assez "inoffensif", n'est-ce pas? t-il? Et si vous le combinez avec la mauvaise gestion du mot de passe?

J'ai donc conçu un script qui a récupéré la page de mot de passe (c'est une requête intra-domaine, SOP est satisfait), extrait le mot de passe et les informations client (UA, OS et similaires) et envoyez-le à mon C&C. Puis instillé un sentiment d'envie au PDG en écrivant soigneusement un e-mail l'informant de mon "intention" d'acheter.

Au bout d'une journée, j'ai reçu le mot de passe utilisé pour se connecter sur le 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 si c'était encore une chose) et j'ai pu accéder au webmail (les informations du client ont été utilisées pour simuler un accès légitime , au cas où il serait nécessaire de faire profil bas).

Pour faire court, une attaque n'est pas une seule étape atomique, elle est faite de petites conquêtes. Si vous laissez la place à votre adversaire pour un pas, vous ne saurez jamais ce qu'il peut faire à partir de là. Un XSS est de la place pour l'attaquant, comme vous en avez vu pas mal.

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 qui se trouvent à 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 à la bombe dans un client de messagerie, etc.). Notez que ce type d'activité peut souvent être caché au client pour qu'il ne se rende pas compte qu'il est actuellement attaqué.

Une attaque XSS ne constitue 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 très humain, car tout type 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 de votre site vers une fausse page de connexion. Vous avez maintenant une faille de sécurité de masse potentielle des comptes d'utilisateurs sur votre site.
• Quelqu'un place un cryptominer sur votre site. Cela obligera les machines de vos visiteurs à faire des heures supplémentaires et, une fois repérées, vous donnera un air grossièrement gourmand et / ou grossièrement incompétent en tant qu'administrateur système. Aucun de ces éléments n'est satisfaisant.
• 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 plante les navigateurs. Encore une fois, il devrait être clair pourquoi c'est mauvais.
• Quelqu'un insère du code DDOS dans votre site pour essayer de supprimer votre site ou un tiers. S'il vous est destiné, 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 est devenu 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: Application Web Manuel des pirates

XSS est une injection de commande du côté client, comme l'a souligné l'autre utilisateur, il peut entraîner n'importe quelle action qui peut ê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 riding".

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 y est présent, vous disposez maintenant des 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 du fait que votre utilisateur voit ses 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 votre les utilisateurs ont des droits d'administrateur, alors une vulnérabilité XSS peut facilement conduire à des actions d'administration non intentionnelles. 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 code javascript dans les en-têtes HTTP des bots qui tentent de pirater votre site Web.

Pour vous donner un exemple réel où XSS a été utilisé pour prendre directement le contrôle du serveur lors d'un incident il y a environ 10 ans (même si j'ai oublié le nom du (petit / sans importance) site Web et que je doute qu'il existe plus):

Signaler au webmaster: "Il y a une vulnérabilité XSS sur votre site Web. Vous devriez corriger cela. Comment dois-je vous envoyer les détails?"

Réponse du webmaster en herbe: "Montre-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 Web. "

Le webmaster a fait cela et tout d'un coup, 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 (exécuté dans le navigateur et dans la session du webmaster) a envoyé des requêtes au serveur à:

1. ajouter un nouveau compte avec les droits les plus élevés (à des fins de démonstration)
2. 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 installer des widgets similaires à de nombreux systèmes CMS)

Des dommages supplémentaires auraient pu être causés en envoyant une demande à la société d'hébergement 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 / au registraire de domaine / à la banque et qu'ils n'aient pas de protection CSRF, ce 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 propage sur toutes les pages de profil et pourrait endommager votre serveur ou blesser vos utilisateurs.

Il semble que vous recherchez un danger pour le serveur (y compris SQL, etc.), pas pour le client, tant de dangers ne s'appliquent pas.

Mais il y a un danger à le serveur de ce que le client est autorisé à faire sur le serveur. Si le client a la permission de modifier la base de données, un attaquant peut é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'ID de session / cookie peut être un vol pour obtenir un accès complet aux comptes des victimes.
• Détérioration temporaire du site Web. Exécution de scripts JS malveillants (mineur, voleur de données de carte, enregistreur de frappe, etc.)
• En utilisant des frameworks d'exploitation comme Beef, un attaquant peut effectuer certains appels OS tels que l'ouverture de webcams à distance, la rotation du microphone, la redirection de tous les sites Web vers des sites Web malveillants, etc.
• Parfois, XSS peut être utilisé pour voler les jetons secrets des victimes, les jetons CSRF (crosssite request forgery), les clés API, puis une exploitation plus poussée peut être effectuée comme des attaques CSRF.

Ce blog et celui-ci montrent comment l'attaque XSS est utilisée pour effectuer une 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é qui est assez facile à intégrer dans votre code, et qui est détectable par les scanners. C'est probablement l'une des raisons pour lesquelles il est relativement bien connu du "grand public", y compris des journalistes (au sens de "j'en ai entendu parler").

Si vous en avez un disponible publiquement, 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 le cas.

Il permet de voler toutes vos données. Cela fait. Le͟ ̨da҉t͘a̵ ͢haś ̴al͞r̀ead́y͠b̷e̷e̶n̨ s͝t͜o̢l͝e͜n. Įt̨ ̷ha̵s.

Vous pouvez alors 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 plusieurs 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 accèdent à la page concerné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é.