¿La codificación HTML evitará todo tipo de ataques XSS?

https://stackoverflow.com/questions/53728

09-06-2019
|

Pregunta

No me preocupan otros tipos de ataques.Sólo quiero saber si HTML Encode puede prevenir todo tipo de ataques XSS.

¿Hay alguna forma de realizar un ataque XSS incluso si se utiliza codificación HTML?

Solución

No.

Dejando de lado el tema de permitir algunas etiquetas (no es realmente el punto de la pregunta), HtmlEncode simplemente NO cubre todos los ataques XSS.

Por ejemplo, considere el javascript del lado del cliente generado por el servidor: el servidor genera dinámicamente valores codificados en html directamente en el javascript del lado del cliente, htmlencode no te detengas script inyectado desde su ejecución.

A continuación, considere el siguiente pseudocódigo:

<input value=<%= HtmlEncode(somevar) %> id=textbox>

Ahora, en caso de que no sea inmediatamente obvio, si somevar (enviado por el usuario, por supuesto) está configurado, por ejemplo, en

a onclick=alert(document.cookie)

la salida resultante es

<input value=a onclick=alert(document.cookie) id=textbox>

lo que claramente funcionaría.Obviamente, este puede ser (casi) cualquier otro script...y HtmlEncode no ayudaría mucho.

Hay algunos vectores adicionales a considerar...incluido el tercer tipo de XSS, llamado XSS basado en DOM (en el que el script malicioso se genera dinámicamente en el cliente, p. ej.Basado en Valores).

Tampoco se olvide de los ataques de tipo UTF-7: cómo se ve el ataque

+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-

No hay mucho que codificar allí...

La solución, por supuesto (además de la validación de entrada de lista blanca adecuada y restrictiva), es realizar sensible al contexto codificación:HtmlEncoding es excelente SI su contexto de salida ES HTML, o tal vez necesita JavaScriptEncoding, o VBScriptEncoding, o AttributeValueEncoding, o...etc.

Si está utilizando MS ASP.NET, puede utilizar su biblioteca Anti-XSS, que proporciona todos los métodos de codificación de contexto necesarios.

Tenga en cuenta que toda la codificación no debe limitarse a la entrada del usuario, sino también a los valores almacenados de la base de datos, archivos de texto, etc.

Ah, y no olvides configurar explícitamente el juego de caracteres, tanto en el encabezado HTTP como en la etiqueta META; de lo contrario, seguirás teniendo vulnerabilidades UTF-7...

Más información y una lista bastante definitiva (actualizada constantemente), consulte la hoja de referencia de RSnake: http://ha.ckers.org/xss.html

Otros consejos

Si codifica sistemáticamente todas las entradas del usuario antes de mostrarlas ~~entonces si, estás a salvo~~ todavía no estás 100% seguro.
(Consulte la publicación de @Avid para obtener más detalles)

Además surgen problemas cuando es necesario dejar alguno Las etiquetas no están codificadas para permitir a los usuarios publicar imágenes o texto en negrita o cualquier característica que requiera que la entrada del usuario se procese como (o se convierta en) marcado no codificado.

Tendrá que configurar un sistema de toma de decisiones para decidir qué etiquetas están permitidas y cuáles no, y siempre es posible que alguien encuentre una manera de dejar pasar una etiqueta no permitida.

Ayudará si sigues el consejo de Joel de Hacer que el código incorrecto parezca incorrecto o si tu idioma te ayuda advirtiendo/no compilando cuando está generando datos de usuario sin procesar (escritura estática).

Si codifica todo, lo hará.(dependiendo de su plataforma y de la implementación de htmlencode) Pero cualquier aplicación web útil es tan compleja que es fácil olvidarse de verificar cada parte de ella.O tal vez un componente de terceros no sea seguro.O tal vez alguna ruta de código que aunque codificaste no lo hizo, por lo que la olvidaste en otro lugar.

Por lo tanto, es posible que también desee verificar las cosas en el lado de entrada.Y es posible que desee comprobar el contenido que lee en la base de datos.

Como lo mencionaron todos los demás, estás a salvo siempre que codifiques todo entrada del usuario antes de mostrarla.Esto incluye todos los parámetros de solicitud y los datos recuperados de la base de datos que se pueden cambiar mediante la entrada del usuario.

Como mencionado por Pat A veces querrás mostrar algunas etiquetas, pero no todas.Una forma común de hacer esto es usar un lenguaje de marcado como Textil, Reducción, o Código BBC.Sin embargo, incluso los lenguajes de marcado pueden ser vulnerables a XSS, solo tenga en cuenta.

# Markup example
[foo](javascript:alert\('bar'\);)

Si decide permitir el paso de etiquetas "seguras", le recomendaría buscar alguna biblioteca existente para analizar y desinfectar su código antes de generarlo.Hay muchos vectores XSS existen que tendrías que detectar antes de que tu desinfectante sea bastante seguro.

Secundo el consejo de metavida de encontrar una biblioteca de terceros para manejar el filtrado de salida.Neutralizar los caracteres HTML es un buen método para detener los ataques XSS.Sin embargo, el código que utiliza para transformar metacaracteres puede ser vulnerable a ataques de evasión;por ejemplo, si no maneja adecuadamente Unicode y la internacionalización.

Un error clásico y simple que cometen los filtros de salida caseros es capturar solo < y >, pero omitir cosas como ", lo que puede dividir la salida controlada por el usuario en el espacio de atributos de una etiqueta HTML, donde Javascript se puede adjuntar al DOM.

No, simplemente codificar tokens HTML comunes NO protege completamente su sitio de ataques XSS.Vea, por ejemplo, esta vulnerabilidad XSS encontrada en google.com:

http://www.securiteam.com/securitynews/6Z00L0AEUE.html

Lo importante de este tipo de vulnerabilidad es que el atacante puede codificar su carga útil XSS usando UTF-7, y si no ha especificado una codificación de caracteres diferente en su página, el navegador de un usuario podría interpretar la carga útil UTF-7 y ejecutar el script de ataque.

Otra cosa que debes verificar es de dónde proviene tu entrada.Puede usar la cadena de referencia (la mayor parte del tiempo) para verificar que proviene de su propia página, pero ingresar un número aleatorio oculto o algo en su formulario y luego verificarlo (tal vez con una variable de configuración de sesión) también ayuda a saber que el la entrada proviene de su propio sitio y no de algún sitio de phishing.

Me gustaría sugerir HTML Purifier (http://htmlpurificador.org/) No solo filtra el html, básicamente lo tokeniza y lo vuelve a compilar.Es verdaderamente fuerza industrial.

Tiene el beneficio adicional de permitirle garantizar una salida html/xhtml válida.

Tampoco es nada textil, es una gran herramienta y la uso todo el tiempo, pero también la uso a través del purificador html.

No creo que hayas entendido lo que quise decir con respecto a las fichas.HTML Purifier no sólo "filtra", sino que en realidad reconstruye el HTML. http://htmlpurifier.org/comparison.html

No lo creo.Html Encode convierte todos los caracteres funcionales (caracteres que el navegador podría interpretar como código) en referencias de entidades que el navegador no puede analizar y, por lo tanto, no se pueden ejecutar.

&lt;script/&gt;

No hay forma de que el navegador pueda ejecutar lo anterior.

**A menos que haya un error en el navegador, por supuesto.*

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow