¿Hay otras secuencias que los navegadores interpretan como caracteres especiales HTML?

En HTML, hay varios caracteres especiales < > & ' " que tienen importancia para el analizador DOM. Estos son los personajes con los que las funciones populares como PHP htmlspecialchars se convierten en entidades HTML para que no se activen accidentalmente cuando se analizan.¿Hay otras secuencias que los navegadores interpretan como caracteres especiales HTML?

Las traducciones realizadas son:

'&' (ampersand) se convierte en &

" (comillas dobles) se convierte en " cuando ENT_NOQUOTES no está establecido.

' (comilla simple) se convierte en ' solo cuando se establece ENT_QUOTES.

'<' (menos) se convierte en <

'>' (mayor que) se convierte en >

Sin embargo, recuerdo que en los navegadores antiguos como IE6, también hubo otras secuencias de bytes que causó el analizador DOM del navegador a interpret content as HTML.

¿Sigue siendo un problema hoy? Si filtra estos 5 solo ¿es eso suficiente para evitar XSS?

Por ejemplo, aquí están todos los conocidos combinaciones del carácter "<" en HTML y JavaScript (en UTF-8).

< 
%3C 
&lt 
&lt; 
&LT 
&LT; 
&#60 
&#060 
&#0060 
&#00060 
&#000060 
&#0000060 
&#60; 
&#060; 
&#0060; 
&#00060; 
&#000060; 
&#0000060; 
&#x3c 
&#x03c 
&#x003c 
&#x0003c 
&#x00003c 
&#x000003c 
&#x3c; 
&#x03c; 
&#x003c; 
&#x0003c; 
&#x00003c; 
&#x000003c; 
&#X3c 
&#X03c 
&#X003c 
&#X0003c 
&#X00003c 
&#X000003c 
&#X3c; 
&#X03c; 
&#X003c; 
&#X0003c; 
&#X00003c; 
&#X000003c; 
&#x3C 
&#x03C 
&#x003C 
&#x0003C 
&#x00003C 
&#x000003C 
&#x3C; 
&#x03C; 
&#x003C; 
&#x0003C; 
&#x00003C; 
&#x000003C; 
&#X3C 
&#X03C 
&#X003C 
&#X0003C 
&#X00003C 
&#X000003C 
&#X3C; 
&#X03C; 
&#X003C; 
&#X0003C; 
&#X00003C; 
&#X000003C; 
\x3c 
\x3C 
\u003c 
\u003C

Fuente

2011-12-24 Xeoncross

No. realidad se veía en esto cuando estaba investigando el uso de CSS y los atributos para asignar automáticamente estilos basados en el contenido (my question), y la respuesta corta es no. Los navegadores modernos no permiten que las "secuencias de bytes" se usen como HTML. Yo uso 'secuencias de bytes' ligeramente porque el código de mayor riesgo no usa valores codificados por bytes.

Los ejemplos enumerados en el sitio XSS tratan sobre el uso de atributos y la interpretación de javascript como una cadena que necesitaría ejecución. Pero también se enumeran cosas como &{alert('XSS')} que ejecuta el código entre corchetes, y ese código no funciona en los navegadores modernos.

Pero para responder a su segunda pregunta, no, filtrar esos 5 no es suficiente para evitar un ataque XSS. Lanza tu código a través del código de caracteres especiales HTML de PHP siempre pero hay un hundreds of byte codes that can be used y no podrás garantizar nada. Enviarlo a través de un filtro de PHP (especialmente htmlentities()) le dará el texto exacto ingresado cuando lo envíe a HTML (IE « en lugar de «). Dicho esto, en la mayoría de los casos, dependiendo de su uso, usar htmlspecialchars es suficiente para cubrir más ataques. Depende de cómo va a utilizar la entrada, pero en su mayor parte será seguro.

XSS es algo complicado de explicar. Una buena regla general es siempre filtrar todo lo que un usuario ingresará. Y use una lista blanca en lugar de una lista negra.De lo que hablas aquí sería una lista negra de estos valores, cuando siempre es más seguro suponer que tus usuarios son maliciosos y solo permiten ciertas cosas.

Fuente

2011-12-24 19:15:39 Ktash

omfg @ 'attribute =" & {alert ('XSS')} '' solía funcionar. – goat

Netscape fue el último navegador que encontré con documentación de que esto funcionó realmente, aunque creo que funcionó en IE 5 y algunos otros también, simplemente no estaba tan bien documentado. Pero sí, los navegadores modernos dejaron de poder hacer eso, probablemente por algunas razones (seguridad, separación de contenido y acción, etc.). – Ktash

Bueno, en mi caso necesito admitir tantos caracteres como sea posible (especialmente unicode), así que estoy tratando de averiguar qué bloquear, ya que no puedo entender casi todo el espacio Unicode. Afortunadamente, que yo sepa, solo el pequeño espacio ASCII contiene las cosas peligrosas, solo me pregunto si las profundidades del Unicode contienen algunas cosas que podrían * ayudar * a activar otros bytes. ('preg_match_all ('/ \ p {L} +/u', $ str, $ arr)'). También debo permitir la discusión de secuencias peligrosas, así que no quiero eliminar todo lo sospechoso. – Xeoncross

Aquí se muestra un ejemplo: <button onclick="confirm('Are you sure you want to delete ');alert('xss')> Aquí la entrada de atacantes es lo que viene después de "eliminar" y antes de ')>

Este escape no funcionará en este caso, porque nos escapamos para el contexto equivocado.

En pocas palabras, la prevención de xss escapa para el contexto dado. En el ejemplo anterior, estamos en un contexto de JavaScript dentro de un contexto de atributo HTML. Vea la hoja de trucos de prevención de OWASP XSS.

Fuente

2011-12-25 19:07:10 Erlend

es suficiente para escapar de texto en HTML, pero hay contextos en HTML, donde incluso el texto es peligroso:

no permiten a los usuarios crear URLs arbitrarias (en <a>, <img>, etc.), ya que pueden insertar javascript: o muchas variaciones de él. Lista blanca solo ^https?://.
HTML-escape no es suficiente en <script> (que utilizan entidad de escape de todos modos) o en los atributos que ejecutan un script (onclick, etc). Para aquellos que necesita json_encode().

Fuente

2011-12-27 14:27:19 Kornel

¿Hay otras secuencias que los navegadores interpretan como caracteres especiales HTML?

Respuesta

Cuestiones relacionadas