Cuál es la diferencia entre AntiXSS.HtmlEncode y HttpUtility.¿HtmlEncode?

Acabo de encontrar una pregunta con una respuesta que sugiere la biblioteca AntiXSS para evitar el scripting entre sitios. Sonó interesante, leyendo el blog msdn , parece que solo proporciona un método HtmlEncode (). Pero ya uso HttpUtility.HtmlEncode().

¿Por qué querría usar AntiXSS?HtmlEncode sobre HttpUtility.¿HtmlEncode?

De hecho, no soy el primero en hacer esta pregunta. Y, de hecho, Google aparece algunos respuestas , principalmente

  • Un enfoque de lista blanca en lugar de lista negra
  • Una mejora del rendimiento de 0.1 ms

Bueno, eso está bien, pero ¿qué significa para mí? No me importa mucho el rendimiento de 0.1 ms y realmente no tengo ganas de descargar y agregar otra dependencia de biblioteca para la funcionalidad que ya tengo.

¿Hay ejemplos de casos en los que la implementación de AntiXSS evitaría un ataque que la implementación de HttpUtility evitaría? no?

Si continúo usando la implementación HttpUtility, ¿estoy en riesgo? ¿Qué pasa con este 'bug'?

Author: animuson, 2009-10-22
Source

5 answers

No tengo una respuesta específica a su pregunta, pero me gustaría señalar que el enfoque de la lista blanca vs lista negra no solo es "agradable". Es importante. Muy importante. Cuando se trata de seguridad, cada pequeña cosa es importante. Recuerde que con cross-site scripting y cross-site request forgery, incluso si su sitio no muestra datos confidenciales, un hacker podría infectar su sitio inyectando javascript y usarlo para obtener datos confidenciales de otro sitio. Hacerlo lo correcto es crítico.

Las directrices de OWASP especifican el uso de un enfoque de lista blanca . Las directrices de cumplimiento de PCI también especifican esto en las normas de codificación (ya que se refieren a las directrices de OWASP).

Además, la nueva versión de la biblioteca AntiXSS tiene una nueva función: .GetSafeHtmlFragment () que es bueno para aquellos casos en los que desea almacenar HTML en la base de datos y que se muestre al usuario como HTML.

También, en cuanto al "error", si está codificando correctamente y siguiendo todas las pautas de seguridad, está utilizando procedimientos almacenados parametrizados, por lo que las comillas simples se manejarán correctamente, si no está codificando correctamente, ninguna biblioteca disponible lo protegerá completamente. La biblioteca AntiXSS está destinada a ser una herramienta a ser utilizada, no un sustituto del conocimiento. Confiar en la biblioteca para hacerlo bien para usted estaría esperando un pincel realmente bueno para producir buenas pinturas sin un buen artista.

Editar-Añadido

As preguntado en la pregunta, un ejemplo de donde el anti xss te protegerá y HttpUtility no:

HttpUtility.HtmlEncode y Servidor. HtmlEncode no impide Cross Site Scripting

Eso es según el autor, sin embargo. No lo he probado personalmente.

Suena como que estás al tanto de tus pautas de seguridad, por lo que esto puede no ser algo que tenga que decirte, pero en caso de que un desarrollador menos experimentado esté leyendo esto, la razón por la que digo que el enfoque de la lista blanca es crítico es esto.

Ahora mismo, hoy, HttpUtility.HtmlEncode puede bloquear con éxito todos los ataques que existen, simplemente eliminando / encoding < y >, además de algunos otros caracteres "conocidos potencialmente inseguros", pero alguien siempre está tratando de pensar en nuevas formas de entrar. Permitir solo contenido seguro conocido (lista blanca) es mucho más fácil que tratar de pensar en cada posible bit inseguro de entrada que un atacante podría lanzarte (lista negra enfoque).

 29
Author: David,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-05-20 15:21:19

En términos de por qué usaría uno sobre el otro, considere que la biblioteca AntiXSS se libera más a menudo que la ASP.NET framework-dado que, como dice David Stratton, "alguien siempre está tratando de pensar en nuevas formas de entrar", cuando alguien se le ocurre uno, la biblioteca AntiXSS es mucho más probable que obtenga una versión actualizada para defenderse de él.

 12
Author: PhilPursglove,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-10-23 13:50:34

Las siguientes son las diferencias entre los métodos Microsoft.Security.Application.AntiXss.HtmlEncode y System.Web.HttpUtility.HtmlEncode:

  1. Anti-XSS utiliza la técnica de lista blanca, a veces conocida como el principio de inclusiones, para proporcionar protección contra ataques de Cross-Site Scripting (XSS). Este enfoque funciona definiendo primero un conjunto de caracteres válido o permitido, y codifica cualquier cosa fuera de este conjunto (caracteres no válidos o ataques potenciales). System.Web.HttpUtility.HtmlEncode y otros métodos de codificación en ese espacio de nombres utilizan el principio de exclusiones y codificar solo ciertos caracteres designados como potencialmente peligrosos, tales como caracteres, & y'.

  2. La lista de caracteres blancos (o seguros) de la Biblioteca Anti-XSS admite más de una docena de idiomas (Griego y Copto, Cirílico, Suplemento Cirílico, Armenio, Hebreo, Árabe, Siríaco, Suplemento Árabe, Thaana, NKo y más)

  3. La biblioteca Anti-XSS se ha diseñado especialmente para mitigar los ataques XSS, mientras que HttpUtility los métodos de codificación se crean para garantizar que ASP.NET la salida no rompe HTML.

  4. Rendimiento: el delta medio entre AntiXss.HtmlEncode() y HttpUtility.HtmlEncode() es de +0,1 milisegundos por transacción.

  5. Anti-XSS Versión 3.0 proporciona un arnés de prueba que permite a los desarrolladores ejecutar pruebas de validación y rendimiento de XSS.

 7
Author: rahul sharma,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-10-17 21:02:26

La mayoría de las vulnerabilidades XSS (cualquier tipo de vulnerabilidad, en realidad) se basan puramente en el hecho de que la seguridad existente no "esperaba" que sucedieran ciertas cosas. Los enfoques de solo lista blanca son más aptos para manejar estos escenarios de forma predeterminada.

 4
Author: Chris,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-10-23 14:01:07

Utilizamos el enfoque de lista blanca para los sitios de Windows Live de Microsoft. Estoy seguro de que hay cualquier número de ataques de seguridad que no hemos pensado todavía, así que estoy más cómodo con el enfoque paranoico. Sospecho que ha habido casos en los que la lista negra expuso vulnerabilidades que la lista blanca no, pero no podría decirte los detalles.

 3
Author: Bruce,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-10-22 18:01:15