¿Por qué deberían los filtros XSS escapar de la barra diagonal?

Navega tus respuestas
16

En las recomendaciones de OWASP con respecto a 

& --> &
< --> &lt;
> --> &gt;
" --> &quot;
' --> &#x27;  &apos; not recommended because its not in the HTML spec (See: section 24.4.1) &apos; is in the XML and XHTML specs.
/ --> &#x2F;  forward slash is included as it helps end an HTML entity

¿Cuál es el propósito de incluir / allí? De hecho, / es parte de la entidad final, pero como ya estamos escapando de < y AFAIK ningún navegador conocido aceptaría / sin < anterior como entidad end, ¿cuál es la razón para escapar? / p>     

pregunta StasM 04.02.2014 - 00:53
fuente

4 respuestas

9

Antes de que HTML 5 viniera con un algoritmo de análisis estándar, se definió HTML 4 basado en SGML. Y su sintaxis basada en SGML tenía características que diferían en términos de compatibilidad con el navegador y diferían en cuanto a las personas que las conocían.

Una de las características más oscuras en las que estará interesado, a los efectos de esta pregunta, es Null End Tag (NET). Eche un vistazo al siguiente código para una página HTML: 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
  "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title/hello/
<body>
<p/hello/

Si lo desea, intente ponerlo en un validador de HTML . NET especifica que el código como <TAGNAME/text/ se analiza en la misma cosa que obtendría de <TAGNAME>text</TAGNAME> .

Desde aquí, puede ver por qué es una buena idea escapar del carácter / al interpolar los datos proporcionados por el usuario en el marcado. Un / podría potencialmente terminar en una de estas construcciones NET y ser interpretado como la etiqueta final, en lugar de un carácter sólido literal.

Seguro que ningún navegador ahora entiende la sintaxis de NET, pero es parte de la especificación, por lo que es prudente tenerla en cuenta.

    
respondido por el guest 15.02.2017 - 22:27
fuente
6

Su pregunta pregunta "¿Por qué / ?".

Sin embargo, parece que no estás preocupado por > , " y ' ?

Técnicamente, para garantizar la seguridad dentro del contenido del elemento, solo necesita codificar los caracteres < y & porque las etiquetas HTML no pueden comenzar con > , " , ' o / . Tenga en cuenta que solo estoy hablando de HTML aquí (no XHTML).

Para responder a su pregunta, el motivo es que / es un carácter HTML con un significado especial. Si está siguiendo las pautas de OWASP, se asume que desea que su sistema sea seguro y siempre es mejor errar por el lado de la precaución, ya que hay pocas desventajas de hacerlo en este caso.

Si desea ser minimalista, consulte OWASP XSS Reglas de codificación mínimas experimentales .

    
respondido por el SilverlightFox 04.02.2014 - 10:59
fuente
3

Cuando un personaje tiene un significado sintáctico en cualquier contexto, debes ser cauteloso y errar por el lado de escapar.

Si, por ejemplo, un atacante ha encontrado una forma de inyectarlo al final de alguna etiqueta existente, puede crear una etiqueta como <br /> que no requiere finalización; la transformación podría cambiar el significado del documento.

Pido disculpas por no tener un ejemplo concreto para ti más allá de eso, pero cuesta muy poco escapar de él, por lo que la compensación es ciertamente a favor de hacerlo.

No veo ninguna razón particular para ello, además de una protección contra otros errores o errores que se pueden explotar con esta inclusión en particular. No es una recomendación especialmente fuerte, ya que ningún PoC puede desarrollarse universalmente para mostrar su necesidad, pero no hay ningún daño al seguirlo.

    
respondido por el Falcon Momot 04.02.2014 - 01:03
fuente
2

"por lo que sé ..." es la raíz de muchos errores, al no poder codificar caracteres peligrosos. Es el enfoque de la "lista negra" para codificar solo las cosas que sabes que son peligrosas en lugar de no codificar solo las cosas que sabes que no son peligrosas.

Por ejemplo, imagine que el servidor establece el valor de un atributo de etiqueta HTML a la entrada del usuario ... 

<input value=userdata>

Lo anterior es completamente legal y HTML válido. Muchas páginas web no encapsulan sus valores entre comillas, y los navegadores interpretan esto correctamente.

Ahora, suponga que utiliza la lista OWASP que incluyó en la parte superior de la página. Tenga en cuenta que el espacio no está en la lista .... 

<input value=foo onclick=alert()>

Ahora tenemos un ataque exitoso. Hemos utilizado el espacio para salir del contexto anterior, luego el signo de igual para establecer un contexto donde podemos escribir javascript y paréntesis para ejecutar una función. Ninguno de estos estaba en la lista negra (rota) que mostraste.

Con este mismo ataque (usando el espacio para salir), el símbolo / se puede usar como parte del contenido de javascript como signo de división, parte de un comentario (// o / *) o de otras maneras. La hoja de trucos de evasión del filtro OWASP ( enlace ) tiene una buena lista de cadenas de ataque que usan diferentes caracteres, dependiendo de lo que sea o no está codificado, y para diferentes contextos. El carácter de guión (-) se puede usar para el marcado XUL contra mozilla.

El hecho de que no pueda ver dónde sería un problema nunca es suficiente. DEBES saber que nunca puede ser un problema antes de dejarlo pasar. Como puede ver con el ejemplo anterior, incluso OWASP no pudo predecir cierto uso válido de los datos del usuario, y sus instrucciones de codificación estaban incompletas.

Lo seguro es codificar siempre todo, pero aquello que no puede ser perjudicial. En general, es seguro codificar todos los caracteres ASCII no alfanuméricos debajo del punto de caracteres 127 y dejar que todo lo demás quede sin codificar. Menos que esto invita a errores como el descrito anteriormente.

    
respondido por el atk 04.02.2014 - 02:20
fuente

Lea otras preguntas en las etiquetas

¿Es seguro incluir el esquema de datos en su Política de seguridad de contenido? Si encuentro o creo un exploit de 0 días, ¿puedo ser responsable de liberarlo al público?