Ho trovato molti siti popolari che non hanno token crsf nell'intestazione del cookie, vuol dire che tutti questi siti sono vulnerabili?
Ho cercato di saperne di più e ho scoperto che c'è qualcosa chiamato CORS che lo protegge ma non riesco a capire di cosa si tratta.
Condividi la tua metodologia, se possibile, come testare se non trovi un sito con token crsf? come controllerai se ce l'ha o no?
La semplice risposta è "no". I token CSRF (Cross-Site Request Forgery) sono una difesa generalizzata contro CSRF, ma altre condizioni devono essere in gioco per essere vulnerabili. Ad esempio, l'utente malintenzionato deve essere in grado di effettuare una richiesta valida al sito in modo prevedibile. Esistono anche altri fattori di progettazione che possono essere utilizzati per mitigare la minaccia di CSRF.
I cookie di sessione / sessione tendono a rendere gli attacchi più facili perché vengono inviati con qualsiasi richiesta al dominio indipendentemente dal fatto che la richiesta provenga dallo stesso sito di origine. Cross Source Resource Sharing (CORS) aiuta a prevenire ciò bloccando le richieste di origine incrociata a meno che il sito in cui viene effettuata la richiesta non consenta esplicitamente richieste di origine incrociata. Tuttavia, le richieste GET sono generalmente consentite a condizione che non vengano eseguite tramite JavaScript, quindi a volte un attacco CSRF può introdursi richiedendo contenuti utilizzando un tag immagine.
Relativo ai cookie di autenticazione ... un altro fattore di mitigazione nei confronti di CSRF potrebbe essere quello di inviare il token di autenticazione come intestazione anziché come cookie. Ciò richiede che le tue richieste abbiano il token aggiunto esplicitamente ad ogni richiesta, riducendo così il rischio che il browser aggiunga automaticamente l'autorizzazione a richieste non effettuate dal tuo stesso codice. Il token viene solitamente archiviato in Local Storage per questo, a cui è possibile accedere solo dal codice che carica dallo stesso dominio del codice che lo ha salvato.
Come accennato in precedenza, per essere vulnerabili il codice dannoso deve essere in grado di prevedere come deve interagire con il sito per ottenere una risposta utile. Ad esempio, se il sito sotto attacco era una banca, il codice dannoso deve essere in grado di determinare i dettagli completi di una richiesta di trasferimento di denaro per poterlo fare. Se la richiesta di trasferimento di denaro presuppone un account di origine predefinito, è molto più semplice per l'attaccante effettuare poiché non è necessario indovinare tali informazioni perché il server ha assunto il contesto dell'utente per impostazione predefinita.
Detto questo, nella maggior parte dei casi l'attaccante potrebbe essere in grado di accedere a un sacco di informazioni sull'utente dal tuo sito se hanno abbastanza tempo per giocarci dal proprio account. Quindi, supponendo che l'attaccante non possa fare qualcosa perché una richiesta cross-site non avrebbe successo in una singola fase sarebbe follia. Nel precedente esempio, avrebbero solo bisogno di fare una richiesta per ottenere un elenco degli account dell'utente prima che possano fare una richiesta di trasferimento di denaro.
L'affermazione, "ogni sito senza un token CSRF è vulnerabile a un attacco CSRF", non è accurato. Certamente non si applica ai siti web statici che non hanno funzionalità lato server, dove CSRF non è nemmeno applicabile / possibile. Inoltre, il OWASP CSRF Prevenzione Cheat Sheet cita alcuni altri meccanismi di CSRF di prevenzione che non utilizzare i token CSRF:
Adding CSRF tokens, a double submit cookie and value, encrypted token, or other defense that involves changing the UI can frequently be complex or otherwise problematic. An alternate defense which is particularly well suited for AJAX endpoints is the use of a custom request header. This defense relies on the same-origin policy (SOP) restriction that only JavaScript can be used to add a custom header, and only within its origin. By default, browsers don't allow JavaScript to make cross origin requests.
A particularly attractive custom header and value to use is:
X-Requested-With: XMLHttpRequest
o
Sometimes it's easier or more appropriate to involve the user in the transaction in order to prevent unauthorized transactions (forged or otherwise).
The following are some examples of challenge-response options:
- Re-Authentication (password or stronger)
- One-time Token
- CAPTCHA
In caso contrario, qualsiasi applicazione web che non realizzare qualsiasi di questi meccanismi e ha HTTP GET o POST richieste che avviano le azioni possono essere vulnerabili.
CSRF e CORS sono concetti piuttosto separati anche se c'è qualche somiglianza, almeno alla base di tutto.
CORS, o Cross-Origin-condivisione delle risorse consente a un server di definire una politica di cui origini (altri domini) possono recuperare le informazioni da esso. Anche se il criterio predefinito impedisce a un'altra origine di leggere i dati, non impedisce l'esecuzione di un attacco CSRF.
Please share your methodology if possible, like what will you test for if you don't find a site with crsf token? how will you check if it has one or not?
È possibile verificare la presenza di un token CSRF esaminando i cookie, il corpo della richiesta e l'HTML, sebbene possa dipendere dallo specifico sistema utilizzato.
Puoi testare le vulnerabilità CSRF creando una pagina HTML di prova che tenti di eseguire richieste sensibili verso il sito web in questione.