Purificateur HTML - Que purifier?

Question

J'utilise HTML Purifier pour protéger mon application contre les attaques XSS. Actuellement, je purifie le contenu des éditeurs WYSIWYG, car c’est le seul endroit où les utilisateurs sont autorisés à utiliser le balisage XHTML.

Ma question est la suivante: dois-je utiliser HTML Purifier également sur un nom d'utilisateur et un mot de passe dans un système d'authentification de connexion (ou sur des champs de saisie de la page d'inscription tels que l'adresse électronique, le nom, l'adresse, etc.)? Y at-il une chance d’attaque XSS là-bas?

Answer 1

Vous devez purifier tout ce qui sera éventuellement affiché sur une page. En raison des attaques XSS, les pirates informatiques insèrent des <script> balises ou d’autres balises malveillantes pouvant être reliées à d’autres sites.

Les mots de passe et les courriels devraient convenir. Les mots de passe ne doivent jamais être affichés et les emails doivent avoir leur propre validateur pour s'assurer qu'ils sont au bon format.

Enfin, souvenez-vous toujours de mettre htmlentities () sur le contenu.

Oh .. et regardez filter_var ainsi. Très bon moyen de filtrer les variables.

Answer 2

Il existe des risques XSS lorsque des données saisies par un utilisateur peuvent être consultées par d'autres utilisateurs. Même si ces données ne sont pas visibles pour le moment, ne présumez pas que cela ne sera pas nécessaire.

En ce qui concerne le nom d'utilisateur et le mot de passe, vous ne devez jamais afficher un mot de passe, ni même le stocker sous une forme pouvant être affichée (c'est-à-dire le coder avec sha1()). Pour les noms d'utilisateur, limitez les caractères légaux, tels que [A-Za-z0-9_]. Enfin, comme l’a suggéré l’autre réponse, utilisez la fonction de codage d’entités HTML de votre langue pour toutes les données saisies pouvant contenir des caractères HTML réservés ou spéciaux, afin d’empêcher ces données de provoquer des erreurs de syntaxe lorsqu’elles sont affichées.

Answer 3

Non, je n'utiliserais pas HTMLPurifier sur le nom d'utilisateur et le mot de passe lors de l'authentification de connexion. Dans mes applications, j'utilise des noms d'utilisateur alphanumériques et un filtre de validation d'entrée et les affiche avec htmlspecialchars avec ENT_QUOTES. Ceci est très efficace et beaucoup plus rapide que HTMLpurifier. Je n'ai pas encore vu d'attaque XSS utilisant une chaîne alphanumérique. Et BTW HTMLPurifier est de toute façon inutile lors du filtrage du contenu alphanumérique. Par conséquent, si vous forcez la chaîne d'entrée à travers un filtre alphanumérique, il ne sert à rien de l'afficher avec HTMLpurifier. En ce qui concerne les mots de passe, ils ne devraient jamais être montrés à quiconque, ce qui élimine la possibilité de XSS. Et si, pour une raison perverse, vous souhaitez afficher les mots de passe, vous devez concevoir votre application de manière à ce que seul le propriétaire du mot de passe puisse le voir, sinon vous êtes foutu fort et XSS est le moindre de votre inquiétude!

Answer 4

HTML Purifier prend HTML en entrée et génère HTML en sortie. Son but est de permettre à l'utilisateur d'entrer du code HTML avec certains balises, attributs et valeurs, tout en filtrant les autres. Ceci utilise une liste blanche pour empêcher toute donnée pouvant contenir des scripts. C'est donc utile pour quelque chose comme un éditeur WYSIWYG.

Les noms d'utilisateur et mots de passe, en revanche, ne sont pas HTML . Ce sont du texte brut , de sorte que l'épurateur HTML n'est pas une option. Essayer d’utiliser HTML Purifier ici corromprait les données ou autoriserait les attaques XSS.

Par exemple, cela laisse inchangé ce qui suit, ce qui peut causer des problèmes XSS lorsqu'il est inséré comme valeur d'attribut dans certains éléments:

" onclick="javascript:alert()" href="

Ou si quelqu'un a essayé d'utiliser des symboles spéciaux dans son mot de passe et a entré:

<password

alors leur mot de passe deviendrait vide et le rendrait beaucoup plus facile à deviner.

Au lieu de cela, vous devriez encoder le texte. Le codage requis dépend du contexte, mais vous pouvez utiliser htmlentities lors de la génération de ces valeurs si vous vous en tenez à la règle n ° 0 et à la règle n ° 1 , à la Aide-mémoire de prévention OWASP XSS