I token CORS e CSRF sono solo per le richieste POST e GET? [chiuso]

Question

I token CORS e CSRF sono solo per le richieste POST e GET? [chiuso]

#1 da (4 voti)

0

Ho le seguenti domande su CSRF, SOP e CORS.

I token CSRF proteggono solo l'invio di moduli con metodi POST o GET? Si tratta solo di una "pratica comune" (riguardo al fatto che solo le richieste di moduli sono vulnerabili come ad esempio POSTARE una richiesta di trasferimento di fondi in un sito di web banking)
CORS è disponibile solo (ignora SOP) quando si richiede contenuto con un metodo GET e non con POST? Se un modulo è protetto con un token CSRF, non c'è motivo di fare riferimento a CORS per effettuare tale richiesta (ovvero inviare il modulo da un dominio diverso) a causa del fatto che anche con CORS abilitato esiste un token CSRF che protegge quel contenuto (anche se questo non è un tipico caso d'uso del token CSRF).
CORS è basato sul controllo dell'intestazione di origine a causa del fatto che il browser della vittima non può essere ingannato nello spoofing dell'intestazione Origin? Mentre cURL ci permette di spoofare le intestazioni, in questo particolare attacco il browser della vittima non può essere ingannato?

Ho letto vari post su quanto sopra, ma mi piacerebbe una spiegazione più chiara. Ad esempio ho letto che :

However, resource loading from other hosts like images, scripts, stylesheets, iframes, form submissions etc. are not subject to this limitation

Ciò che mi confonde penso sia che la maggior parte dei thread riguardanti il token CSRF elaborino solo su esempi con moduli e inviando dati con metodo POST a un server e non elaborino l'immagine più grande.

csrf same-origin-policy cors

posta XII 14.05.2018 - 11:43

fonte

1 risposta

Leggi altre domande sui tag csrf same-origin-policy cors

È possibile che l'app ssh su Android raccolga le mie credenziali? Tokenizzazione - È una cattiva pratica riutilizzare i token?

score 4 · Answer 1

In base a ciò che chiedi, penso che tu stia confondendo un po 'i concetti:

CSRF è un metodo per eseguire un'azione cross-site autenticato, cioè attivato da un utente malintenzionato ma eseguito con l'autenticazione di un utente già connesso a causa dell'invio automatico di cookie di sessione esistenti o di credenziali di autenticazione di base. CSRF riguarda solo l'esecuzione dell'azione e non si preoccupa di leggere il risultato.
Nel contesto di CSRF CORS riguarda il controllo delle richieste che possono essere inviate dal browser al server in primo luogo utilizzando l'API XMLHTTPRequest o fetch. Non limita l'invio di richieste semplici, che sono richieste che potrebbero essere create senza XMLHTTPRequest o recupera incorporando una risorsa, inviando un modulo ecc. Limita solo le richieste non semplici (es. Richieste con metodo personalizzato, intestazione personalizzata .. .) potrebbe essere inviato cross-site richiedendo prima di queste richieste non semplici di verificare la politica CORS del sito per vedere se la richiesta reale è consentita.
CORS non è la singola politica che copre tutte le cose relative a qualsiasi tipo di richieste cross-site ma copre solo un sottoinsieme specifico.

Con questo in mente:

Does CSRF tokens only protect form submission with either POST or GET methods?

Un token CSRF è essenzialmente un segreto che l'attaccante non può indovinare. Può essere utilizzato per qualsiasi tipo di richiesta. Ma dato che con richieste non semplici la politica CORS verrebbe comunque controllata, in realtà non aggiunge valore a tali richieste. Pertanto, quando si utilizza XMLHTTPRequest o fetch viene spesso applicata una richiesta non semplice aggiungendo un'intestazione personalizzata in modo che non sia necessario alcun token CSRF (più complesso).

Is CORS only available (bypasses SOP) when requesting content with a GET method and not with POST?

CORS non ha nulla a che fare con GET o POST ma riguarda richieste non semplici o semplici. Entrambi i tipi di richieste possono utilizzare GET o POST, sebbene le richieste non semplici possano anche utilizzare metodi personalizzati.

Is CORS based on checking the origin header due to the fact that the browser of the victim cannot be tricked into spoofing the Origin header?

CORS non si basa sul controllo dell'intestazione Origin . La politica CORS è applicata dal browser e non dal server. Ci sono casi in cui il controllo dell'intestazione Origin o Referer è comunque rilevante: come quando si protegge contro CSRF senza un token CSRF o quando si limita l'accesso a WebSockets. Ma questi casi non sono coperti dal CORS, ad esempio CORS non è l'unica cosa che si preoccupa delle richieste cross-site.