está convirtiendo '' a '<' ¿Es suficiente para evitar la ejecución de JavaScript desde HTML arbitrario?

Navega tus respuestas
6

Esta es una especie de pregunta de apuesta. Un conocido mío ha afirmado que, dado un globo arbitrario de HTML, se puede evitar que completamente se ejecute JavaScript si, antes de incluirlo en una página web, reemplaza todas las instancias de < con &lt; - y no realice otros cambios.

No estoy convencido de que mi relación sea correcta, pero tampoco puedo pensar en un contraejemplo. ¿Alguien puede probar o refutar?

Aclaración: suponga que el escape ocurre en el lado del servidor, y el globo se inserta como el contenido de un elemento normal, por ejemplo, 

<p>{{ GLOB GOES HERE }}</p>

También, asuma un cliente que implementa el algoritmo del analizador HTML5, correctamente; no nos preocupan los errores, los analizadores heredados o los escenarios que se aplican solo en XML o SGML.

Más aclaraciones: las reglas de OWASP son deliberadamente conservadoras. Debido a que esta es una apuesta de barra, queremos una respuesta pedante , no una respuesta conservadora.

    
pregunta zwol 26.11.2014 - 03:45
fuente

5 respuestas

5

Dentro del elemento, el modo de análisis está en estado de datos. Los únicos caracteres especiales que pueden escapar del estado de los datos son < y & ( enlace sec .8.2.4.1).

Si reemplazas todas las instancias de < con &lt; , solo necesitas preocuparte por & .

En HTML4 y XML, deberías considerar qué referencias de entidad están disponibles para ser reemplazadas, y si alguna de ellas podría usarse para inyectar un script u otro vector de ataque. Esto podría ser un problema, por ejemplo, si el marcado se refiere a una DTD externa y el atacante puede redirigir una descarga de red de la DTD externa a una de su elección. Esta es una de las razones por las que muchos analizadores XML y HTML no van a la red para resolver los identificadores del sistema.

Sin embargo, HTML5 solo permite que & se use para entidades de caracteres, ninguna de las cuales puede usarse para escapar del modo de datos.

Por lo tanto, en ausencia de errores en el analizador y en el marcado, su conocimiento es correcto.

    
respondido por el Jonathan Giddy 30.11.2014 - 09:07
fuente
5

Depende de dónde se impriman los datos dentro del documento HTML, ya que hay diferentes contextos dentro de diferentes reglas . Reemplazar un < literal por &lt; solo es viable cuando < es un carácter especial, lo que cambiaría el estado de análisis actual.

Hay una descripción general rápida de reglas de prevención en XSS (Cross Site Scripting) de OWASP Hoja de trucos para la prevención , que debería darte una pista de lo que debes saber.

    
respondido por el Gumbo 26.11.2014 - 08:36
fuente
4

Depende de muchos factores.

Si la entrada maliciosa (toda la entrada del usuario es maliciosa por defecto) se refleja solo en su cuerpo HTML y su servidor envía los encabezados "Tipo de contenido: texto / html; conjunto de caracteres = utf-8" y "Contenido X" Tipo-Opciones: nosniff ", la respuesta es sí, este método es lo suficientemente seguro.

Cuando digo cuerpo HTML, supongo que estás haciendo eco de la entrada a <html><body>INPUT_HERE</body></html>.

Si acaba de transmitir la entrada a una página en blanco, sin unos pocos bytes antes de la entrada, se puede usar el ataque de Rosetta Flash.

    
respondido por el Lucas NN 26.11.2014 - 03:49
fuente
4

Esta es una muy mala práctica. Estás manteniendo una lista negra. Pero la forma recomendada es mantener una lista blanca que proporcione solo los caracteres permitidos después de un filtro.

La respuesta a tu pregunta es, < puede codificarse en hexadecimal y escribir en otros esquemas codificados. Entonces, simplemente reemplazar < con &lt; no sería adecuado.

    
respondido por el Kasun 26.11.2014 - 06:28
fuente
1

¿Dónde estás analizando el < ? Si está en el cliente, entonces solo tiene quizás detenido un hacker de diez años ( pero no este hacker de diez años ).

Sin embargo, si está analizando el código ejecutable del lado del servidor, entonces sí, efectivamente detuvo esta forma particular de inyección, aunque hay formas más completas y seguras de hacer esto.

Quizás me esté perdiendo la esencia de tu pregunta, así que si simplemente estás preguntando si puedes reemplazar todas las instancias de < con (cualquier otra cosa), entonces la respuesta es sí. Sí, de forma predeterminada, esto evitará que todas las etiquetas de javascript se analicen y ejecuten porque la entidad de caracteres &lt; no se procesa cuando se carga el DOM.

Aquí hay una referencia para cumplir con lo que puede pedir. Dejé mi primer bit arriba porque todavía es importante.

    
respondido por el Matthew Peters 26.11.2014 - 04:30
fuente

Lea otras preguntas en las etiquetas

Usando una sola aplicación para usuario y administrador (con diferentes métodos de autenticación) vs separándolos en dos aplicaciones ¿Por qué no podemos hacer ataques MiTM cuando utilizamos una conexión segura?