Come difendersi da un CSRF dallo stesso sito web?

Bene, il CS in CSRF sta per cross site.

Generalmente, lo scenario di attacco che descrivi non dovrebbe essere possibile per due motivi:

• Le richieste GET non dovrebbero cambiare lo stato del server, quindi non hanno bisogno di alcuna protezione CSRF.
• Le richieste che cambiano server-state dovrebbero essere protette tramite un token. Questo token non dovrebbe essere aggiunto automaticamente ai dati forniti dall'utente e un utente malintenzionato non può creare un link o un modulo contenente questo token, quindi anche le richieste provenienti dallo stesso sito verranno bloccate.

Se si utilizza un approccio basato su referer per la protezione CSRF (o se si aggiunge automaticamente un token a tutti i link o moduli) e se le richieste GET cambiano server-state (o se le richieste POST possono essere convertite in richieste GET o se autorizzi l'utente a pubblicare tag form) dovresti:

1. Considera strongmente il tuo approccio in generale. Non stai seguendo le best practice relative alla sicurezza o allo sviluppo web.
2. Non consentire agli utenti di pubblicare un numero eccessivo di HTML. Soprattutto i tag form necessari per POST CSRF non dovrebbero essere consentiti, in quanto consentono una serie di altri attacchi (furto di informazioni segrete, phishing, ecc.).

I token di protezione CSRF devono essere specifici dell'utente . Posso creare una richiesta che cancelli il mio account (o qualsiasi altra cosa) includendo il mio token, ma non ho il token per nessun altro così la mia richiesta forgiata, se inviata con il cookie ID di sessione di qualcun altro, fallirebbe (essere bloccato dalla protezione CSRF).

Sembra che abbiate perso almeno un elemento critico della protezione CSRF. O hai frainteso che i token anti-CSRF devono essere unici per utente, o stai cercando di usare qualche tipo di filtro di origine richiesta (come l'intestazione Referer o Origin) per rilevare CSRF, e questo è il modo sbagliato di fare esso.

In realtà non fa differenza se un link o un modulo dannoso si trova in una pagina sullo stesso dominio o su un dominio diverso.

Quando richiedi che la richiesta contenga un token di sicurezza valido solo per una situazione molto specifica, un utente malintenzionato non sarà in grado di indovinare quel token anche se contrabbandando un link in contenuti nello stesso dominio.

Inoltre, le attività che modificano i dati non dovrebbero essere attivate da una richiesta GET. Richiede sempre il POST, inoltre richiede un token di sicurezza connesso all'utente attualmente connesso e non può essere riutilizzato in diverse situazioni.