Dans quelle mesure devrais-je essayer d'empêcher un utilisateur de XSSing lui-même?
Disons qu'un utilisateur peut stocker des données dans une application Web. Je ne parle maintenant que de ce type de données que l'utilisateur peut voir lui-même, et non pas destiné à être consulté par d'autres utilisateurs de la webapp. (Ou si d'autres utilisateurs peuvent afficher ces données, elles sont traitées de manière plus sécurisée.)
À quel point serait-il horrible de permettre une certaine vulnérabilité XSS dans ces données?
Bien sûr, la réponse d'un puriste serait clairement: "Aucune vulnérabilité n'est autorisée". Mais honnêtement - pourquoi?
Tout ce qui est autorisé est l'utilisateur XSSing THEMSELVES. Quel est le mal ici? Les autres utilisateurs sont protégés. Et je ne vois pas pourquoi quelqu'un monterait une attaque contre lui-même (sauf s'il s'agit d'une attaque inoffensive, auquel cas - encore une fois - aucun mal n'est fait).
Mon instinct est que le raisonnement ci-dessus soulèvera quelques sourcils ... OK, alors qu'est-ce que je ne vois pas?
Il s'agit en fait d'un véritable concept, "Self XSS" qui est suffisamment courant pour que si vous ouvrez https://facebook.com puis ouvrez les outils de développement, ils vous en avertissent 
Évidemment, Facebook est un type spécifique de cible et que ce problème vous intéresse ou non, cela dépend de la nature exacte de votre site, mais vous ne pourrez peut-être pas ignorer l'idée qu'un utilisateur utilise des techniques d'ingénierie sociale pour amener un autre utilisateur à s'attaquer.
Bien que vous ayez raison, cela pourrait ne pas avoir autant d'importance d'un point de vue d'attaque. Du point de vue de l'utilisabilité, l'utilisateur peut rencontrer des 'comportement inattend'. Il y a quelque temps, je devais travailler avec des logiciels qui avaient un problème évident d'injection SQL (les entrepreneurs ne pouvaient pas/ne voulaient pas le résoudre). Cela signifiait que les utilisateurs inattendus entreraient dans quelque chose d'apparemment inoffensif tel que leur nom "O'Brien", qui déclencherait une injection SQL et pour les personnes analphabètes par ordinateur, c'était un comportement inattendu, qui était extrêmement difficile à dépanner pour eux. C'est probablement moins probable avec XSS, mais tenez compte des points suivants si un utilisateur utilise <> au lieu de (), les données peuvent sembler disparaître. Une preuve de concept se trouve ci-dessous:
<html>
<head><title>HI</title></head>
<body>
<h1>WEBSITE</h1>
Hey my name is <travis>.
</body>
</html>
Notez que lorsque ce site Web est rendu, le mot 'travis', n'est pas rendu.
Si la seule façon d'insérer du code malveillant est de le taper littéralement sur votre page Web, alors le vecteur d'attaque serait "self xss", qui a été mentionné dans une autre réponse, et qui est une attaque d'ingénierie sociale que vous ne pouvez pas vraiment empêcher.
Mais si du code malveillant peut également être chargé d'autres manières sur votre page, vous avez un problème plus important. Par exemple, si votre site Web est vulnérable aux XSS ou CSRF reflétés, un attaquant peut les utiliser pour obliger l'utilisateur à charger du code malveillant.
Exemple de XSS reflété: si le paramètre de données est imprimé sur la page sans la désinfecter, un attaquant peut obliger la victime à naviguer jusqu'à l'URL suivante pour lui faire charger du code malveillant.
https://www.example.com/search?data=<script src="..."></script>
Exemple de CSRF: si les données soumises sont ensuite imprimées sur la page sans les nettoyer et qu'il n'y a pas non plus de protection contre CSRF, un attaquant peut obliger la victime à publier des données malveillantes.
<form method="post" action="submit">
<input type="text" name="title">
<input type="text" name="note">
<input type="submit" value="submit">
<!-- NO TOKEN TO PREVENT CSRF HERE!!! -->
</form>
Comme vous pouvez le voir, le problème n'est pas seulement "qui peut voir les données", mais aussi "qui peut entrer les données". Mais même si vous étiez sûr que les exemples ci-dessus ne s'appliquent pas à votre situation, pourquoi devriez-vous toujours essayer d'éviter XSS et toujours essayer de nettoyer les données? Parce que la désinfection devrait devenir une habitude même si, dans certaines situations, elle peut ne pas sembler vraiment utile. Si la désinfection n'est pas une habitude, tôt ou tard, vous oublierez de désinfecter quelque chose qui finira par conduire à XSS.
XSS est toujours mauvais, même si la charge utile est liée au compte qui l'a créé. Bien sûr, ce n'est pas aussi mauvais que XSS "ordinaire", mais ce n'est toujours pas inoffensif.
Voici un exemple d'attaque: d'abord, je dois demander à la victime de se connecter en tant que moi. Cela peut se faire via l'ingénierie sociale ou la connexion CSRF s'il n'y a aucune protection contre cela. Deuxièmement, je demande à la victime de visiter la page concernée en tant que moi. Le script ajoute ensuite un enregistreur de frappe au site, donc lorsque la victime se déconnecte et essaie de se connecter comme elle-même, je reçois son mot de passe.
Il existe de nombreuses raisons pour lesquelles une attaque comme celle-ci échouerait, mais cela pourrait bien fonctionner. Vous devez boucher tous les trous XSS, peu importe où ils se trouvent.
Je pense qu'il y a un autre cas d'utilisation qui peut ne pas être répertorié dans les réponses jusqu'à présent qui est le accidentel self XSS. Certains utilisateurs peuvent rencontrer un problème qu'ils rencontrent sur un site et peuvent commencer à rechercher des solutions de dépôt qu'ils copient et collent. Des "solutions" soigneusement conçues pourraient causer des problèmes.
La portée de l'attaque est que l'utilisateur s'automutile accidentellement, mais il est peu probable qu'il nuise aux autres utilisateurs. Ceci est similaire à la façon dont il peut être dangereux de copier et coller des commandes bash que vous trouvez sur Internet. Un site malveillant pourrait offrir une aide Linux, mais inclure subtilement une commande qui pourrait exfiltrer les données utilisateur d'une manière ou d'une autre.
Autoriser des attaques soi-disant "auto-XSS" peut avoir des ramifications secondaires.
Par exemple, j'ai récemment vu un problème où un champ de texte serait, selon le rapport de bogue, supprimer tout le texte après un signe inférieur à. Le navigateur interprétait le signe inférieur à comme le début d'une balise HTML.
Un autre problème que j'ai vu est que ces champs "self-XSS" ne permettent aucune entrée valide arbitraire. Par exemple, considérez un champ "notes", dans lequel l'utilisateur peut souhaiter stocker quelque chose qu'il a appris:
One can make bold text by surrounding it with these tags: <b>Hello, bold world!</b>
Si votre application autorise les attaques "auto-XSS", l'utilisateur aura du mal à ajouter une telle note.
Quelque chose qui n'est pas mentionné dans d'autres réponses, est les problèmes de sécurité secondaires potentiels qui peuvent survenir d'un auto-XSS.
Supposons que votre application dispose de fonctionnalités vraiment puissantes/dangereuses qui obligent l'utilisateur à saisir à nouveau son mot de passe, comme changer un ancien mot de passe ou autoriser un tiers à accéder à son compte. Un attaquant pourrait accéder temporairement au compte via une attaque comme le détournement de cookies, une session inactive (utilisateur éloigné de son bureau) ou une contrefaçon de demande intersite (CSRF). Dans aucun de ces cas, l'attaquant ne pourrait effectuer directement ces actions puissantes car il ne connaîtrait pas le mot de passe de l'utilisateur. Cependant, ils pourraient tirer parti de la vulnérabilité auto-XSS pour effectuer une attaque d'ingénierie sociale très convaincante pour obtenir les informations d'identification des utilisateurs ou configurer une charge utile XSS pour leur donner un accès permanent au compte de l'utilisateur (chaque fois que l'utilisateur se connecte).
Dans le cas de CSRF, une action relativement inoffensive peut être transformée en une attaque puissante en utilisant le CSRF pour provoquer un self-XSS stocké qui donne ensuite à l'attaquant l'accès aux cookies de l'utilisateur ou à la session du navigateur. J'ai en fait utilisé cette technique de chaîne d'attaque à plusieurs reprises pour démontrer les vulnérabilités aux développeurs.
Il y a ici d'excellentes réponses d'un point de vue purement sécuritaire. L'angle self-XSS est absolument correct, même si celui du haut lié à celui-ci n'a pas explicitement établi la connexion qu'il implique.
Étant, essentiellement, que si les gens peuvent se laisser piéger dans la suppression de code auto-XSS dans la console de développement, pourquoi vous attendriez-vous à ce qu'ils ne se laissent pas piéger dans la chute dans un élément d'entrée de votre interface utilisateur?
D'autres réponses lient cela ensemble à la façon dont cela peut créer des problèmes plus larges quand cela (imo, inévitablement, si quelqu'un se fait piéger dans l'auto-XSSing) conduit à des compromis de compte.
Je pense que ce sont probablement les principales raisons immédiates. Mais je voudrais quand même aborder cela sous un autre angle:
Pratiques de développement: implications de permettre Self-XSS
Disons qu'un utilisateur peut stocker des données dans une application Web. Je ne parle maintenant que de ce type de données que l'utilisateur peut voir lui-même, et non pas destiné à être consulté par d'autres utilisateurs de la webapp.
Le problème avec votre supposition ici est qu'elle suppose que vous n'empêchez pas XSS sur toutes les sorties de données fournies par l'utilisateur comme pratique par défaut: idéalement comme mécanisme de sortie par défaut de la classe ou de la fonction utilisée pour récupérer et sortir des données, avec tout écart nécessitant un paramètre spécifique pour sélectionner la méthode de filtrage de sortie différente.
Si vous n'avez pas votre application codée de telle manière que la méthode de sortie par défaut empêche XSS (et différentes cibles de sortie telles que les attributs par rapport aux éléments nécessitent des méthodologies différentes pour ce qui est et n'est pas autorisé, par conséquent 'par défaut'), et il faut plus d'efforts (pas moins) pour cibler la sortie afin de permettre (espérons-le à la liste blanche, "purifié") quelque chose de passer en HTML natif/etc ...
Dans quelle mesure êtes-vous sûr que vous n'allez pas avoir un accident où une réflexion des données utilisateur sur le Web ne permet pas à XSS en dehors de juste "les données que l'utilisateur peut VOIR ELLES"?
Parce que des erreurs se produisent. Les gens oublient les étapes lorsqu'ils écrivent du code. Des échecs se produisent dans la formation où des points clés ou même des sujets sont manqués. Certaines personnes ne font pas de "RTFM": même les développeurs. L'architecture/le cadre de votre application doit viser à s'assurer que le chemin le moins résistant lors de l'écriture de code est toujours le résultat le plus sûr, pas le résultat le moins sûr.
Permettre à XSS de se produire potentiellement sur la base des entrées de l'utilisateur devrait nécessiter une action positive, un choix explicite du développeur par rapport à chaque endroit où cela pourrait se produire, et non simplement le résultat par défaut de base de l'extraction des données utilisateur stockées et de leur reflet. Si votre code n'est pas écrit comme ceci, où il empêche XSS par défaut et nécessite un paramètre de remplacement d'une sorte pour désactiver cette purification de sortie, c'est un signe que vous devez réévaluer votre processus.
Bien que dans ce contexte, nous nous concentrions sur les conséquences techniques de permettant un auto-XSS, nous devons également prendre en considération l'impact d'une telle chose en tant qu'entreprise: un auto-XSS pourrait provoquer des comportements inattendus (affectant l'expérience utilisateur), alors comment un utilisateur devrait-il se sentir/réagir en le rencontrant?
De plus, étant donné qu'une vulnérabilité XSS est facilement évitable, cela vaut-il vraiment la peine de ne pas s'en inquiéter? Pensez simplement à toute conséquence possible: tickets de support ouverts, bogues signalés, mécontentement des utilisateurs, ..?