Le codage HTML empêchera-t-il tous les types d'attaques XSS ?

Question

Je ne suis pas préoccupé par d'autres types d'attaques. Je veux juste savoir si HTML Encode peut prévenir tous les types d'attaques XSS.

Existe-t-il un moyen d'effectuer une attaque XSS même si HTML Encode est utilisé ?

Answer 1

Non.

Si l'on met de côté la question de l'autorisation de certaines balises (qui n'est pas vraiment l'objet de la question), HtmlEncode ne couvre tout simplement PAS toutes les attaques XSS.

Prenons l'exemple du javascript côté client généré par le serveur - le serveur produit dynamiquement des valeurs codées en html directement dans le javascript côté client, htmlencode va ne pas s'arrêter a empêché l'exécution du script injecté.

Considérons ensuite le pseudocode suivant :

<input value=<%= HtmlEncode(somevar) %> id=textbox>

Maintenant, au cas où cela ne serait pas immédiatement évident, si somevar (envoyé par l'utilisateur, bien sûr) est fixé par exemple à

a onclick=alert(document.cookie)

le résultat obtenu est le suivant

<input value=a onclick=alert(document.cookie) id=textbox>

qui fonctionnerait manifestement. Évidemment, il peut s'agir de (presque) n'importe quel autre script... et HtmlEncode ne serait pas d'une grande aide.

Il y a quelques vecteurs supplémentaires à prendre en compte... y compris le troisième type de XSS, appelé DOM-based XSS (dans lequel le script malveillant est généré dynamiquement sur le client, par exemple sur la base des valeurs #).

N'oubliez pas non plus les attaques de type UTF-7 - où l'attaque ressemble à

+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-

Il n'y a pas grand-chose à encoder ici...

La solution, bien sûr (en plus d'une validation appropriée et restrictive des entrées en liste blanche), consiste à effectuer les opérations suivantes sensible au contexte encodage : HtmlEncoding est excellent SI le contexte de sortie est HTML, ou peut-être avez-vous besoin de JavaScriptEncoding, ou VBScriptEncoding, ou AttributeValueEncoding, ou... etc.

Si vous utilisez MS ASP.NET, vous pouvez utiliser leur bibliothèque Anti-XSS, qui fournit toutes les méthodes de codage contextuel nécessaires.

Notez que tous les encodages ne doivent pas être limités à la saisie de l'utilisateur, mais également aux valeurs stockées dans la base de données, aux fichiers texte, etc.

Oh, et n'oubliez pas de définir explicitement le charset, à la fois dans l'en-tête HTTP ET dans la balise META, sinon vous aurez toujours des vulnérabilités UTF-7...

Pour plus d'informations et une liste définitive (constamment mise à jour), consultez l'aide-mémoire de RSnake : http://ha.ckers.org/xss.html

Answer 2

Si vous encodez systématiquement toutes les données saisies par l'utilisateur avant de les afficher alors oui, vous êtes en sécurité vous n'êtes toujours pas en sécurité à 100 %.
(Voir le billet de @Avid pour plus de détails)

En outre, des problèmes se posent lorsqu'il s'agit de laisser certains ne sont pas codées, ce qui permet aux utilisateurs d'afficher des images, du texte en gras ou toute autre fonction nécessitant que les données de l'utilisateur soient traitées (ou converties) en balises non codées.

Vous devrez mettre en place un système de prise de décision pour déterminer quelles balises sont autorisées et lesquelles ne le sont pas, et il est toujours possible que quelqu'un trouve un moyen de laisser passer une balise non autorisée.

Il est utile de suivre les conseils de Joel, à savoir Faire passer un code erroné pour un code erroné ou si votre langue vous aide en avertissant ou en ne compilant pas lorsque vous produisez des données utilisateur non traitées (typage statique).

Answer 3

Si vous encodez tout, il le fera. (en fonction de votre plateforme et de l'implémentation de htmlencode) Mais toute application web utile est si complexe qu'il est facile d'oublier d'en vérifier chaque partie. Ou peut-être qu'un composant tiers n'est pas sûr. Ou peut-être qu'un chemin de code que vous pensiez faire de l'encodage ne l'a pas fait et que vous l'avez oublié ailleurs.

Il peut donc être utile de vérifier les choses du côté de l'entrée. Et vous pourriez vouloir vérifier les choses que vous lisez dans la base de données.

Answer 4

Comme tous les autres l'ont mentionné, vous êtes en sécurité tant que vous encodez todos de l'utilisateur avant de l'afficher. Cela inclut tous les paramètres de la requête et les données extraites de la base de données qui peuvent être modifiées par l'utilisateur.

En tant que mentionné par Pat vous voudrez parfois afficher certaines balises, mais pas toutes. Une façon courante de le faire est d'utiliser un langage de balisage tel que Textile , Markdown ou BBCode . Cependant, même les langages de balisage peuvent être vulnérables aux XSS, il faut en être conscient.

# Markup example
[foo](javascript:alert\('bar'\);)

Si vous décidez de laisser passer les balises "sûres", je vous recommande de trouver une bibliothèque existante pour analyser et assainir votre code avant la sortie. Il existe beaucoup de vecteurs XSS qu'il faudrait détecter pour que votre désinfectant soit relativement sûr.

Answer 5

Je partage le conseil de metavida de trouver une bibliothèque tierce pour gérer le filtrage de sortie. Neutraliser les caractères HTML est une bonne approche pour stopper les attaques XSS. Cependant, le code que vous utilisez pour transformer les métacaractères peut être vulnérable aux attaques d'évasion ; par exemple, s'il ne gère pas correctement l'Unicode et l'internationalisation.

Une erreur classique et simple commise par les filtres de sortie maison est de n'attraper que < et >, mais d'omettre des choses comme ", qui peuvent interrompre la sortie contrôlée par l'utilisateur dans l'espace d'attribut d'une balise HTML, où le Javascript peut être attaché au DOM.