Hay una falla XSS reflejada en una aplicación que estoy probando. Inicialmente, la carga útil se envía en la solicitud POST como valor de una clave JSON y la respuesta también es un objeto JSON. El valor devuelto en el objeto JSON es usado directamente por Javascript del lado del cliente y por lo tanto el defecto. Mi pregunta es, intenté todas las formas dadas en esta página para enviar una carga JSON a través de un formulario HTML, pero fallé porque el servidor está validando correctamente la entrada. ¿Hay alguna manera de que esta falla XSS pueda ser explotada? Además, el método GET en la misma URL no funciona.
¿XSS no se puede explotar cuando se envían datos POST en JSON?
1 respuesta
-1
El artículo está demostrando que se puede usar un formulario HTML para enviar un objeto JSON a través de CSRF, incluso si el lado del servidor solo acepta solicitudes text/plain que esperan JSON.
(en lugar de las típicas application/x-www-form-urlencoded ) solicitudes.
He incluido el ejemplo vinculado en este sitio, porque no permitimos contenido de solo enlace.
<html>
<form action=http://192.168.1.41:3000 method=post enctype="text/plain" >
<input name='{"a":1,"b":{"c":3}, "ignore_me":"' value='test"}'type='hidden'>
<input type=submit>
</form>
</html>
da como resultado que una solicitud se vea como
Segúnsuscomentarios,ahoraentiendoqueestápreguntandoacercadelosataquesReflectedXSS.
LacargaútilsedevuelvesincambiosenunarespuestaJSON.
¿HayalgúnHTMLinvolucrado?
Siesasí,entoncestododependedecómoestécodificadositieneunavulnerabilidadXSS.
Porotrolado,siestoessimplementeun"eco" sin HTML agregado, entonces depende de sus encabezados de respuesta. Content-Type: text/html debería ser suficiente para evitar que la respuesta se ejecute como código, pero en algunos navegadores, todavía sería vulnerable . Content-Disposition: attachment resolvería el problema suponiendo que la extensión filename y los tipos de contenido son seguros. (es decir, txt )
si la carga útil no se puede enviar a través de formularios HTML, ¿significa que XSS no es "explotable"?
Si no se puede crear un formulario HTML (con la carga de JSON que acepta el servidor), este XSS no es explotable, ¿verdad?
Sin embargo, con una pregunta como esa, parece que estás a punto de "dispararte en el pie" bloqueando una respuesta "fácil". Me preocupa solo porque no entiendo por qué está haciendo esa pregunta .
- Advertencia: con un formulario HTML puede ser posible enviar la carga JSON necesaria en función de los detalles de la validación del servidor que está utilizando.
Te responderé de todos modos:
Suponiendo que un formulario HTML es insuficiente (lo que significa que ya ha refutado mi advertencia) y que la Cadena de consulta tampoco es suficiente (cierto en su caso); entonces los ataques XSS reflexivos no serían posibles.
- El atacante solo tendría AJAX como posibilidad, así como varios complementos que podrían iniciar CSRF . XSS almacenado aún podría ser posible en esa situación, si su servidor tiene características más avanzadas más allá del "eco" de la solicitud.
Información adicional:
Hay tres vías que vienen a la mente para XSS. Solo los elementos 2 y 3 requieren que se cargue la carga útil de su elección a través de CSRF.
Los elementos 1 y 2 se aplican a un ataque XSS almacenado que implica insertar código en uno de los campos de texto de la base de datos del servidor, de modo que cuando el servidor muestre los resultados más adelante, se pueda ejecutar en el Navegador debido a la codificación faltante / impropia (vulnerabilidad XSS) por el servidor.
-
Si tiene las credenciales adecuadas, o es un sitio público (es decir, los comentarios de Stack Exchange), cualquier persona (incluso el atacante) puede insertar el código directamente.
Luego, si el sistema fuera vulnerable (codificación incorrecta / faltante), los futuros visitantes que vean el contenido enviado serían víctimas del ataque.
-
Si este era un sistema cerrado, de modo que el atacante no tuviera las credenciales de inicio de sesión adecuadas para que los datos enviados fueran aceptados en una base de datos, entonces el atacante tendría que utilizar un CSRF para aprovechar de las credenciales de otro usuario (asumiendo que el usuario ya ha iniciado sesión en el sistema de destino cuando visita el sitio del atacante)
-
Para XSS reflectivo , necesitarías el CSRF # 2 para esto. En este caso, no es necesario almacenar los datos, pero está aprovechando una situación en la que los datos de entrada se devuelven al usuario.
- es decir, una página de vista previa,
- o un formulario actualizado con valores precargados
- una página de error que incluye contenido del usuario (es decir, X es una dirección de correo electrónico no válida)
XSS almacenado puede ser preferible para que el atacante llegue a una audiencia más amplia. También existe la posibilidad de que un sistema determinado no sea vulnerable a XSS almacenado, pero aún así pueda ser vulnerable a XSS reflectante.
respondido por el
George Bailey
16.06.2016 - 16:17
fuente
Lea otras preguntas en las etiquetas web-application xss json