Ricordami contro sessione persistente per applicazioni web

Il rischio principale di una sessione persistente è l'aumento dell'esposizione per eventuali vulnerabilità esistenti sul lato client (ad esempio XSS, CSRF, fissazione della sessione, ecc.)

Cioè, qualsiasi sito maligno che bersaglia i tuoi utenti tramite exploit per quanto sopra sarebbe più probabile che abbia successo perché l'utente è rimasto loggato.

Con remember-me si potrebbe applicare anche il precedente - Dì che il token remember-me a lungo termine viene scambiato automaticamente per un token di sessione per richiesta.

per es.

nella richiesta che il browser invia

Cookie: remember-me=32132213312132

e il server emette automaticamente un token di sessione per questa richiesta perché convalida il token. Inoltre, risponde con il nuovo token di sessione per le richieste successive da utilizzare in questa sessione:

Set-Cookie: session=asdkalkjdjsaddsajdsal

Questo dimostra che, anche se viene utilizzato un cookie separato per l'accesso a lungo termine, poiché viene scambiato automaticamente, esso favorirà anche gli exploit cross-domain nelle sessioni utente di attacco.

Potresti mitigarlo usando i token di aggiornamento stile OAuth2. Quindi se l'utente malintenzionato tenta un attacco CSRF come

<img src="https://example.com/transfer_money?to_acc=2321321&amount=1000000"/>

nonavrebbeautomaticamentesuccessoperchéiltokendiaggiornamentodasolononèsufficienteperautenticarelarichiesta(remember-me)-deveesserescambiatoperuntokendiaccesso(session).

es.sel'utentevisitailtuosito,potrebbeesserciunaltropassaggioesplicitoperottenereiltokensessionperrappresentareunutenteattivoeconnesso:

<formmethod="post">
  <input type="hidden" name="anti-csrf" value="asddadaddasa242421fsas" />
</form>

Il token anti-csrf è collegato al token di aggiornamento nel database lato server, impedendo l'utilizzo di un exploit CSRF per ottenere il token prima dell'attacco. Quanto sopra deve essere inviato manualmente dall'utente per impedire a un utente malintenzionato di aprire la pagina in un popup o all'interno di un IFrame.

Solo dopo che tutte le convinzioni precedenti sono riuscite, il server ha risposto con un token di accesso ( session ):

Set-Cookie: session=asdkalkjdjsaddsajdsal

Naturalmente il tuo sito dovrebbe già mitigare XSS, CSRF e simili, tuttavia questo è un approccio difensivo per proteggere i token a lungo termine che hanno una maggiore probabilità di compromettere un utente perché il loro login è più probabile che sia attivo in caso di attacco.

(Ho già avuto alcune riflessioni sull'argomento, ma stavo cercando ulteriori pareri. Dal momento che sembra aver causato qualche confusione, impostarle qui può aiutare a capire il problema che sto cercando di risolvere).

Esistono impatti funzionali molto definiti, in particolare se lo sviluppatore sceglie di utilizzare il substrato di sessione per archiviare le informazioni transazionali, ma ha anche altre complicazioni. L'impatto funzionale è fuori tema qui.

Il primo argomento a favore di una funzione remember-me è che impone un aggiornamento dello stato di autenticazione. Sebbene non sia un requisito essenziale di implementazione (né un'esclusione essenziale dalla sessione persistente complementare), significa che l'account deve essere nuovamente convalidato quando un utente riprende l'interazione dopo un'interruzione.

Come per i commenti sopra, Limit ha già notato che il consenso dell'utente è fondamentale. Lasciare un terminale di accesso pubblico registrato in un account non sarebbe una buona idea. Ciò significa quindi che semplicemente estendere la durata della sessione non è un'opzione - il sistema deve implementare la scelta dell'utente. Dal punto di vista dell'architettura, l'opzione "remember-me" è meno intrecciata con la gestione delle sessioni, rendendo più semplice l'implementazione e quindi più sicura.

Un'ulteriore considerazione è che, nel caso di sessioni di lunga durata, le informazioni necessarie per rilevare tali sessioni vengono archiviate nei backup. Questo vale anche quando il cookie "remember-me" contiene un riferimento ai dati lato server.

Se il contenuto di "remember-me" è autonomo, adeguatamente protetto da mezzi crittografici, allora chiunque abbia accesso a una copia dei dati del server ha ancora un cerchio extra da attraversare per accedere a una sessione, ovvero è necessario riprodurre la crittografia utilizzata per creare i dati del lato client. Naturalmente, se capita di avere accesso anche al codice, probabilmente avranno accesso a qualsiasi chiave, ma questo avrà un valore limitato se la chiave è derivata da altri dati vincolati come l'indirizzo IP del client. D'altra parte, probabilmente le stesse protezioni potrebbero essere applicate all'ID di sessione in una sessione persistente.

La prossima considerazione è il contenuto dei dati della sessione. Se c'è più dell'identità dell'account e dello stato di autenticazione (ad esempio, dati integrati da altri servizi), potrebbe avere un valore intrinseco per un utente malintenzionato. In questo scenario, la riduzione della resa rimuovendo i dati per gli utenti inattivi (ad esempio l'opzione "ricordami") ha alcuni vantaggi.

Nel complesso, ho difficoltà a vedere qualsiasi argomento positivo per l'approccio di sessione persistente dal punto di vista della sicurezza.