Quelle est la différence entre AntiXss.HtmlEncode et HttpUtility.HtmlEncode?

Question

Je viens de rencontrer une question avec une réponse suggérant que la bibliothèque AntiXss évite les scripts intersite. Cela semblait intéressant de lire le blog msdn , il semble ne fournir qu'un code HTML. () méthode. Mais j’utilise déjà HttpUtility.HtmlEncode ().

Pourquoi voudrais-je utiliser AntiXss.HtmlEncode sur HttpUtility.HtmlEncode?

En effet, je ne suis pas le premier à poser cette question. Et, en effet, Google retourne une certaine répond , principalement

• Une approche utilisant la liste blanche au lieu de la liste noire
• Amélioration des performances de 0,1 ms

Bien, c'est bien, mais qu'est-ce que cela signifie pour moi? La performance de 0,1 ms ne me préoccupe pas tellement et je n'ai pas vraiment envie de télécharger et d'ajouter une autre dépendance à la bibliothèque pour des fonctionnalités que j'ai déjà.

Existe-t-il des exemples de cas où l'implémentation AntiXss empêcherait une attaque que l'implémentation d'HttpUtility ne ferait pas?

Si je continue à utiliser l'implémentation HttpUtility, suis-je à risque? Qu'en est-il de ce "bogue" ?

Answer 1

Je n'ai pas de réponse précise à votre question, mais je voudrais souligner que l'approche liste blanche / liste noire ne se limite pas à & "nice &"; C'est important. Très important. En matière de sécurité, tout est important. N'oubliez pas qu'avec les scripts intersites et la falsification de requêtes intersites . Même si votre site ne présente pas de données sensibles, un pirate informatique pourrait l’infecter en injectant du javascript et en l’utilisant pour obtenir des données sensibles d’un autre site. Il est donc essentiel de bien faire les choses.

Les directives OWASP spécifient l'utilisation d'une approche de liste blanche . Les directives de conformité PCI le spécifient également dans les normes de codage (car elles font référence aux directives OWASP).

De plus, la nouvelle version de la bibliothèque AntiXss a une nouvelle fonction intéressante: .GetSafeHtmlFragment (), ce qui est pratique dans les cas où vous souhaitez stocker du code HTML dans la base de données et le faire afficher sous forme HTML à l'utilisateur.

De même, comme pour le " bogue " ;, si vous codez correctement et respectez toutes les consignes de sécurité, vous utilisez des procédures stockées paramétrées, de sorte que les guillemets simples soient gérés correctement. Si vous ne codez pas correctement, aucune bibliothèque standard ne vous protégera pleinement. La bibliothèque AntiXss est censée être un outil à utiliser, pas un substitut à la connaissance. En vous fiant à la bibliothèque, vous vous attendez à ce qu'un très bon pinceau produise de bons tableaux sans un bon artiste.

Modifier - Ajouté

Comme demandé dans la question, un exemple de cas où l'anti xss vous protégera et où HttpUtility ne vous protégera pas:

HttpUtility.HtmlEncode et Server. HtmlEncode n'empêche pas les scripts entre sites

C'est selon l'auteur, cependant. Je ne l'ai pas testé personnellement.

Il semble que vous respectiez vos consignes de sécurité. Ce n'est donc peut-être pas quelque chose que je dois vous dire, mais juste au cas où un développeur moins expérimenté lirait ceci, la raison pour laquelle je dis que la liste blanche approche est critique est la suivante.

À l'heure actuelle, HttpUtility.HtmlEncode peut bloquer toutes les attaques, simplement en supprimant / encodant < et >, ainsi que quelques autres & "potentiellement dangereux" & "; caractères, mais quelqu'un essaie toujours de trouver de nouvelles façons d'intervenir. Autoriser uniquement le contenu connu comme sûr (liste blanche) est beaucoup plus facile que d'essayer de penser à toutes les informations potentiellement dangereuses qu'un attaquant pourrait éventuellement vous envoyer (noir). approche de liste).

Answer 2

En ce qui concerne la raison pour laquelle vous utiliseriez l'une sur l'autre, considérez que la bibliothèque AntiXSS est publiée plus souvent que le framework ASP.NET - car, comme le dit David Stratton, "quelqu'un essaie toujours de trouver de nouvelles façons de Dans ', quand quelqu'un en proposera une, la bibliothèque AntiXSS aura bien plus de chances de disposer d'une version mise à jour pour se défendre.

Answer 3

Les différences entre les méthodes Microsoft.Security.Application.AntiXss.HtmlEncode et System.Web.HttpUtility.HtmlEncode sont les suivantes:

1. Anti-XSS utilise la technique de la liste blanche, parfois appelée principe des inclusions, pour assurer une protection contre les attaques XSS (Cross-Site Scripting). Cette approche fonctionne en définissant d’abord un ensemble de caractères valide ou autorisé, puis en codant tout ce qui ne l’appartient pas (caractères non valides ou attaques potentielles). HttpUtility et d’autres méthodes de codage dans cet espace de noms utilisent le principe d’exclusions et ne codent que certains caractères désignés comme potentiellement dangereux, tels que < ;, > ;, & amp; et 'personnages.

2. La liste de caractères blancs (ou sécurisés) de la bibliothèque Anti-XSS prend en charge plus d’une douzaine de langues (grec et copte, cyrillique, supplément cyrillique, arménien, hébreu, arabe, syriaque, supplément arabe, thaana, nko et plus)

3. La bibliothèque Anti-XSS a été spécialement conçue pour limiter les attaques XSS alors que AntiXss.HtmlEncode() les méthodes de codage sont créées pour garantir que la sortie ASP.NET ne rompt pas le code HTML.

4. Performances - le delta moyen entre HttpUtility.HtmlEncode() et <=> est de +0,1 millisecondes par transaction.

5. Anti-XSS version 3.0 fournit un faisceau de tests permettant aux développeurs d'exécuter des tests de validation et de performance XSS.

Answer 4

La plupart des vulnérabilités XSS (n'importe quel type de vulnérabilité, en fait) sont uniquement basées sur le fait que la sécurité existante ne & "attend pas &"; certaines choses se passent. Les approches utilisant uniquement la liste blanche sont plus susceptibles de gérer ces scénarios par défaut.

Answer 5

Nous utilisons l'approche de la liste blanche pour les sites Windows Live de Microsoft. Je suis sûr qu'il y a un certain nombre d'attaques de sécurité auxquelles nous n'avons pas encore pensé, alors je suis plus à l'aise avec l'approche paranoïaque. Je soupçonne qu'il y a eu des cas où la liste noire a exposé des vulnérabilités que la liste blanche n'a pas, mais je ne pourrais pas vous donner les détails.