¿Es posible que XSS explote las respuestas JSON con un escape de cadena JavaScript adecuado
Las respuestas JSON se pueden explotar sobreescribiendo constructores de matrices o si los valores hostiles no son cadena de escape de JavaScript.
Supongamos que ambos vectores se abordan de la manera normal. Google atrapa el abastecimiento directo de respuesta JSON prefijando todo JSON con algo como:
throw 1; < don't be evil' >
Y luego el resto del JSON sigue. Así que el Dr. Mal no puede, usando el tipo de hazaña discutida aquí http://sla.ckers.org/forum/read.php?2,25788 obtenga su cookie (suponiendo que haya iniciado sesión) poniendo lo siguiente en su sitio:
<script src="http://yourbank.com/accountStatus.json">
En cuanto a las reglas de escape de cadenas, bueno, si estamos usando comillas dobles, necesitamos prefijar cada una con una barra invertida y cada barra invertida con otra barra invertida, etc.
Pero mi pregunta es, ¿qué pasa si estás haciendo todo esto?
Burpsuite (la herramienta de seguridad automatizada) detecta intentos XSS incrustados que se devuelven con escape unHTML en una respuesta JSON y lo informa como una vulnerabilidad XSS. Tengo un informe que mi aplicación contiene vulnerabilidades de este tipo, pero no estoy convencido. Lo he intentado y no puedo hacer que un exploit funcione.
Así que no creo que esto sea correcto, pero le pido a la comunidad StackOverflow que intervenga.
Hay un caso específico, el de IE MIME-type sniffing que creo que podría resultar en un exploit. Después de todo, IE 7 todavía tenía la "característica" de que las etiquetas de script incrustadas en los comentarios de la imagen se ejecutaban independientemente del encabezado Content-Type. Vamos a dejar también tal claramente comportamiento estúpido a un lado al principio.
Seguramente el JSON sería analizado por el analizador JavaScript nativo (Window.JSON en Firefox) o por una eval () según el antiguo comportamiento predeterminado de jQuery. En ninguno de los dos casos la siguiente expresión resultaría en la ejecución de la alerta:
{"myJSON": "legit", "someParam": "12345<script>alert(1)</script>"}
¿Tengo razón o estoy equivocado?
4 answers
Esta vulnerabilidad xss potencial se puede evitar utilizando el Content-Type correcto. Basado en RFC-4627 todas las respuestas JSON deben usar el tipo application/json. El siguiente código es no vulnerable a xss, adelante pruébelo:
<?php
header('Content-type: application/json');
header("x-content-type-options: nosniff");
print $_GET['json'];
?>
El encabezado nosniff se usa para deshabilitar el rastreo de contenido en versiones antiguas de Internet Explorer. Otra variante es la siguiente:
<?php
header("Content-Type: application/json");
header("x-content-type-options: nosniff");
print('{"someKey":"<body onload=alert(\'alert(/ThisIsNotXSS/)\')>"}');
?>
Cuando el código anterior es visto por un navegador, se le pidió al usuario que descargara un archivo JSON, JavaScript no se ejecutó en las versiones modernas de Chrome, FireFox e Internet Explorer. Esto sería una violación de RFC.
Si usa JavaScript para eval() el JSON anterior o escribe la respuesta en la página, entonces se convierte en XSS basado en DOM. El XSS basado en DOM se parchea en el cliente al desinfectar el JSON antes de actuar sobre estos datos.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-01-19 00:44:45
Burpsuite (la herramienta de seguridad automatizada) detecta intentos XSS incrustados que se devuelven unHTML-escaped en una respuesta JSON y lo informa como una vulnerabilidad XSS.
Tal vez intenta evitar la vulnerabilidad descrita en la regla 3.1 de la Hoja de trucos de OWASP XSS.
Dan el siguiente ejemplo de código vulnerable:
<script>
var initData = <%= data.to_json %>;
</script>
Incluso si las comillas dobles, las barras y las nuevas líneas se escapan correctamente, puede salir de JSON si está incrustado en HTML:
<script>
var initData = {"foo":"</script><script>alert('XSS')</script>"};
</script>
JsFiddle .
to_json() la función puede evitar este problema prefijando cada barra con una barra invertida. Si se usa JSON en el atributo HTML, toda la cadena JSON debe tener un escape HTML. Si se usa en un atributo href="javascript:", debe ser URL-escaped.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-01-19 00:10:22
Si limitamos nuestro alcance a IE (todas las versiones), supongamos que está ejecutando un sitio basado en PHP o ASP.NET, e ignorar el filtro anti-xss IE, entonces usted está equivocado: sus usuarios son vulnerables. Configurar 'Content-type: application / json' tampoco ayudará.
Esto se debe al comportamiento de detección de contenido de IE, que va más allá de buscar etiquetas HTML en el cuerpo de la respuesta para incluir análisis URI.
Esta publicación en el blog explica esto muy bien:
Http://blog.watchfire.com/wfblog/2011/10/json-based-xss-exploitation.html
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-03-28 23:40:06
Para el registro, aunque acepté una respuesta, para la pregunta literal exacta que estoy haciendo, tenía razón y no había vulnerabilidad debido a la presencia de no-HTML-escapado pero correctamente JSON-escapado HTML dentro de los valores JSON. Podría haber un error allí si ese valor se insertó en el DOM sin escapar del lado del cliente, pero Burpsuite tiene pocas posibilidades de saber si eso sucedería simplemente mirando el tráfico de red.
En el caso general de determinar qué es un valor vulnerabilidad en estas circunstancias, es instructivo reconocer que si bien puede no parecer un buen diseño, el contenido de respuesta de un valor JSON podría saberse legítimamente que ciertamente no contiene ninguna entrada del usuario y está destinado a ser HTML ya renderizado para ser insertado de forma segura en el DOM sin escaparse. Escapar sería un error (no de seguridad) como mencioné en otro comentario.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-09-21 03:13:09