Prevención del XSS reflejado en la URL [duplicado]

1

Acabamos de realizar algunas pruebas de lápiz en una aplicación web y el área identificada como Alto impacto y Probabilidad media fue:

Cross-Site scripting (reflected)

El ejemplo dado fue la capacidad de manipular una URL como:

www.domain.com/application/index.php/<IFRAME SRC=source.com onload="alert(document.cookie)"></IFRAME>

Todos los datos que se pasan realmente a la aplicación a través de formularios, GET, etc. se escapan y si ingresa el código iframe anterior en un formulario y lo envía o lo pasa como un parámetro GET, "no hace nada", pero cuando voy a este URL en un navegador, obtengo diferentes resultados dependiendo del navegador que va desde nada en Chrome e IE hasta Firefox mostrando la cookie en una ventana emergente.

Respuesta HTTP según lo solicitado:

GET /application/index.php/%3CBODY%20ONLOAD=alert%28%27XSS%27%29%3E HTTP/1.1
Host: "www.domain.com":http://www.domain.com
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close 

Obviamente, no puedo confiar en que el usuario use el navegador correcto, así que, ¿cómo puedo mitigarlo? El código se pasa a la URL real y, por lo que puedo ver, se ejecuta antes de que se cargue la aplicación, por lo que no puedo ver ¿Cómo puedo evitarlo si se ejecuta en la URL o me equivoco?

No hay una razón genuina por la que alguien deba pasar ', ", < o > a través de la URL, ¿existen controles de nivel de servidor que pueden eliminar los caracteres desfavorables de la URL? / p>     

pregunta bhttoan 20.05.2015 - 16:11
fuente

1 respuesta

1

Probablemente necesites buscar en Google y leer sobre XSS, pero aquí hay una introducción rápida. Las secuencias de comandos entre sitios son un ataque en el que un sitio hostil, llamémosle H, ataca su sitio S. H tiene en él un enlace a S que contiene un código malicioso que ha sido diseñado para proporcionarle al atacante algún beneficio (por ejemplo: información útil o realizar una acción). Es probable que esto solo funcione si el usuario que visita H está actualmente conectado a su sitio S, pero está bien. A los atacantes no les importa si no funcionan la mayor parte del tiempo siempre que funcionen lo suficiente.

Uno podría pensar que el sitio S puede suponer que la entrada siempre proviene del usuario que está conectado actualmente, por lo que S no necesita proteger al usuario para que no ingrese cosas tontas como scripts. Pero XSS es un medio para que un atacante engañe a un usuario para que parezca que ingrese (en realidad no lo ha ingresado en un cuadro de texto, pero la solicitud falsificada parece similar) a los scripts y otras entradas que son peligrosas para ellos mismos. Así que S no solo debe protegerse a sí mismo del usuario, S también debe proteger al usuario del usuario porque a veces el usuario será un enlace falsificado desde otro sitio.

Comience por leer Hoja de trucos de XSS de OWASP y busque defensas en otros lugares.

    
respondido por el Neil Smithline 20.05.2015 - 17:46
fuente

Lea otras preguntas en las etiquetas