CSRF con JSON POST cuando Content-Type debe ser application / json

9

Estoy probando una aplicación web para la cual se realizan acciones comerciales mediante el envío de solicitudes JSON como por ejemplo:

POST /dataRequest HTTP/1.1
Host: test.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 
Firefox/55.0
Accept: */*
Accept-Language: pl,en-US;q=0.7,en;q=0.3
Content-Type: application/json; charset=utf-8
Content-Length: 99
Cookie: SESSIONID=7jtyutuytu1a
Connection: close

{"F":"test.AppRequestFactory","I":[{"O":"5vhghgjhgjE0="}]}

Hice la página de envío automático de HTML como esta

<html>
<head>
</head>
<body onload=document.getElementById('xsrf').submit()>
    <form id="xsrf" action="https://test.com/dataRequest" method=post enctype="text/plain">
    <input name='{"F":"test.AppRequestFactory","I":[{"O":""O":"5vhghgjhgjE0' value='"}]}' type='hidden'>
    </form>
</body>
</html>

El problema es que se enviará con el encabezado Content-Type: text/plain , pero el servidor solo acepta Content-Type: application/json; charset=utf-8 .

He leído la discusión CSRF con JSON POST donde uno de los comentarios dice:

  

Use algo como esto: var blob= new Blob([JSON.stringify(YOUR JSON)], {type : 'application/json; charset=UTF-8'}); para generar un blob JSON y se enviará perfectamente. CSRF en segundos!

Pero no tengo idea de cómo usar este enfoque.

¿Esta aplicación es vulnerable al ataque CSRF?

    
pregunta user187205 01.10.2017 - 18:53
fuente

2 respuestas

8
  

¿Esta aplicación es vulnerable al ataque CSRF?

Sí, es vulnerable. El requisito previo, sin embargo, aquí es Flash . Con la ayuda de Flash, es posible forjar un encabezado Content-type con cualquier valor arbitrario. Lo que debe hacer es enviar una solicitud a su propio dominio y luego emitir un redireccionamiento 307. Por favor, consulte la siguiente captura de pantalla:

Paraobtenermásinformación,consulte este artículo de cm2.pw .

  

Use algo como esto: var blob= new Blob([JSON.stringify(YOUR JSON)], {type : 'application/json; charset=UTF-8'}); para generar un blob JSON y se enviará perfectamente. CSRF en segundos!

Esto, afaik, ya está arreglado en los navegadores modernos. Sin embargo, todavía funciona en IE con el archivo URI.

    
respondido por el 1lastBr3ath 21.12.2017 - 09:16
fuente
5
  

Advertencia : Esta respuesta puede ser incorrecta y optimista. Consulte la la respuesta de 1lastBr3ath más arriba.

No, no creo que la aplicación sea vulnerable.

Puedes cambiar el encabezado Content-Type , por ejemplo, utilizando la API de recuperación . Sin embargo, solo hay tres valores que puede usar para las solicitudes de dominios cruzados:

application/x-www-form-urlencoded
multipart/form-data
text/plain

Si lo cambia a cualquier otra cosa, como application/json , el navegador primero hará una solicitud OPTIONS al servidor, para ver si permite que se cambie ese encabezado. Este comportamiento es parte de CORS , y está diseñado para limitar las solicitudes de dominio cruzadas puede hacer con JavaScript a los antiguos que podría hacer con HTML simple. Entonces, a menos que el servidor permita específicamente que cualquier dominio establezca este encabezado (lo que sería una estupidez), no tiene suerte.

Tenga en cuenta, sin embargo, que esto parece ser un caso de "seguridad por accidente". Confiaría en algo más fuerte para mi protección CSRF (y tal vez lo hagan, una vez que supere el obstáculo del tipo de contenido). ¿Qué sucede si algún día alguien piensa que sería bueno si el servidor acepta otros tipos de contenido y elimina esa limitación? Con esta configuración, sería fácil abrir accidentalmente un agujero de seguridad.

    
respondido por el Anders 02.10.2017 - 11:37
fuente

Lea otras preguntas en las etiquetas