Esiste una vulnerabilità quando si utilizza XHR con metodo GET e intestazione HTTP anti-CSRF personalizzata?

Question

Esiste una vulnerabilità quando si utilizza XHR con metodo GET e intestazione HTTP anti-CSRF personalizzata?

Naviga le tue risposte

#1 da (9 voti)
#2 da (1 voti)

1

Pulsante Imagine dopo aver fatto clic su quale browser invia la richiesta http XHR con il metodo GET. Caratteristiche:

dopo l'esecuzione dell'azione sensibile richiesta viene eseguita
le informazioni sensibili vengono inviate nei parametri GET
Intestazioni HTTP X-Requested-With: XMLHttpRequest e X-CSRF-Token con token PRG sufficientemente grande vengono inviate e sono necessarie per eseguire l'azione
a Copy link location non è accessibile quando fai clic con il pulsante destro del mouse sul modulo

Normalmente XHR è usato con GET ma qui è usato con GET. È l'unica differenza rispetto alle normali richieste XHR.

Questo design porta a vulnerabilità di sicurezza?

Modifica: alcuni rispondenti e commentatori dicono che:

L'utente può copiare o URL del segnalibro. Tuttavia, l'unico posto da cui l'utente può copiare l'url è il codice sorgente della pagina perché questo URL non è esposto nella barra degli indirizzi del browser, menu di rightclick perché il pulsante è un modulo). Inoltre, i parametri vengono aggiunti alla richiesta dal browser stesso, quindi l'utente non può copiare l'URL completo dal codice sorgente.
L'utente può copiare parte della finestra del browser. Tuttavia, l'URL non è esposto nella finestra del browser
Potrebbe diventare parte dell'intestazione del Referer. Tuttavia, è XHR e non cambia l'url nell'intestazione Referer delle prossime richieste

Quindi l'unica vulnerabilità valida sembra essere che i parametri GET possono essere registrati nei log del server Web (non verranno registrati al proxy a causa dell'utilizzo di TLS). Se questi registri sono accessibili all'attaccante, allora avrà informazioni sensibili.

http web-application appsec csrf

posta Andrei Botalov 17.05.2012 - 13:37

fonte

2 risposte

Leggi altre domande sui tag http web-application appsec csrf

Quanto è sicuro fornire la password del mio account amministratore per un software di terze parti: EasyUS Todo Backup? crea un'app per iPhone / Android che invia una password utente al mio server, come proteggere?

score 9 · Answer 1

Non mi affiderei a questo progetto. La specifica HTTP afferma:

Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

Più in generale non consiglierei mai di utilizzare i token CSRF nelle richieste GET poiché potrebbero essere disponibili in vari file di log (vulnerabilità se il token anticsrf non viene corretto dopo un uso.), potrebbero diventare parte dell'intestazione del referrer , gli utenti possono aggiungerli ai segnalibri e questo porterà a una perdita di sicurezza oa segnalibri non validi. Questo potrebbe avere un impatto negativo anche sul SEO. Ecc, ecc.

Quindi penso che GET + CSRF + ANY_OTHER_SENSITIVE_DATA = cattiva idea.

score 1 · Answer 2

Problema 1: dati sensibili nell'URL.
Problema 2: token CSRF nell'URL Tutto ciò che inserisci nell'URL verrà registrato nella cronologia del browser, nei registri del proxy, nei registri del server web ....
Problema 3: non puoi impedire all'utente di visualizzare il link / url disabilitando le opzioni del tasto destro, tutto ciò che hai inviato al browser sarà accessibile all'utente, in un modo o nell'altro

NON USARE GET per la pubblicazione di dati e richieste che cambiano lo stato.

Non vedo alcun problema nel mettere il token CSRF nell'intestazione, altre cose che devi considerare non sono l'apertura del server alle richieste CORS HTML5. Se devi consentire a CORS, ci sono altre cose da considerare.