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

Question

Acabo de funcionar a través de una pregunta con una respuesta que sugiere la biblioteca AntiXSS para evitar este tipo de ataque. Suena interesante, al leer el msdn blog, 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, yo no soy el primero en hacer esta pregunta. Y, de hecho, Google se convierte en imagen someanswers, principalmente

• Una lista blanca en lugar de enfoque de lista de negro
• una mejora del rendimiento 0,1 ms

Bueno, eso es bueno, pero lo que lo hace significa para mí? No me importa tanto 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 prevendría un ataque que la implementación de HttpUtility no haría?

Si sigo usando la aplicación HttpUtility, ¿estoy en riesgo? ¿Qué hay de this 'bug'?

Answer 1

que no tienen una respuesta específica a su pregunta, pero me gustaría señalar que la lista blanca vs enfoque de la lista negro no sólo "buena". 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 está mostrando los datos sensibles, un hacker podría infectar a su sitio mediante la inyección de javascript y lo utilizan para obtener datos confidenciales de otro sitio. Hacerlo bien es crítico.

OWASP guidelines specify using a white list approach. Las pautas de Cumplimiento de PCI también especifican esto en estándares de codificación (ya que se refieren a las directrices de OWASP).

Además, la versión más nueva de la biblioteca AntiXss tiene una nueva y agradable función: .GetSafeHtmlFragment() que es agradable 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 , ninguna biblioteca extravagante lo protegerá por completo. La biblioteca AntiXss pretende ser una herramienta para ser utilizada, no un sustituto del conocimiento. Confiando en que la biblioteca lo haga bien para usted, esperaría un pincel realmente bueno para producir buenas pinturas sin un buen artista.

Editar - Añadido

Como se le preguntó en la pregunta, un ejemplo de que la lucha contra XSS le protegerá y HttpUtility no:

HttpUtility.HtmlEncode and Server. HtmlEncode do not prevent Cross Site Scripting

Esto es según el autor, aunque . No lo he probado personalmente

---

Suena como si estuviera arriba en sus directrices de seguridad, por lo que este puede no ser algo que tengo que decirte, pero sólo en caso de un desarrollador con menos experiencia está por ahí leyendo esto, la razón por la que digo que el enfoque de lista blanca es crítico es esto.

En este momento, hoy en día, HttpUtility.HtmlEncode puede bloquear con éxito todos los ataques por ahí, simplemente quitando/codificación < y >, además de algunos otros personajes conocidos "potencialmente peligrosos", pero siempre hay alguien que está tratando de pensar en nuevas formas de entrar. Permitir solo contenido conocido seguro (lista blanca) es mucho más fácil que tratar de pensar en cada posible entrada insegura que un atacante podría lanzarle (enfoque de lista negra).

Answer 2

Utilizamos el enfoque de lista blanca para los sitios Windows Live de Microsoft. Estoy seguro de que hay varios ataques de seguridad que aún no hemos pensado, por lo 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 tenía, pero no pude decirle los detalles.

Answer 3

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

Answer 4

La mayoría de las vulnerabilidades XSS (cualquier tipo de vulnerabilidad, en realidad) se basan simplemente 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.

Answer 5

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

1. Anti-XSS utiliza la técnica de la lista blanca, a veces conocido como el principio de inclusiones, para proporcionar protección contra Cross-Site Scripting (XSS) ataques. Este enfoque funciona definiendo primero un conjunto de caracteres válido o admisible y codifica todo lo que esté 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 usan el principio de exclusiones y codifican solo ciertos caracteres designados como potencialmente peligrosos como <,>, & 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, 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 los métodos de codificación HttpUtility se crean para garantizar que la salida de ASP.NET no rompa HTML.

4. Rendimiento - el promedio delta 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 validación XSS y pruebas de rendimiento.