Le sessioni della tua app self-hosted scadono quando dovrebbero? Una checklist pratica di valutazione

Perché il comportamento delle sessioni conta dopo l’accesso

L’autenticazione conferma che un utente ha effettuato l’accesso. La sessione consente all’applicazione di riconoscere quell’utente mentre passa da una pagina all’altra o torna nell’app. Se una sessione resta utilizzabile più a lungo del previsto, qualcuno che ha accesso al browser o a una credenziale di sessione copiata potrebbe continuare a usare l’account.

Avere configurato un timeout non dimostra che ogni percorso rilevante scada come previsto. Il logout, la modifica di una password, la disattivazione di un account e il single sign-on possono coinvolgere parti diverse del sistema. Considera il comportamento delle sessioni come un ciclo di vita da valutare e testare nuovamente, non come una singola impostazione da individuare.

OWASP consiglia di applicare la scadenza delle sessioni lato server e di invalidare una sessione quando l’utente esegue il logout. NIST indica che i cookie di sessione dovrebbero scadere alla scadenza del periodo di validità della sessione o poco dopo. Sono controlli utili, ma non dimostrano che ogni applicazione offra gli stessi controlli o che ogni flusso debba avere un esito universale prescritto.

Distingui accesso, durata della sessione, timeout per inattività e dispositivi ricordati

Prima di esaminare le impostazioni, usa termini coerenti. L’accesso è la fase di autenticazione. La sessione è il riconoscimento continuativo, da parte dell’applicazione, di quell’accesso. La sessione può essere rappresentata o mantenuta tramite più di un meccanismo, quindi la sola scadenza visualizzata per un cookie del browser potrebbe non indicare se il server accetta ancora la sessione.

Un timeout per inattività limita una sessione dopo un periodo senza attività. L’età massima della sessione, talvolta chiamata durata assoluta, limita per quanto tempo una sessione può restare valida indipendentemente dall’attività. Non presumere che l’attività azzeri un limite assoluto o che un’impostazione chiamata «timeout sessione» abbia un significato univoco: consulta la documentazione dell’applicazione e verifica il comportamento.

Un’opzione «ricordami» o per ricordare un dispositivo può modificare l’esperienza dell’utente alla visita successiva. Verifica se, in quella specifica applicazione, ripristina una sessione, evita alcuni passaggi di autenticazione o svolge un’altra funzione. Registra separatamente il suo comportamento, senza considerarla equivalente a un timeout per inattività.

Definisci i requisiti in base ai flussi reali e ai rischi

Scegli i requisiti in base all’uso dell’applicazione e a ciò che una sessione lasciata incustodita o ancora valida potrebbe esporre. Una postazione condivisa, l’accesso a dati aziendali sensibili o la possibilità di apportare modifiche rilevanti possono richiedere aspettative diverse rispetto a un’app usata brevemente su un dispositivo privato.

Prima di eseguire i test, metti per iscritto il comportamento atteso. Per esempio, decidi cosa si aspetta la tua organizzazione dopo un periodo di inattività, al raggiungimento dell’età massima della sessione, dopo un logout esplicito e dopo la disattivazione di un account da parte di un amministratore. Per le modifiche delle password e gli eventi SSO, definisci l’esito necessario invece di presumere che l’applicazione o il provider di identità lo gestiscano automaticamente.

Le indicazioni citate qui non stabiliscono un unico valore di timeout valido per ogni applicazione e flusso di lavoro. Considera la scelta una decisione esplicita di sicurezza e usabilità e documenta eventuali eccezioni, per esempio un flusso in cui gli utenti devono mantenere aperta una sessione per un’attività di lunga durata.

• A quali dati o azioni si può accedere nell’app e cosa potrebbe consentire una sessione lasciata incustodita?
• È probabile che gli utenti lavorino su dispositivi condivisi o lasciati incustoditi?
• Cosa dovrebbe accadere dopo un periodo di inattività e qual è la durata massima accettabile di una sessione?
• Quali eventi dovrebbero interrompere l’accesso: logout, modifica della password, disattivazione dell’account o modifica da parte del provider di identità?
• È disponibile un’opzione per ricordare il dispositivo e il suo comportamento è accettabile per il tuo caso d’uso?

Consulta la documentazione dell’applicazione per individuare i controlli effettivi

Cerca nella documentazione ufficiale i riferimenti a scadenza delle sessioni, timeout per inattività, durata massima, logout, revoca delle sessioni, dispositivi ricordati e SSO. Consulta la documentazione relativa all’applicazione e alla versione che usi. Non dedurre che una funzione esista perché è presente in un prodotto dal nome simile o in un’impostazione di un’altra app.

Registra se ogni controllo è configurabile, dove si configura e se la documentazione descrive l’applicazione lato server. Se la documentazione non specifica un flusso, segnalo come sconosciuto e testalo oppure chiedi al fornitore o al manutentore. La scadenza di un cookie e una regola di validità della sessione lato server sono verifiche correlate, ma l’una non deve essere considerata prova dell’altra.

Le indicazioni di OWASP supportano la verifica della scadenza lato server e dell’invalidazione al logout. Quelle di NIST supportano il controllo che i cookie di sessione scadano alla scadenza del periodo di validità della sessione o poco dopo. Nessuno dei passaggi citati specifica quale comportamento aspettarsi per modifiche delle password, disattivazione degli account, età massima o sessioni del provider di identità: verifica questi casi per la tua app.

• Registra il significato documentato di ogni impostazione di timeout, compreso se l’attività la azzera.
• Cerca una modalità documentata per terminare o revocare le sessioni attive e annotane l’ambito.
• Verifica se il comportamento delle sessioni è diverso per gli account locali e per gli utenti SSO.
• Conserva il titolo della documentazione consultata, la versione o la data se disponibili e la data della revisione.

Esegui test pratici del ciclo di vita

Se possibile, usa un account di test e un ambiente non di produzione. Se devi eseguire i test in produzione, pianifica il lavoro in modo da non interrompere altri utenti o modificare inavvertitamente l’accesso ad account reali. Mantieni non sensibili i dati dell’account di test ed evita di inserire credenziali di sessione o altri segreti in schermate o note condivise.

Per verificare l’inattività, accedi, lascia l’app inutilizzata per l’intervallo configurato e poi prova ad aprire una pagina protetta o a eseguire un’azione innocua. Verifica separatamente l’aspettativa sull’età massima con una sessione attiva: mantienila attiva secondo il piano di test e controlla se termina al limite indicato. Registra il tempo trascorso e ciò che vede l’utente.

Per il logout, esci e poi prova a visitare di nuovo una pagina protetta usando lo stesso contesto del browser. OWASP consiglia che il logout invalidi la sessione; registra se la vecchia sessione consente ancora di accedere a contenuti protetti. Non considerare sufficiente il solo reindirizzamento alla pagina di accesso se i contenuti protetti restano raggiungibili tramite un altro percorso.

Verifica la modifica della password e la disattivazione dell’account come eventi distinti. Per ciascuno, determina se le sessioni esistenti continuano a funzionare, se la modifica influisce solo sugli accessi futuri e se il comportamento corrisponde al requisito scritto. Le indicazioni primarie fornite non stabiliscono un esito universale obbligatorio per questi casi: documenta quindi la tua policy e verifica il comportamento dell’applicazione invece di fare supposizioni.

Usa un’azione di test innocua e autorizzata per confermare lo stato dell’accesso. Se l’esito non è chiaro, ripeti il test in una sessione pulita del browser e consulta la documentazione dell’applicazione o il relativo canale di supporto.

Ripeti le verifiche per SSO e account locali

Se l’applicazione supporta sia l’accesso locale sia il single sign-on, testa separatamente ciascun percorso. L’applicazione e il provider di identità possono avere sessioni distinte; terminare una sessione non dimostra, di per sé, che sia terminata anche l’altra. Allo stesso modo, uscire da un’applicazione non comporta necessariamente la disconnessione dell’utente dal provider di identità.

Per l’SSO, registra sequenza ed esito per il logout dall’applicazione, il logout dal provider di identità, le modifiche delle password e la disattivazione degli account. Verifica cosa succede quando l’utente torna nell’app e quando prova a usare una pagina dell’app già aperta. Per gli account locali, ripeti i test pertinenti senza presumere che si applichi il comportamento SSO.

Se il provider di identità o l’applicazione offre controlli per revocare le sessioni, documenta quali sessioni dichiara di revocare e conferma l’effetto in un test. Se il comportamento del sistema non è documentato o verificabile, mantienilo come lacuna irrisolta invece di interpretare un reindirizzamento apparentemente riuscito come prova.

Registra comportamento atteso e prove in una matrice di test delle sessioni

Una matrice concisa trasforma verifiche occasionali in evidenze operative ripetibili. Tieni separato il risultato atteso da quello osservato: il primo riflette la tua policy, mentre il secondo descrive ciò che l’app ha fatto durante il test.

Includi applicazione e versione, percorso di autenticazione, data del test, configurazione pertinente, account di test, passaggi, tempo trascorso quando rilevante, risultato osservato e stato superato, non superato o irrisolto. Annota la documentazione consultata e l’azione successiva prevista per le lacune. Evita di registrare password, token di sessione o altre credenziali.

Ripeti la matrice dopo modifiche sostanziali alla configurazione dell’applicazione, all’impostazione dell’autenticazione o alla distribuzione. La pianificazione delle verifiche è una scelta operativa del tuo team: le fonti citate qui non prescrivono un intervallo di retest.

• Inattività: condizione di terminazione attesa; intervallo di inattività testato; verifica dell’eventuale persistenza dell’accesso a contenuti protetti.
• Età massima della sessione: limite atteso; verifica che la sessione sia rimasta attiva durante il test; ora di terminazione osservata ed esito.
• Logout: invalidazione attesa; esito del riutilizzo dello stesso contesto del browser.
• Modifica della password: impatto atteso sulle sessioni esistenti; esito per l’account testato.
• Disattivazione dell’account: impatto atteso; esito dei tentativi di accesso esistenti e nuovi.
• SSO e accesso locale: testa ogni percorso applicabile e registra a quale sistema apparteneva la sessione.
• Lacune: controlli non documentati, risultati non verificabili e responsabile delle verifiche successive.

Assegna le responsabilità tra applicazione, provider di identità e hosting

Non presumere che un’unica parte controlli l’intero ciclo di vita delle sessioni. Associa ogni comportamento atteso al componente che può configurarlo o verificarlo nella tua distribuzione. La ripartizione precisa dipende dall’applicazione, dal provider di identità, dalla modalità di hosting e dagli accordi in vigore; le indicazioni citate non assegnano responsabilità tra queste parti.

Il responsabile dell’applicazione dovrebbe documentare la policy di accesso, verificare il comportamento dell’applicazione e decidere come gestire le lacune irrisolte. Per i flussi SSO, coordínati con l’amministratore del provider di identità per comprendere i suoi controlli relativi a sessioni e account, quindi testa l’esperienza nel suo complesso. Rendi esplicita la ripartizione dei compiti, invece di affidarti alla generica supposizione che SSO o hosting gestiscano la revoca.

Anche le responsabilità dell’hosting devono essere definite chiaramente. Airbip offre la distribuzione gestita delle applicazioni a catalogo come workload Docker su server cloud Airbip, con instradamento automatizzato e certificati TLS tramite Traefik e Let’s Encrypt, oltre alla gestione del ciclo di vita dei servizi e backup configurabili. Queste funzionalità infrastrutturali, da sole, non dimostrano cosa faccia un’applicazione quando una sessione scade o un account viene disattivato. Verifica il comportamento a livello applicativo e concorda chi gestisce ciascuna attività operativa.

Se la tua organizzazione necessita di un controllo delle sessioni che l’applicazione non offre, non considerare la gestione dell’infrastruttura un sostituto, a meno che un controllo documentato e testato non soddisfi il requisito. Registra la lacuna e decidi se modificare la configurazione, aggiungere un controllo adeguato, scegliere un’altra applicazione o modalità di distribuzione oppure accettare il rischio residuo.

• Indica chi è responsabile della policy sui timeout e chi approva le eccezioni.
• Indica chi configura e testa il comportamento delle sessioni a livello applicativo.
• Per l’SSO, identifica l’amministratore del provider di identità e i comportamenti che può confermare.
• Documenta separatamente le attività di hosting rispetto all’accesso all’applicazione e alla governance degli account.
• Tieni traccia di ogni comportamento non verificato come elemento aperto, con una decisione o un’azione successiva.