Prise en charge de XSS dans ASP.net Vs AntiXss Lib

Comment la prise en charge de XSS (Cross Site Scripting) fournie par ASP.net diffère-t-elle d'AntiXss. AntiXss est une bibliothèque Microsoft pour sécuriser votre site contre XSS. Les deux API semblent presque similaires et il semble qu'ils peuvent facilement être changés d'un à l'autre en faisant trouver replace dans vos fichiers de code.Prise en charge de XSS dans ASP.net Vs AntiXss Lib

Lequel offre plus de sécurité contre XSS? Est-il souhaitable d'utiliser le support intrinsèque fourni par ASP.net?

Source

2010-08-09 Anand Patel

Il existe plusieurs différences. Tout d'abord, la bibliothèque Microsoft AntiXss utilise le codage de la liste blanche, ce qui signifie que tous les caractères sont codés, à l'exception de tous les caractères connus comme sûrs. Le mécanisme de codage standard d'ASP.NET est la liste noire. Pour le codage HTML par exemple, il code seulement 4 caractères: <, >, & et " (par exemple, il n'encode pas le guillemet simple). Regardez par exemple au this SO answer ce qui peut mal tourner avec ça.

Une autre différence est que le codage ASP.NET de base (en utilisant le HttpUtility) est uniquement capable d'encoder les URL en HTML. AntiXss permet également l'encodage des attributs HTML et du texte JavaScript. Il n'y a aucun moyen sûr de faire avec ASP.NET standard.

Source

2010-08-09 07:07:56 Steven

Si je ne recherche que l'encodage html et url, est-ce qu'il serait prudent d'utiliser le support intrinsèque d'ASP.net plutôt que de créer une dépendance sur AntiXSS? Quel est ton consseille. –

L'encodage de la liste blanche est par définition plus sûr que l'encodage de la liste noire, il est donc sage d'utiliser la bibliothèque 'AntiXss'. Toutefois, lorsque vous utilisez ASP.NET 4.0, vous pouvez laisser l'infrastructure utiliser la bibliothèque 'AntiXss' sous les couvertures lorsque vous utilisez la méthode' HttpUtility.HtmlEncode'. Cela vous évite d'avoir une dépendance directe sur la bibliothèque et permet à l'ensemble de la pile de contrôles ASP.NET d'utiliser cette bibliothèque. Voir ce blog pour plus d'informations: http://idunno.org/archive/2010/04/07/replacing-the-asp.net-encoder-with-antixss.aspx. – Steven

Vous devriez noter que l'implémentation de la classe 4.0 signifie toujours que vous devrez avoir la dépendance. Alors que le framework a un encodage HtmlAttribute et a, à partir de la version 4.0, un code Javascript, il utilise toujours une liste noire plutôt qu'une liste blanche. Bien sûr, cela signifie que les versions du framework peuvent être plus rapides, mais AntiXSS devrait être intrinsèquement plus sûr. – blowdart

Une chose que vous devez garder à l'esprit est les cycles de libération; le codage intégré à HttpUtility peut uniquement être mis à jour lorsqu'une nouvelle version d'ASP.NET est publiée. Si quelqu'un propose une attaque XSS qui fonctionne contre HttpUtility le lendemain de sa publication, votre application est vulnérable jusqu'à ce qu'une nouvelle version d'ASP.NET soit publiée. AntiXSS a un cycle de libération (beaucoup) plus rapide, ce qui signifie que lorsque de nouvelles attaques apparaissent, l'équipe peut y réagir plus rapidement et publier un AntiXSS mis à jour qui se défend contre eux.

Source

2010-08-09 08:38:21 PhilPursglove

Prise en charge de XSS dans ASP.net Vs AntiXss Lib

Répondre

Questions connexes