Mi chiedo se un attacco CSRF, rivelerà le informazioni che vengono inviate indietro in una richiesta GET.
Ho bisogno di inviare un numero di previdenza sociale, al cliente un paio di volte, e NON è qualcun altro dovrebbe mai essere in grado di ricevere. I dati sono già protetti da HTTPS, ma so che non fermerà un attacco CSRF.
La richiesta non cambierà nulla nell'applicazione, ma i dati non devono perdere.
Come può essere sfruttato? E quali misure posso prendere per impedirlo?
Un attacco CSRF significa che un sito Web induce un utente a effettuare una richiesta di pagina su un altro sito Web che non desiderava effettuare. Questo può essere usato per indurre l'utente a compiere un'azione su quel sito Web che non intende eseguire.
Potrei, ad esempio, chiederti di fare clic su questo link sorprendente (davvero, è fantastico!) , e accidentalmente ti causano la cancellazione del tuo account su example.com (solo un esempio - non esiste uno script simile su example.com). Quando avrei più controllo su questo sito, potrei usare uno script o un reindirizzamento HTTP, quindi non sarebbe necessario alcun social engineering. Ma qualsiasi risposta a quell'azione verrà inviata a te, non a me. Ciò significa che quando l'azione non è distruttiva e legge solo le informazioni senza modificarle, una CSRF sarebbe inutile. Nel peggiore dei casi, l'utente si chiederà il motivo per cui viene reindirizzato all'improvviso sul sito Web che mostra il proprio numero di previdenza sociale.
Ma esiste un modo per un sito Web di ottenere informazioni da un sito Web diverso nel contesto dell'utente: xmlHttpRequest. Normalmente, stesse politiche di origine si applicano e impediscono a xmlHttpRequests di attraversare i confini del dominio. Ma questa restrizione può essere sostituita da le impostazioni di condivisione delle risorse tra origini sul server web . Quando abilmente accetti CORS per gli altri siti web (o tutti ), possono inviare richieste nel contesto dei tuoi utenti al tuo sito web e leggere la risposta. Quando vuoi sapere come controllare o modificare la configurazione di CORS sul tuo webserver, fai riferimento alla relativa documentazione.
Generalmente, CSRF non rappresenterebbe una minaccia dal momento che gli attacchi CSRF sono exploit di sessione che non coinvolgono l'attaccante. Tuttavia, se l'attacco CSRF comporta la modifica delle password degli utenti, l'utente malintenzionato potrebbe accedere a molto più di SS #. Inoltre, se l'attacco CSRF potrebbe essere utilizzato in combinazione con un attacco XSS, in alcuni casi questo potrebbe rivelare molte informazioni sensibili.
In entrambi i casi, le protezioni generali CSRF (nonces o cookie sottoposti a doppio invio), le protezioni XSS (filtro di input e di output) e i reindirizzamenti corretti, se applicabile, impedirebbero questo. Il fatto che si tratti di una richiesta GET limita l'esposizione ma non garantisce affatto che sia sicuro.
CSRF non è possibile, ma ci sono stati JSON Hijacking per preoccuparsi di. Tuttavia, questo non è stato un problema per molto tempo e non è più possibile nei browser moderni .
Da 2 : -
Chrome 2.0.172.31 and Firefox 3.0.11 were both vulnerable to this.
Qui è dove l'array JavaScript e i setter di oggetti sono stati ridefiniti nella pagina prima che una richiesta JSON venisse fatta al dominio remoto. Quando è stato restituito il JSON, il codice definito nei nuovi setter verrebbe eseguito e i dati verranno persi nella pagina remota.
Dai un'occhiata a questo post per alcuni suggerimenti se desideri proteggere il tuo codice per l'utilizzo sui vecchi browser o browser rari che potrebbero essere vulnerabili.
Leggi altre domande sui tag http session-management csrf