asp.net - ¿Cuál es la diferencia entre AntiXss.HtmlEncode y HttpUtility.HtmlEncode?

html-encode antixsslibrary

Question

Acabo de encontrar una pregunta con una respuesta que sugiere la biblioteca AntiXss para evitar las secuencias de comandos entre sitios. Parecía interesante, al leer 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, efectivamente, Google encuentra some answers , principalmente.

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

Bueno, eso está bien, pero ¿qué significa para mí? No me importa mucho el rendimiento de 0.1ms 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 no evitaría?

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

Answer 1

En términos de por qué usaría uno sobre el otro, considere que la biblioteca AntiXSS se publica más a menudo que el marco ASP.NET, ya que, como dice David Stratton, "alguien siempre está tratando de pensar en nuevas formas de romper", cuando alguien crea una, es mucho más probable que la biblioteca AntiXSS obtenga una versión actualizada para defenderse de ella.

Answer 2

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

Answer 3

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

1. Anti-XSS utiliza la técnica de la lista blanca, a veces conocida como el principio de inclusiones, para brindar protección contra los ataques de secuencias de comandos entre sitios (XSS). Este enfoque funciona al definir primero un conjunto de caracteres válido o permisible, y codifica cualquier cosa fuera de este conjunto (caracteres no válidos o posibles ataques). System.Web.HttpUtility.HtmlEncode y otros métodos de codificación en ese espacio de nombres utilizan el principio de exclusiones y codifican solo ciertos caracteres designados como potencialmente peligrosos, como <,> y & y ''caracteres.

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, árabe, Thaana, NKo y más)

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

4. Rendimiento: el delta promedio entre AntiXss.HtmlEncode() y HttpUtility.HtmlEncode() es de +0.1 milisegundos por transacción.

5. La versión 3.0 de Anti-XSS proporciona un arnés de prueba que permite a los desarrolladores ejecutar tanto la validación XSS como las pruebas de rendimiento.

Answer 4

No tengo una respuesta específica a su pregunta, pero me gustaría señalar que el enfoque de lista blanca frente a lista negra no solo es "bueno". Es importante. Muy importante. Cuando se trata de seguridad, todo es importante. Recuerde que con las secuencias de comandos entre sitios y la falsificación de solicitudes entre sitios , incluso si su sitio no muestra datos confidenciales, un pirata informático podría infectar su sitio inyectando javascript y utilizarlo para obtener datos confidenciales de otro sitio. Así que hacerlo bien es crítico.

Las pautas de OWASP especifican el uso de un enfoque de lista blanca . Las pautas de cumplimiento de PCI también lo especifican en los estándares de codificación (ya que se refieren a las pautas de OWASP).

Además, la versión más reciente de la biblioteca de AntiXss tiene una nueva y agradable función: .GetSafeHtmlFragment () que es buena para aquellos casos en los que desea almacenar HTML en la base de datos y mostrarlo al usuario como HTML.

Además, 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, no haga falta. La biblioteca de estantería te protegerá por completo. La biblioteca AntiXss está destinada a ser una herramienta para ser utilizada, no un sustituto del conocimiento. Confiando en la biblioteca para hacerlo bien, usted esperaría que un pincel realmente bueno produzca buenos cuadros sin un buen artista.

Editar - Añadido

Como se preguntó en la pregunta, un ejemplo de dónde el anti xss lo protegerá y HttpUtility no:

HttpUtility.HtmlEncode y servidor. HtmlEncode no previene los scripts de sitios cruzados

Sin embargo, eso es de acuerdo con el autor. No lo he probado personalmente.

Parece que estás al tanto de tus pautas de seguridad, por lo que puede que esto no sea algo que deba decirte, pero en caso de que un desarrollador con menos experiencia esté leyendo esto, la razón por la que digo que el enfoque de lista blanca es fundamental Es esto.

En este momento, hoy, HttpUtility.HtmlEncode puede bloquear con éxito todos los ataques, simplemente eliminando / codificando < y > , además de algunos otros caracteres "conocidos potencialmente inseguros", pero siempre hay alguien que intenta pensar en nuevas formas de romper. Permitir solo contenido seguro (lista blanca) es mucho más fácil que pensar en cada bit de entrada inseguro posible que un atacante pueda lanzarle (enfoque de lista negra).

Answer 5

Utilizamos el enfoque de lista blanca para los sitios Windows Live de Microsoft. Estoy seguro de que hay muchos ataques de seguridad que aún no hemos pensado, así que me siento más cómodo con el enfoque paranoico. Sospecho que ha habido casos en que la lista negra expuso vulnerabilidades que la lista blanca no lo hizo, pero no pude decirles los detalles.