Está usando las funciones htmlentities o htmlspecialchars para bloquear el ataque XSS

3

Sé que esta pregunta fue discutida en la red varias veces. y la gente da algún ejemplo de cómo omitir estas funciones pasando un código. Pero aquí hay un problema: todo ejemplo de htmlentities / htmlspecialchars se relaciona cuando lo insertamos como valor de atributo como

<a href="" title="<?php echo htmlentities([XSS_CODE]) ?>"></a> 

O

<img onerror="<?php echo htmlentities([XSS_CODE]) ?>" /> 

Pero si necesito mostrar los datos como contenido como se muestra a continuación.

<div><?php echo htmlentities([XSS_CODE]) ?></div>

Cómo podría ser inseguro. Como el código no tendrá activadores / eventos como en el caso de los atributos, esto debería ser seguro en todos los casos.

Estudié enlace . Casi todos los ejemplos de omisión de ataque / filtro XSS no funcionan para un caso determinado. Probé el valor codificado hexadecimal de < &erio; > como se indica en el último párrafo de url, pero nuevamente fracasó y se mostró simplemente como datos.

Realmente tengo dudas sobre enlace que tienen una combinación que no se maneja con htmlentities como \ x3c, \ u003c,% 3C. Mientras que yo mismo soy incapaz de producirlos y explotarlos usándolos.

Probé un ejemplo como

$code = "\x3cstrong\x3eHello World\x3\cstrong\x3e";
// OR
$code = "\u003cstrongu003eHello Worldu003c\cstrongu003e";


<div><?php echo htmlentities($code); ?></div>

Nota: Probé todos los ataques en Firfox 40 en la máquina Ubuntu.

    
pregunta kuldeep.kamboj 21.09.2015 - 16:24
fuente

2 respuestas

4

htmlentities es la mejor función para usar, ya que codifica todos los caracteres posibles.

La única forma en que puedo ver el logro de XSS en su ejemplo es con Internet Explorer si el conjunto de caracteres está establecido en UTF -7 .

Si tu juego de caracteres es UTF-7 entonces

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

se convierte en

<script>alert(document.location)</script>

cuando sea interpretado por el navegador. Además, htmlentities no causa ninguna codificación de los caracteres.

Tenga en cuenta que solo las versiones antiguas de Internet Explorer detectarán automáticamente UTF-7, ya que deberían configurarse explícitamente en versiones modernas (ya sea por el autor del sitio web o por el atacante que use algún otro vector) - vea esta respuesta .

    
respondido por el SilverlightFox 22.09.2015 - 13:36
fuente
1

Cuando un navegador analiza un atributo de evento como "onerror", primero HTML decodifica el valor del atributo y luego lo envía al motor JS para su ejecución. Por eso no basta con solo codificar HTML el contenido del usuario que está insertando en dichos atributos.

En contraste, cuando un navegador analiza una etiqueta <script> , no decodifica HTML su contenido. Simplemente reenvía su contenido al motor JS para su ejecución.

De forma similar, cuando inserta contenido de usuario entre etiquetas <div> , no veo una forma en que XSS pueda ser posible si los datos del usuario están codificados en HTML porque el navegador no realiza decodificación, excepto, por supuesto, solo para presentar los caracteres codificados en la pantalla .

Y no tengo idea de cómo el atributo de título de la etiqueta <a> podría llevar a XSS si su contenido está codificado en HTML y se cita dos veces. Por favor, hágamelo saber si sabes cómo :)

    
respondido por el pineappleman 21.09.2015 - 20:45
fuente

Lea otras preguntas en las etiquetas