CSRF con JSON POST

Question

CSRF con JSON POST

#1 da (27 voti)
#2 da (6 voti)

25

Sto giocando con un'applicazione di test che accetta richieste JSON e la risposta è anche JSON. Sto cercando di fare un CSRF per una transazione che accetta solo i dati JSON con il metodo POST in richiesta. L'applicazione genera un errore se l'URL viene richiesto utilizzando il metodo get (ad es. In <script src= ).

Anche perché l'attacco sia significativo, ovvero la transazione da effettuare, devo inviare i dati nella richiesta. Se creo la mia pagina e invii le richieste JSON, i cookie non viaggiano e quindi il server restituisce un messaggio di errore non autenticato.

Non ci sono token casuali nella richiesta originale dal server.

Mi chiedevo se ci fosse un modo per portare a termine con successo un attacco CSRF in questo scenario.

http json csrf

posta Sachin Kumar 30.12.2011 - 10:39

fonte

2 risposte

6

Questo è sfruttabile utilizzando Flash, in base al link

The ability to make cookie-bearing cross-domain HTTP GET and POST requests via the browser stack, with fewer constraints than typically seen elsewhere in browsers. This is achieved through the URLRequest API. The functionality, most notably, includes the ability to specify arbitrary Content-Type values, and to send binary payloads.

Non l'ho ancora provato ma sembra plausibile.

Aggiornamento: sembra che le ultime versioni di Flash non consentano più richieste di domini per impostazione predefinita, rendendo questo non sfruttabile.

Aggiornamento n. 2: tuttavia esiste una vulnerabilità di vecchia data nella gestione da parte di Flash dei 307 reindirizzamenti, il che significa che è ancora sfruttabile

risposta data 03.12.2012 - 19:01

fonte

Leggi altre domande sui tag http json csrf

Quali misure di sicurezza prendono PyPI e repository di software di terze parti simili? Rischi di ssh in un host non affidabile? [duplicare]

score 27 · Accepted Answer

Devi almeno controllare Content-Type: application/json sulla richiesta.

Non è possibile ottenere una percentuale POSTed% co_de per inviare una richiesta con <form> . Ma puoi inviare un modulo con una struttura JSON valida nel corpo come Content-Type: application/json .

Non è possibile eseguire un cross-origine ( CORS ) XMLHttpRequest POST con enctype="text/plain" contro un non- server di tipo cross-origin-aware poiché ciò causerà la richiesta HTTP OPTIONS "pre-flighting" prima di approvarla. Ma puoi inviare un XMLHttpRequest POST cross-origine conCredentials se è Content-Type: application/json .

Quindi, anche con il controllo text/plain , puoi avvicinarti a XSRF, se non completamente lì. E i comportamenti su cui stai facendo affidamento per renderlo sicuro sono alquanto oscuri e ancora in fase di Working Draft; non sono garanzie durissime per il futuro del Web.

Questi potrebbero rompersi, ad esempio se un nuovo JSON application/json è stato aggiunto ai moduli in una futura versione HTML. (WHATWG ha aggiunto il enctype enctype a HTML5 e in origine ha provato anche ad aggiungere text/plain , quindi non è escluso che ciò possa accadere.) Aumenta il rischio di compromissione da browser più piccoli e più sottili e bug di plugin in CORS implementazione.

Quindi, anche se probabilmente puoi farla franca per ora, non consiglierei assolutamente di andare avanti senza un adeguato sistema di token anti-XSRF.