Ho tolto l'accesso ma è ancora dentro: una sessione non è un permesso

Hai tolto il permesso a un utente. Forse hai disattivato del tutto l'account. Poi ti accorgi che quella persona riesce ancora a fare cose.

Non si è rotto nulla. Accedere ed essere autorizzati sono due momenti distinti, e in mezzo c'è uno scarto.

L'accesso avviene una volta, il permesso viene chiesto ogni volta

Quando accedi, il sistema ti consegna un biglietto. Il biglietto dice: questa persona ha dimostrato chi è, e questo biglietto vale fino a una certa ora.

Il permesso è una domanda a parte, riposta a ogni richiesta. Ma in pratica molti sistemi, per velocità, prendono al momento dell'accesso una copia della mappa dei permessi e usano quella copia per un po'.

Da qui nascono due ritardi.

Il primo: quando togli un permesso, una sessione aperta può continuare a portarsi dietro quella copia. La modifica la raggiunge solo quando la sessione si rinnova.

Il secondo, e più importante: cancellare o disattivare l'utente non straccia il biglietto che ha in mano. Il biglietto basta a sé stesso e resta valido finché non scade.

La regola: togliere l'accesso non è chiudere la sessione

Sono due azioni distinte, e fare solo la prima lascia una finestra aperta dietro di te.

La finestra non è infinita; un biglietto non vale un giorno intero. Ma non è nemmeno zero, e in una situazione urgente "si chiuderà tra poco" non è una risposta sufficiente.

Quando qualcuno se ne va, o una password è sospetta

Fai tre cose, in ordine.

Togli il permesso. Disattiva anche l'account se è il caso.

Cambia la password. Questo chiude la strada per ottenere un biglietto nuovo al posto di quello che ha. Togliere solo il permesso non lo fa.

Rimuovi i token di accesso a parte. È il passo che si salta più spesso. Un token non è una sessione: non scade da solo, vive finché non lo cancelli tu. Cambiare la password di un utente non invalida i suoi token. Quando rimuovi un utente, controlla a parte che fine hanno fatto i suoi token.

E chiudiamo un equivoco: l'autenticazione a due fattori qui non ti aiuta. Protegge il momento dell'accesso. Su una sessione già aperta non ha nulla da dire.

Il verso opposto: perché mi disconnette in continuazione

È l'altra faccia dello stesso meccanismo.

Il biglietto ha una durata limitata, e l'interfaccia lo rinnova regolarmente finché sei sulla scheda. Chiudi la scheda e torni ore dopo: nessun rinnovo è avvenuto, il biglietto è morto, ti viene chiesto di accedere di nuovo. Non è un guasto.

La seconda causa, meno nota, è più interessante: l'orologio della macchina. Un biglietto porta una marca temporale. Se l'orologio del server va alla deriva, un biglietto appena emesso può sembrare venire dal futuro o essere scaduto da tempo. Il sintomo confonde: la password è giusta, l'accesso pare accettato, e subito dopo la sessione cade. Cercare un problema di orologio dal lato dell'identità non viene in mente a nessuno, ma cercalo.

Cosa fa Atlas

In Atlas il cookie che va al browser non è il biglietto vero. Il browser porta solo un identificativo casuale privo di significato; il biglietto effettivo resta sul server.

La differenza è concreta: anche se una falla del browser legge il cookie, non se ne va con il biglietto stesso, quindi non può portarlo altrove e usarlo là. L'unica cosa che può fare è agire da quel browser finché quella sessione vive. Non è rischio zero, ma restringe la portata della minaccia.

Le sessioni aperte vengono scritte su disco, così quando il prodotto si aggiorna nessuno viene buttato fuori. La scrittura avviene di proposito in un unico passo: se il file fosse rimasto scritto a metà, allora, pur tollerandolo il lato lettura, tutte le sessioni aperte sarebbero cadute.

Quello che vale davvero la pena raccontare è un difetto trovato qui misurando.

I record di sessione scaduti venivano puliti solo dalla memoria, non dal file. È stata guardata una macchina in esercizio: nel file stavano cinque record scaduti, ognuno con dentro un biglietto. Sarebbero rimasti lì fino al prossimo accesso, perché nient'altro scriveva mai quel file.

L'intenzione del codice era già di non tenerli. L'unica cosa che mancava era il passo di scrittura.

La lezione vale per chiunque scriva codice di sicurezza: dimenticare ha due luoghi. Ciò che è stato tolto dalla memoria non è stato tolto dal disco, e dei due quello su disco vive sempre più a lungo. Quando decidi che una cosa non va conservata, la seconda domanda è sempre la stessa: dove viene conservata?