Sto progettando un'API RESTful che deve essere accessibile da un browser web. L'API è protetta dall'autenticazione di base.
Comprendo il concetto di CSRF e le mitigazioni proposte (ho trovato sia voce CSRF di Wikipedia che pagina OWASP CSRF buone spiegazioni). Generalmente introducono alcuni stati che il client deve conservare e presentare al server, quindi il server sa che le richieste provengono ancora dal client giusto.
Tuttavia, devo dire che l'implementazione del client diventa molto "sporca" a causa di ciò e mi chiedevo se potevano esserci soluzioni più pulite. In particolare, uno che non richiederebbe la gestione dello stato aggiuntivo.
Una soluzione che sto pensando, ma volevo controllare con te, è usare un% di intestazione Authorization che non sia Basic .
Secondo RFC 2617, sezione 2, riguardante lo schema di autenticazione Basic , il nome utente e la password possono essere memorizzati nella cache dal browser e inviati nuovamente senza chiedere all'utente in determinate condizioni, e questo è ciò che rende vulnerabile a CSRF :
A client SHOULD assume that all paths at or deeper than the depth of
the last symbolic element in the path field of the Request-URI also
are within the protection space specified by the Basic realm value of
the current challenge. A client MAY preemptively send the
corresponding Authorization header with requests for resources in
that space without receipt of another challenge from the server.
Ho anche verificato che Authorization: OAuth (utilizzato negli endpoint autenticati da OAuth 1.0) e Authorization: Bearer (utilizzato negli endpoint autenticati da OAuth 2.0) non vengono inviati automaticamente dal browser.
Quindi, la mia domanda è: considereresti che un endpoint protetto da intestazioni di autorizzazione OAuth / Bearer dovrebbe prendere precauzioni aggiuntive per prevenire CSRF?