CSRF con JSON POST

Navega tus respuestas
25

Estoy jugando con una aplicación de prueba que acepta solicitudes JSON y la respuesta también es JSON. Estoy intentando realizar un CSRF para una transacción que solo acepta datos JSON con el método POST en solicitud. La aplicación emite un error si se solicita la URL utilizando el método get (por ejemplo, en <script src= ).

También para que el ataque sea significativo, es decir, para que se realice una transacción, tengo que enviar los datos en la solicitud. Si creo mi propia página y envío las solicitudes JSON, las cookies no viajan y, por lo tanto, el servidor devuelve un mensaje de error no autenticado.

No hay tokens aleatorios en la solicitud original del servidor.

Me preguntaba si hay alguna forma de llevar a cabo un ataque CSRF exitoso en este escenario.

    
pregunta Sachin Kumar 30.12.2011 - 10:39
fuente

2 respuestas

26

Por lo menos debe verificar Content-Type: application/json en la solicitud.

No es posible obtener un <form> POSTED para enviar una solicitud con Content-Type: application/json . Pero puede enviar un formulario con una estructura JSON válida en el cuerpo como enctype="text/plain" .

No es posible hacer un origen cruzado ( CORS ) XMLHttpRequest POST con Content-Type: application/json contra un no- servidor con reconocimiento de origen cruzado porque esto causará una solicitud de OPCIONES HTTP de 'vuelo previo' para aprobarlo primero. Pero puede enviar un POSTHRp de solicitud de origen cruzado withCredentials si es text/plain .

Así que incluso con application/json comprobando, puedes acercarte bastante a XSRF, si no estás completamente allí. Y los comportamientos en los que se está confiando para garantizar su seguridad son algo oscuros, y aún se encuentran en la etapa de borrador de trabajo; No son garantías duras y rápidas para el futuro de la web.

Estos pueden romperse, por ejemplo, si se agrega un nuevo JSON enctype a los formularios en una futura versión HTML. (WHATWG agregó text/plain enctype a HTML5 y originalmente intentó también agregar text/xml , por lo que no está fuera de duda que esto pueda suceder). Aumenta el riesgo de compromiso con errores de navegador y complementos más pequeños y sutiles en CORS implementación.

Por lo tanto, aunque probablemente pueda salirse con la suya por ahora, no recomendaría seguir adelante sin un sistema de token anti-XSRF adecuado.

    
respondido por el bobince 30.12.2011 - 12:30
fuente
6

Esto se puede explotar con Flash, de acuerdo con enlace

  

La capacidad de hacer HTTP GET y POST de dominio cruzado con cookies.   solicitudes a través de la pila del navegador, con menos restricciones que las típicas   visto en otros lugares en los navegadores. Esto se logra a través de la URLRequest   API. La funcionalidad, sobre todo, incluye la capacidad de especificar   valores de tipo de contenido arbitrarios, y para enviar cargas binarias.

No lo he probado, pero parece plausible.

Actualización: parece que las últimas versiones de Flash ya no permiten solicitudes de varios dominios de forma predeterminada, lo que hace que esto no se pueda explotar.

Actualización # 2: sin embargo, existe una vulnerabilidad de larga data en el manejo de flash de 307 redirecciones, lo que significa que aún es explotable

    
respondido por el albinowax 03.12.2012 - 19:01
fuente

Lea otras preguntas en las etiquetas

¿Es necesario un desguace de archivos / borrado seguro cuando tiene el cifrado de disco completo activado? ¿Cómo descifrar una contraseña dado su hash y su sal utilizando un método más eficiente que la fuerza bruta?