Se disponiamo di un dominio con vulnerabilità XSS memorizzata. So che è già fondamentale! .. Ma, sto parlando di limitare il danno.
L'hacker non può ottenere il cookie di sessione dell'amministratore, perché è contrassegnato come httponly e il server non consente il metodo TRACE.
Tuttavia, l'utente malintenzionato può utilizzare CSRF per forzare l'amministratore a creare un utente nell'applicazione.
La maggior parte dei controlli CSRF lo renderà solo difficile per l'hacker ma non impossibile;
- il token di sincronizzazione e il viewstate possono essere facilmente rubati con richieste Ajax poiché vengono inviati dallo stesso dominio.
- Referrer e la convalida dell'origine non sono applicabili.
- qualsiasi altra richiesta multi-passo potrebbe essere simulata con ajax.
- Anche i doppi sottomessi sono vulnerabili, poiché il browser invia i cookie per impostazione predefinita.
- I CAPTCHA sono difficili, ma teoricamente possono essere risolti utilizzando turk meccanici.
L'unico controllo che sembra funzionare richiede le credenziali dell'amministratore ogni volta che viene effettuata una richiesta sensibile. Ma la creazione di un utente è una richiesta sensibile? O cambiare la password di qualcuno? potrebbe essere un compito quotidiano ..
Qualche informazione su questo argomento? possiamo prevenire contro CSRF tramite stored-XSS?