Richiesta GET e POST vulnerabile all'attacco CSRF?

Sì, sia GET che POST sono vulnerabili a CSRF.

Tuttavia, RFC 7231 afferma

the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".

Pertanto, se un sito web è conforme allo standard e implementa solo azioni "non sicure" come POST, in questo caso solo le richieste POST sono vulnerabili. Tuttavia, molti siti Web non eseguono questa operazione per tutte le loro azioni "non sicure"; ad esempio, la funzionalità di disconnessione è spesso trascurata.

Sebbene PUT sia sicuro senza CORS , non è il metodo corretto da utilizzare qui. Se stai implementando la protezione CSRF, un buon metodo per proteggere le richieste XHR è aggiungere un'intestazione come X-Requested-With a le vostre richieste e quindi convalidare questo lato del server di intestazione. È possibile combinare questo valore con un valore casuale controllato dal lato server per aggiungere ulteriore protezione nel caso di plug-in del browser come Flash che contengono vulnerabilità che accidentalmente consentono l'intestazione. Vedi questa risposta e questa .

GET e POST possono essere entrambi vulnerabili a CSRF a meno che il server non presenti un strong meccanismo Anti-CSRF , il server non può contare sul browser per evitare richieste tra domini. Per quanto riguarda le richieste PUT, c'è una leggera differenza, in teoria è anche vulnerabile, tuttavia richiede che le circostanze siano più favorevoli . Ecco perché:

Mentre le richieste GET e POST possono essere fatte facilmente tramite moduli HTML, immagini, tag di script, ecc., fare una richiesta PUT è leggermente più complicato, non puoi fare una richiesta PUT senza il browser interferendo con la richiesta.

Se si utilizza l'API XmlHttpRequest per impostare il metodo di richiesta come PUT, il browser invia prima una richiesta CORS (Cross Origin Resource Sharing) al server di destinazione in cerca di autorizzazione per fai la richiesta, ciò che accade è che una richiesta di OPZIONI è fatta al server di destinazione con un'intestazione impostata su Origine della richiesta di risposta: link (dove è ospitato lo script) e Access-Control-Request-Method e Access-Control-Request -Headers . Se il server risponde con Access-Control-Allow-Origin: link , il browser invia la richiesta in avanti. Correttamente, è necessario che il server restituisca il valore per l'intestazione Origin come server, se l'intestazione Origin è impostata su * * , quindi le credenziali non possono essere inviate con la richiesta . Poiché fare una richiesta PUT con credenziali (cookie) a un server che consente Origine: * non è consentito. Dal link :

Richieste di verifica preliminare

Unlike simple requests (discussed above), "preflighted" requests first send an HTTP request by the OPTIONS method to the resource on the other domain, in order to determine whether the actual request is safe to send. Cross-site requests are preflighted like this since they may have implications to user data. In particular, a request is preflighted if:

It uses methods other than GET, HEAD or POST. Also, if POST is used to send request data with a Content-Type other than application/x-www-form-urlencoded, multipart/form-data, or text/plain, e.g. if the POST request sends an XML payload to the server using application/xml or text/xml, then the request is preflighted. It sets custom headers in the request (e.g. the request uses a header such as X-PINGOTHER)

Quindi, condurre un attacco CSRF contro una pagina che utilizza PUT è leggermente più difficile , poiché richiede la cooperazione del server di destinazione . Tuttavia, questo non dovrebbe essere invocato come un meccanismo anti-CSRF valido in quanto le stranezze del browser potrebbero rendere inutile questo meccanismo di protezione.

Inoltre, per quanto riguarda le circostanze che possono rendere la dipendenza dal metodo PUT come protezione sono state riassunte bene in questa risposta: link

Spero di esserti stato utile.

Il metodo; vale a dire inserire, pubblicare, eliminare, richiedere, ottenere ecc., l'invio di dati è irrilevante. Un attacco CSRF (Cross Site Request Forgery) consente l'iniezione e l'elaborazione di contenuti non attendibili dal server Web.