Sessione

Sessione, in informatica e telecomunicazioni, è un termine che può essere utilizzato per indicare:^[1]

• il colloquio tra utente ed elaboratore su un determinato argomento, tipicamente un'applicazione software;
• l'attività svolta tra due entità per trasferire dati in entrambi i sensi per tutta la durata del collegamento ovvero compreso all'interno del tempo di connessione tra le entità stesse.

Con il suo significato di base il termine è entrato in questi ambiti intorno agli anni settanta. Si parla di livello di sessione nel caso si parli di modello OSI.

In inglese, la parola "sessione" si riferisce a un periodo di tempo discreto durante il quale viene eseguita un'attività. Una sessione web è quindi il tempo che un utente trascorre navigando su un determinato sito web: dal momento in cui arriva sulla prima pagina, al momento in cui lascia il sito^[2].

Una sessione web è costituita da dati o file che sono persistenti durante l'uso di un sito web o di un'applicazione web. Queste risorse sono identificate in modo univoco con un ID di sessione. Il browser dell'utente riceve questo ID all'inizio di una nuova sessione e questo ID viene scambiato durante ogni successiva comunicazione tra il browser e il server^[3].

Una sessione web include tutte le informazioni che possono essere rilevanti durante la visita dell'utente. A seconda dello scopo del sito Web o dell'applicazione Web, ciò può includere dati come:

• Le pagine visualizzate dall'utente
• I dettagli di contatto che l'utente ha inserito in un modulo
• Gli articoli nel carrello degli acquisti dell'utente

Di solito esiste un limite di tempo massimo per le sessioni web, dopo il quale la sessione scadrà. Questo limite di tempo massimo dipende dall'attuazione. Ad esempio, le sessioni web in Google Analytics scadono dopo 30 minuti di inattività; l'ulteriore attività dell'utente verrà trattata come una nuova sessione.

I siti Web e le applicazioni Web con un numero molto elevato di utenti spesso memorizzano nella cache le sessioni Web, in modo che possano essere recuperate in modo più rapido ed efficiente.

I vantaggi dell'utilizzo delle sessioni web sono evidenti: le sessioni web consentono al sito web di avere una qualche forma di "memoria a breve termine" sull'attività di un utente.

Da un lato, non avere alcuna memoria degli utenti sarebbe estremamente scomodo. Se un sito Web di e-commerce non è in grado di ricordare le azioni di un utente, ad esempio, gli utenti dovrebbero effettuare ordini di e-commerce tutti in una volta all'interno di una singola azione, invece di memorizzare gli articoli in un carrello della spesa.

D'altra parte, anche avere una memoria troppo lunga può essere poco pratico. Ad esempio, se un utente torna su un sito di e-commerce dopo un mese, potrebbe non voler vedere gli stessi articoli nel carrello degli acquisti dell'ultima volta.

Le sessioni web rappresentano un equilibrio tra questi due estremi. Le sessioni Web a breve termine forniscono ai siti Web e alle applicazioni Web una "memoria" sufficiente per creare esperienze utente coinvolgenti e personalizzate nel corso della visita di un utente, senza memorizzare troppe informazioni irrilevanti a lungo termine.

Le sessioni Web vengono spesso confrontate (e confuse con) i cookie. Sebbene sia i cookie che le sessioni web memorizzino informazioni su un utente, le loro funzioni sono diverse nella pratica.

I cookie sono file di testo che vengono utilizzati per autenticare e tenere traccia dei visitatori di un sito Web e che vengono memorizzati solo sulla macchina dell'utente. La durata di un cookie è in genere molto più lunga di quella di una sessione web, nell'ordine di mesi o addirittura anni. I cookie sono il modo in cui i siti Web memorizzano le informazioni dell'utente a lungo termine che dovrebbero essere preservate: ad esempio, accedendo automaticamente all'utente quando arriva al sito Web o compilando automaticamente un modulo con i dettagli dell'utente.

Al contrario, le sessioni web hanno lo scopo di memorizzare informazioni solo sulle attività più recenti dell'utente. Le sessioni Web vengono archiviate sul server anziché sul client, il che consente di impedire agli utenti malintenzionati di modificarle. Sia le sessioni web che i cookie possono essere utilizzati in combinazione per tenere traccia del comportamento a lungo e breve termine degli utenti.

Il ciclo di sessione comprende tre fasi^[4]:

• Avvio o apertura: Si avvia uno scambio di informazioni tra l'utente (od anche il client) che intende avvalersi di un servizio e il server che sovraintende tale servizio. La procedura più nota e comune è quella di login. Il server prepara e memorizza un pacchetto di informazioni permanenti che diventeranno i parametri di sessione e, per l'utente, i suoi dati di lavoro per tutta la sessione (solitamente i dati preparati dal server vengono inseriti nei cookie, che a loro volta vengono scaricati dai web Browser e sfruttati per mantenere la sessione del servizio attivo, senza dover ogni volta reinserire i dati manualmente.)

• Lavoro in sessione: Il colloquio prosegue, sempre con lo scambio delle informazioni di sessione. Le tipiche applicazioni per il web prevedono spesso che nell'arco della sessione parte di queste informazioni possano essere variate o aggiunte di nuove.

• Chiusura: Su richiesta dell'utente o del client il server cancella le informazioni di sessione. In assenza di una specifica richiesta, nella gran parte delle applicazioni è prevista la chiusura o fine automatica di sessione, dopo un certo tempo in cui l'utente/client non invia alcun messaggio.

Una sessione Web è una sequenza di richieste HTTP di rete e transazioni di risposta associate allo stesso utente. Le applicazioni Web moderne e complesse richiedono la conservazione delle informazioni o dello stato di ciascun utente per la durata di più richieste. Pertanto, le sessioni forniscono la possibilità di stabilire variabili, come diritti di accesso e impostazioni di localizzazione, che si applicheranno a ogni interazione che un utente ha con l'applicazione web per la durata della sessione.

Le applicazioni Web possono creare sessioni per tenere traccia degli utenti anonimi dopo la prima richiesta dell'utente. Un esempio potrebbe essere il mantenimento della preferenza della lingua dell'utente. Inoltre, le applicazioni Web utilizzeranno le sessioni una volta che l'utente si è autenticato. Ciò garantisce la capacità di identificare l'utente su eventuali richieste successive oltre a poter applicare controlli di sicurezza di accesso, accesso autorizzato ai dati privati dell'utente e aumentare l'usabilità dell'applicazione. Pertanto, le attuali applicazioni Web possono fornire funzionalità di sessione sia prima che dopo l'autenticazione.

Una volta stabilita una sessione autenticata, l'ID sessione (o token) è temporaneamente equivalente al metodo di autenticazione più forte utilizzato dall'applicazione, come nome utente e password, passphrase, password monouso (OTP), certificati digitali basati su client, smartcard o dati biometrici (come impronte digitali o retina oculare).

HTTP è un protocollo senza stato (RFC2616 sezione 5), in cui ogni coppia di richieste e risposte è indipendente da altre interazioni web. Pertanto, al fine di introdurre il concetto di sessione, è necessario implementare funzionalità di gestione della sessione che colleghino sia i moduli di autenticazione che di controllo di accesso (o autorizzazione) comunemente disponibili nelle applicazioni web^[4]:

• L'ID di sessione o il token associa le credenziali di autenticazione dell'utente (sotto forma di una sessione utente) al traffico HTTP dell'utente e ai controlli di accesso appropriati applicati dall'applicazione web. La complessità di questi tre componenti (autenticazione, gestione della sessione e controllo degli accessi) nelle moderne applicazioni web, oltre al fatto che la sua implementazione e associazione risiede nelle mani dello sviluppatore web (poiché i framework di sviluppo web non forniscono relazioni strette tra questi moduli), rende molto impegnativa l'implementazione di un modulo di gestione delle sessioni sicuro.
• La divulgazione, l'acquisizione, la previsione, la forza bruta o la fissazione dell'ID di sessione porteranno ad attacchi di dirottamento della sessione (o sidejacking), in cui un utente malintenzionato è in grado di impersonare completamente un utente vittima nell'applicazione web. Gli aggressori possono eseguire due tipi di attacchi di dirottamento della sessione, mirati o generici. In un attacco mirato, l'obiettivo dell'aggressore è impersonare un utente vittima dell'applicazione Web specifico (o privilegiato). Per gli attacchi generici, l'obiettivo dell'aggressore è impersonare (o ottenere l'accesso come) qualsiasi utente valido o legittimo nell'applicazione web.

Per mantenere lo stato autenticato e tenere traccia dei progressi degli utenti all'interno dell'applicazione web, le applicazioni forniscono agli utenti un identificatore di sessione (ID sessione o token^[5]) che viene assegnato al momento della creazione della sessione e viene condiviso e scambiato dall'utente e dall'applicazione web per tutta la durata della sessione (viene inviato ad ogni richiesta HTTP). L'ID sessione è una coppia name=value.

Con l'obiettivo di implementare ID di sessione protetti, la generazione di identificatori (ID o token) deve soddisfare le seguenti proprietà.

Il nome utilizzato dall'ID di sessione non deve essere estremamente descrittivo né offrire dettagli non necessari sullo scopo e sul significato dell'ID.

I nomi degli ID di sessione utilizzati dai framework di sviluppo di applicazioni Web più comuni possono essere facilmente rilevati tramite fingerprint, come PHPSESSID(PHP), JSESSIONID(J2EE), CFID& CFTOKEN(ColdFusion), ASP.NET_SessionId(ASP.NET), ecc. Pertanto, il nome dell'ID di sessione può rivelare il tecnologie e linguaggi di programmazione utilizzati dall'applicazione web.

Si consiglia di modificare il nome dell'ID di sessione predefinito del framework di sviluppo Web con un nome generico, ad esempio id.

L'ID sessione deve essere sufficientemente lungo da impedire attacchi di forza bruta, in cui un utente malintenzionato può passare attraverso l'intero intervallo di valori ID e verificare l'esistenza di sessioni valide.

• La lunghezza dell'ID sessione deve essere almeno 128 bit (16 byte).

• La lunghezza dell'ID di sessione di 128 bit viene fornita come riferimento in base alle ipotesi fatte nella sezione successiva Entropia dell'ID di sessione. Tuttavia, questo numero non deve essere considerato un valore minimo assoluto, poiché altri fattori di implementazione potrebbero influenzarne la forza.
• Ad esempio, esistono implementazioni ben note, come ID di sessione Microsoft ASP.NET: "L'identificatore di sessione ASP.NET è un numero generato in modo casuale codificato in una stringa di 24 caratteri composta da caratteri minuscoli dalla A alla Z e da numeri da 0 a 5 ".
• Può fornire un'entropia efficace molto buona e, di conseguenza, può essere considerato abbastanza lungo da evitare supposizioni o attacchi di forza bruta.

L'ID di sessione deve essere imprevedibile (abbastanza casuale) per evitare attacchi di indovinazione, in cui un utente malintenzionato è in grado di indovinare o prevedere l'ID di una sessione valida attraverso tecniche di analisi statistica. A tal fine, è necessario utilizzare un buon CSPRNG (Cryptographically Secure Pseudorandom Number Generator)^[4].

Il valore dell'ID di sessione deve fornire almeno l'entropia 64 bit (se viene utilizzato un buon PRNG, questo valore è stimato essere la metà della lunghezza dell'ID di sessione).

Inoltre, un ID di sessione casuale non è sufficiente; deve anche essere univoco per evitare ID duplicati. Un ID di sessione casuale non deve già esistere nello spazio dell'ID di sessione corrente.

• L'entropia dell'ID di sessione è realmente influenzata da altri fattori esterni e difficili da misurare, come il numero di sessioni attive simultanee che l'applicazione web ha comunemente, il timeout assoluto di scadenza della sessione, la quantità di tentativi ID di sessione al secondo che l'attaccante può fare e il l'applicazione web di destinazione può supportare, ecc.
• Se viene utilizzato un ID di sessione con un'entropia di 64 bit, un utente malintenzionato impiegherà almeno 292 anni per indovinare con successo un ID di sessione valido, supponendo che l'attaccante possa provare 10.000 tentativi al secondo con 100.000 sessioni simultanee valide disponibili nell'applicazione web.

Il contenuto (o valore) dell'ID di sessione deve essere privo di significato per prevenire attacchi di divulgazione di informazioni, in cui un utente malintenzionato è in grado di decodificare il contenuto dell'ID ed estrarre i dettagli dell'utente, della sessione o del funzionamento interno dell'applicazione web.

L'ID sessione deve essere semplicemente un identificatore sul lato client e il suo valore non deve mai includere informazioni sensibili (o PII).

Il significato e la logica aziendale o dell'applicazione associata all'ID sessione devono essere archiviati sul lato server e, in particolare, negli oggetti sessione o in un database o repository di gestione delle sessioni.

Le informazioni memorizzate possono includere indirizzo IP del client, agente utente, e-mail, nome utente, ID utente, ruolo, livello di privilegio, diritti di accesso, preferenze di lingua, ID account, stato corrente, ultimo accesso, timeout di sessione e altre sessioni interne dettagli. Se gli oggetti e le proprietà della sessione contengono informazioni sensibili, come i numeri di carta di credito, è necessario crittografare e proteggere adeguatamente il repository di gestione della sessione.

Si consiglia di creare ID di sessione crittograficamente efficaci tramite l'uso di funzioni hash crittografiche come SHA256^[4].

L'implementazione della gestione della sessione definisce il meccanismo di scambio che verrà utilizzato tra l'utente e l'applicazione Web per condividere e scambiare continuamente l'ID di sessione. Ci sono più meccanismi disponibili in HTTP per mantenere lo stato della sessione all'interno delle applicazioni web, come i cookie (intestazione HTTP standard), i parametri URL (riscrittura URL - RFC2396), argomenti URL su richieste GET, argomenti del corpo su richieste POST, come campi modulo nascosti (Moduli HTML) o intestazioni HTTP proprietarie^[4].

Il meccanismo di scambio dell'ID di sessione preferito dovrebbe consentire la definizione di proprietà avanzate del token, come la data e l'ora di scadenza del token o vincoli di utilizzo granulari. Questo è uno dei motivi per cui i cookie (RFC 2109 e 2965 e 6265) sono uno dei meccanismi di scambio dell'ID di sessione più ampiamente utilizzati, offrendo funzionalità avanzate non disponibili in altri metodi.

L'utilizzo di specifici meccanismi di scambio dell'ID di sessione, come quelli in cui l'ID è incluso nell'URL, potrebbe rivelare l'ID di sessione (nei collegamenti e nei registri Web, nella cronologia e nei segnalibri del browser Web, nell'intestazione del referer o nei motori di ricerca), nonché facilitare altri attacchi, come la manipolazione dell'ID o attacchi di fissazione della sessione.

I framework di sviluppo Web, come J2EE, ASP.NET, PHP e altri, forniscono le proprie funzionalità di gestione delle sessioni e l'implementazione associata. Si consiglia di utilizzare questi framework incorporati anziché crearne uno fatto in casa da zero, poiché vengono utilizzati in tutto il mondo su più ambienti Web e sono stati testati dalle comunità di sviluppo e sicurezza delle applicazioni Web nel tempo^[4].

Tuttavia, tieni presente che questi framework hanno anche presentato vulnerabilità e punti deboli in passato, quindi è sempre consigliabile utilizzare l'ultima versione disponibile, che potenzialmente risolve tutte le vulnerabilità note, nonché rivedere e modificare la configurazione predefinita per migliorare la sua sicurezza seguendo le raccomandazioni descritte in questo documento.

Le capacità di archiviazione o il repository utilizzato dal meccanismo di gestione delle sessioni per salvare temporaneamente gli ID di sessione devono essere protetti, proteggendo gli ID di sessione dalla divulgazione accidentale locale o remota o dall'accesso non autorizzato.

Un'applicazione web dovrebbe utilizzare i cookie per la gestione dello scambio di ID di sessione. Se un utente invia un ID di sessione tramite un meccanismo di scambio diverso, come un parametro URL, l'applicazione Web dovrebbe evitare di accettarlo come parte di una strategia difensiva per interrompere la fissazione della sessione^[4].

• Anche se un'applicazione web utilizza i cookie come meccanismo di scambio dell'ID di sessione predefinito, potrebbe accettare anche altri meccanismi di scambio.
• È quindi necessario confermare tramite test approfonditi tutti i diversi meccanismi attualmente accettati dall'applicazione Web durante l'elaborazione e la gestione degli ID di sessione e limitare i meccanismi di tracciamento dell'ID di sessione accettati ai soli cookie.
• In passato, alcune applicazioni Web utilizzavano parametri URL, o addirittura passavano dai cookie ai parametri URL (tramite riscrittura URL automatica), se sono soddisfatte determinate condizioni (ad esempio, l'identificazione di client Web senza supporto per i cookie o la mancata accettazione dei cookie a causa di preoccupazioni relative alla privacy degli utenti).

Al fine di proteggere lo scambio di ID di sessione da intercettazioni attive e divulgazioni passive nel traffico di rete, è essenziale utilizzare una connessione HTTPS (TLS) crittografata per l'intera sessione web, non solo per il processo di autenticazione in cui vengono scambiate le credenziali dell'utente.

Inoltre, l'attributo Secure cookie deve essere utilizzato per garantire che l'ID di sessione venga scambiato solo tramite un canale crittografato. L'utilizzo di un canale di comunicazione crittografato protegge anche la sessione da alcuni attacchi di fissazione della sessione in cui l'attaccante è in grado di intercettare e manipolare il traffico web per iniettare (o correggere) l'ID di sessione sul browser web della vittima^[4].

La seguente serie di best practice si concentra sulla protezione dell'ID di sessione (in particolare quando vengono utilizzati i cookie) e aiuta con l'integrazione di HTTPS all'interno dell'applicazione web:

• Non passare una determinata sessione da HTTP a HTTPS o viceversa, poiché ciò rivelerà l'ID di sessione in chiaro attraverso la rete.
  • Quando si esegue il reindirizzamento a HTTPS, assicurarsi che il cookie sia impostato o rigenerato dopo che si è verificato il reindirizzamento.
• Non mischiare contenuti crittografati e non crittografati (pagine HTML, immagini, CSS, file JavaScript, ecc.) Nella stessa pagina o dallo stesso dominio.
• Ove possibile, evitare di offrire contenuti pubblici non crittografati e contenuti privati crittografati dallo stesso host. Laddove è richiesto contenuto non sicuro, considera di ospitarlo su un dominio non sicuro separato.
• Implementare HTTP Strict Transport Security (HSTS) per applicare le connessioni HTTPS.

Vedere il foglio illustrativo della protezione del livello di trasporto OWASP per una guida più generale sull'implementazione sicura di TLS.

È importante sottolineare che TLS non protegge dalla previsione dell'ID di sessione, dalla forza bruta, dalla manomissione o dalla correzione sul lato client; tuttavia, fornisce una protezione efficace contro un utente malintenzionato che intercetta o ruba ID di sessione tramite un attacco man in the middle.

Lo stesso argomento in dettaglio: Cookie.

Il meccanismo di scambio dell'ID di sessione basato sui cookie fornisce più funzionalità di sicurezza sotto forma di attributi dei cookie che possono essere utilizzati per proteggere lo scambio dell'ID di sessione^[4]:

L'attributo cookie Secure indica ai browser Web di inviare il cookie solo tramite una connessione HTTPS (SSL/TLS) crittografata. Questo meccanismo di protezione della sessione è obbligatorio per impedire la divulgazione dell'ID di sessione tramite attacchi MitM (Man-in-the-Middle). Assicura che un utente malintenzionato non possa semplicemente acquisire l'ID di sessione dal traffico del browser web.

Forzare l'applicazione Web a utilizzare solo HTTPS per la sua comunicazione (anche quando la porta TCP/80, HTTP, è chiusa nell'host dell'applicazione Web) non protegge dalla divulgazione dell'ID di sessione se il cookie Secure non è stato impostato: il browser Web può essere ingannato per rivelare l'ID di sessione su una connessione HTTP non crittografata. L'aggressore può intercettare e manipolare il traffico dell'utente vittima e iniettare un riferimento HTTP non crittografato all'applicazione Web che costringerà il browser Web a inviare l'ID di sessione in chiaro.

L'attributo cookie HttpOnly indica ai browser Web di non consentire agli script (ad esempio JavaScript o VBscript) la possibilità di accedere ai cookie tramite l'oggetto document.cookie DOM. Questa protezione dell'ID di sessione è obbligatoria per impedire il furto dell'ID di sessione tramite attacchi XSS. Tuttavia, se un attacco XSS è combinato con un attacco CSRF, le richieste inviate all'applicazione web includeranno il cookie di sessione, poiché il browser include sempre i cookie quando invia le richieste. Il cookieHttpOnly protegge solo la riservatezza del cookie; l'attaccante non può utilizzarlo offline, al di fuori del contesto di un attacco XSS.

SameSite consente a un server di definire un attributo di cookie rendendo impossibile al browser inviare questo cookie insieme a richieste cross-site. L'obiettivo principale è mitigare il rischio di fuga di informazioni tra le origini e fornire una certa protezione contro gli attacchi di falsificazione delle richieste tra siti.

L'attributo cookie Domain indica ai browser Web di inviare il cookie solo al dominio specificato e a tutti i sottodomini. Se l'attributo non è impostato, per impostazione predefinita il cookie verrà inviato solo al server di origine. L'attributo cookiePath indica ai browser Web di inviare il cookie solo alla directory o alle sottodirectory specificate (o percorsi o risorse) all'interno dell'applicazione Web. Se l'attributo non è impostato, per impostazione predefinita il cookie verrà inviato solo per la directory (o percorso) della risorsa richiesta e l'impostazione del cookie.

Si consiglia di utilizzare un ambito ristretto o limitato per questi due attributi. In questo modo, l'attributo Domain non dovrebbe essere impostato (limitando il cookie solo al server di origine) e l'attributo Path dovrebbe essere impostato il più restrittivo possibile al percorso dell'applicazione web che utilizza l'ID di sessione.

L'impostazione dell'attributo Domain su un valore troppo permissivo, ad esempio example.comconsente a un utente malintenzionato di lanciare attacchi agli ID di sessione tra diversi host e applicazioni Web appartenenti allo stesso dominio, noti come cookie cross-sottodominio. Ad esempio, le vulnerabilità in www.example.compotrebbero consentire a un utente malintenzionato di ottenere l'accesso agli ID di sessione da secure.example.com.

Inoltre, si consiglia di non mischiare applicazioni web di diversi livelli di sicurezza sullo stesso dominio. Le vulnerabilità in una delle applicazioni Web consentirebbero a un utente malintenzionato di impostare l'ID di sessione per un'applicazione Web diversa sullo stesso dominio utilizzando un attributo Domain permissivo (come example.com) che è una tecnica che può essere utilizzata negli attacchi di correzione della sessione^[4].

Sebbene l'attributo Path consenta l'isolamento degli ID di sessione tra diverse applicazioni Web utilizzando percorsi diversi sullo stesso host, si consiglia vivamente di non eseguire applicazioni Web diverse (soprattutto da diversi livelli di sicurezza o ambiti) sullo stesso host. Altri metodi possono essere utilizzati da queste applicazioni per accedere agli ID di sessione, come l'oggetto document.cookie. Inoltre, qualsiasi applicazione web può impostare cookie per qualsiasi percorso su quell'host.

I cookie sono vulnerabili agli attacchi di spoofing DNS, in cui un utente malintenzionato può manipolare la risoluzione DNS per forzare il browser Web a rivelare l'ID di sessione per un determinato host o dominio.

I meccanismi di gestione della sessione basati sui cookie possono utilizzare due tipi di cookie, cookie non persistenti (o di sessione) e cookie persistenti. Se un cookie presenta il Max-Age(che ha la preferenza su Expires) o gli attributi Expires, verrà considerato un cookie persistente e verrà memorizzato su disco dal browser Web in base alla data di scadenza^[4].

In genere, le funzionalità di gestione della sessione per tenere traccia degli utenti dopo l'autenticazione fanno uso di cookie non persistenti. In questo modo la sessione scompare dal client se l'istanza del browser Web corrente viene chiusa. Pertanto, si consiglia vivamente di utilizzare cookie non persistenti per scopi di gestione della sessione, in modo che l'ID di sessione non rimanga nella cache del client Web per lunghi periodi di tempo, da cui un utente malintenzionato può ottenerlo.

• Garantire che le informazioni sensibili non siano comprese, assicurando che le informazioni sensibili non siano persistenti/crittografate/archiviate in base alle necessità per la durata della necessità
• Garantire che le attività non autorizzate non possano aver luogo tramite la manipolazione dei cookie
• Assicurarsi che il flag di sicurezza sia impostato per impedire la trasmissione accidentale "sul cavo" in modo non sicuro
• Determina se tutte le transizioni di stato nel codice dell'applicazione controllano correttamente i cookie e impongono il loro utilizzo
• Assicurati che l'intero cookie debba essere crittografato se i dati sensibili sono persistenti nel cookie
• Definisci tutti i cookie utilizzati dall'applicazione, il loro nome e il motivo per cui sono necessari

Lo stesso argomento in dettaglio: HTML5.

Il Web Hypertext Application Technology Working Group (WHATWG) descrive le API di archiviazione Web HTML5 localStoragee sessionStorage, come meccanismi per l'archiviazione di coppie nome-valore lato client. A differenza dei cookie HTTP, i contenuti localStoragee sessionStoragenon vengono condivisi automaticamente all'interno delle richieste o risposte dal browser e vengono utilizzati per l'archiviazione dei dati lato client^[6][7][4].

I dati memorizzati utilizzando l' localStorageAPI sono accessibili dalle pagine caricate dalla stessa origine, definita come scheme (https://), host (example.com), port (443) e domain/realm (example.com). Ciò fornisce un accesso simile a questi dati come si otterrebbe utilizzando il flagsecure su un cookie, il che significa che i dati memorizzati da httpsnon possono essere recuperati tramite http. A causa del potenziale accesso simultaneo da finestre/thread separati, i dati archiviati utilizzando localStoragepotrebbero essere soggetti a problemi di accesso condiviso (come le race condition) e dovrebbero essere considerati non bloccanti (Web Storage API Spec).

I dati archiviati utilizzando l'API localStoragevengono conservati durante le sessioni di navigazione, estendendo il periodo di tempo in cui possono essere accessibili ad altri utenti del sistema.

Gli standard non richiedono che i dati localStoragesiano crittografati a riposo, il che significa che potrebbe essere possibile accedere direttamente a questi dati dal disco.

WHATWG suggerisce l'uso di localStorageper i dati a cui è necessario accedere attraverso finestre o schede, su più sessioni e dove potrebbe essere necessario archiviare grandi volumi di dati (multi-megabyte) per motivi di prestazioni.

L'API sessionStoragememorizza i dati all'interno del contesto della finestra da cui è stata chiamata, il che significa che la scheda 1 non può accedere ai dati archiviati dalla scheda 2. Inoltre, come l'API localStorage, i dati archiviati utilizzando l'API sessionStorage sono accessibili dalle pagine caricate dalla stessa origine, che è definito come scheme (https://), host (example.com), port (443) e domain/realm (example.com). Ciò fornisce un accesso simile a questi dati come si otterrebbe utilizzando il flagsecure su un cookie, il che significa che i dati memorizzati da httpsnon possono essere recuperati tramite http.

L'API sessionStorage memorizza i dati solo per la durata della sessione di navigazione corrente. Una volta chiusa la scheda, i dati non sono più recuperabili. Ciò non impedisce necessariamente l'accesso, nel caso in cui una scheda del browser venga riutilizzata o lasciata aperta. I dati possono anche persistere in memoria fino a un evento di garbage collection.

Gli standard non richiedono che i dati sessionStorage siano crittografati a riposo, il che significa che potrebbe essere possibile accedere direttamente a questi dati dal disco.

WHATWG suggerisce l'uso di sessionStorageper i dati rilevanti per un'istanza di un flusso di lavoro, come i dettagli per la prenotazione di un biglietto, ma in cui è possibile eseguire più flussi di lavoro contemporaneamente in altre schede. La natura del vincolo di finestra/scheda manterrà i dati dalla perdita tra i flussi di lavoro in schede separate.

In generale, i dati protetti o sensibili non devono essere archiviati in modo persistente negli archivi dati del browser poiché ciò potrebbe consentire la fuga di informazioni sui sistemi condivisi. Poiché i meccanismi di archiviazione Web sono API, ciò consente anche l'accesso da script iniettati, rendendolo meno sicuro dei cookie con il flaghttponly applicato. Sebbene sia possibile archiviare dati specifici del flusso di lavoro sessionStorageper utilizzarli in quella scheda/finestra specifica durante i ricaricamenti, le API di archiviazione Web dovrebbero essere trattate come archiviazione non sicura. Per questo motivo, se una soluzione aziendale richiede l'uso di localStorageosessionStorageper archiviare dati sensibili, una tale soluzione dovrebbe crittografare i dati e applicare protezioni di riproduzione. A causa della possibilità di accedere alle API di archiviazione Web tramite un attacco XSS, gli identificatori di sessione devono essere archiviati utilizzando cookie non persistenti, con i flag appropriati per proteggere da problemi di accesso non sicuro (Secure), XSS (HttpOnly) e CSRF (SameSite).

Lo stesso argomento in dettaglio: Web worker.

I Web Worker eseguono il codice JavaScript in un contesto globale separato da quello della finestra corrente. Esiste un canale di comunicazione con la finestra di esecuzione principale, che viene chiamato MessageChannel[4].

I web worker sono un'alternativa per l'archiviazione del browser dei segreti (di sessione) quando la persistenza dell'archiviazione durante l'aggiornamento della pagina non è un requisito. Affinché i Web Worker forniscano l'archiviazione sicura del browser, qualsiasi codice che richiede il segreto dovrebbe esistere all'interno del Web Worker e il segreto non dovrebbe mai essere trasmesso al contesto della finestra principale.

L'archiviazione dei segreti nella memoria di un Web Worker offre le stesse garanzie di sicurezza di un cookie HttpOnly: la riservatezza del segreto è protetta. Tuttavia, un attacco XSS può essere utilizzato per inviare messaggi al Web Worker per eseguire un'operazione che richiede il segreto. Il Web Worker restituirà il risultato dell'operazione al thread di esecuzione principale.

Il vantaggio di un'implementazione di Web Worker rispetto a un cookie HttpOnly è che un Web Worker consente ad un codice JavaScript isolato di accedere al segreto; un cookie HttpOnly non è accessibile a nessun JavaScript. Se il codice JavaScript frontend richiede l'accesso al segreto, l'implementazione del Web Worker è l'unica opzione di archiviazione del browser che preserva la riservatezza del segreto.

Gli ID sessione devono essere considerati non attendibili, come qualsiasi altro input utente elaborato dall'applicazione Web, e devono essere accuratamente convalidati e verificati. A seconda del meccanismo di gestione della sessione utilizzato, l'ID di sessione verrà ricevuto in un parametro GET o POST, nell'URL o in un'intestazione HTTP (ad esempio i cookie). Se le applicazioni Web non convalidano e filtrano i valori ID di sessione non validi prima di elaborarle, possono essere potenzialmente utilizzate per sfruttare altre vulnerabilità Web, come SQL injection se gli ID di sessione sono archiviati su un database relazionale o XSS persistente se gli ID di sessione vengono memorizzati e riflessi in seguito dall'applicazione web^[4].

L'ID sessione deve essere rinnovato o rigenerato dall'applicazione Web dopo qualsiasi modifica del livello di privilegio all'interno della sessione utente associata. Lo scenario più comune in cui la rigenerazione dell'ID di sessione è obbligatoria è durante il processo di autenticazione, poiché il livello di privilegio dell'utente passa dallo stato non autenticato (o anonimo) allo stato autenticato. È inoltre necessario considerare altri scenari comuni, come le modifiche alla password, le modifiche alle autorizzazioni o il passaggio da un ruolo utente normale a un ruolo di amministratore all'interno dell'applicazione Web. Per tutte queste pagine critiche dell'applicazione Web, gli ID di sessione precedenti devono essere ignorati, un nuovo ID di sessione deve essere assegnato a ogni nuova richiesta ricevuta per la risorsa critica e l'ID di sessione precedente o precedente deve essere distrutto.

I framework di sviluppo web più comuni forniscono funzioni e metodi di sessione per rinnovare l'ID di sessione, come request.getSession(true)& HttpSession.invalidate()(J2EE), Session.Abandon()& Response.Cookies.Add(new...)(ASP.NET) o session_start()& session_regenerate_id(true)(PHP).

La rigenerazione dell'ID di sessione è obbligatoria per prevenire attacchi di fissazione della sessione, in cui un utente malintenzionato imposta l'ID di sessione sul browser Web dell'utente della vittima invece di raccogliere l'ID di sessione della vittima, come nella maggior parte degli altri attacchi basati sulla sessione, e indipendentemente dall'utilizzo di HTTP o HTTPS. Questa protezione mitiga l'impatto di altre vulnerabilità basate sul Web che possono essere utilizzate anche per lanciare attacchi di correzione della sessione, come la suddivisione della risposta HTTP o XSS.

Una raccomandazione complementare è quella di utilizzare un ID di sessione o un nome token (o un set di ID di sessione) diversi prima e dopo l'autenticazione, in modo che l'applicazione Web possa tenere traccia degli utenti anonimi e degli utenti autenticati senza il rischio di esporre o legare la sessione dell'utente tra entrambi gli stati^[4].

Se l'applicazione Web utilizza i cookie come meccanismo di scambio dell'ID di sessione e più cookie sono impostati per una determinata sessione, l'applicazione Web deve verificare tutti i cookie (e applicare le relazioni tra di essi) prima di consentire l'accesso alla sessione dell'utente.

È molto comune per le applicazioni Web impostare una pre-autenticazione del cookie utente su HTTP per tenere traccia degli utenti non autenticati (o anonimi). Una volta che l'utente si autentica nell'applicazione Web, un nuovo cookie sicuro post-autenticazione viene impostato su HTTPS e viene stabilita un'associazione tra entrambi i cookie e la sessione utente. Se l'applicazione web non verifica entrambi i cookie per le sessioni autenticate, un utente malintenzionato può utilizzare il cookie non protetto di pre-autenticazione per ottenere l'accesso alla sessione dell'utente autenticato.

Le applicazioni Web dovrebbero cercare di evitare lo stesso nome di cookie per diversi percorsi o ambiti di dominio all'interno della stessa applicazione Web, poiché ciò aumenta la complessità della soluzione e potenzialmente introduce problemi di scoping.

Per ridurre al minimo il periodo di tempo in cui un utente malintenzionato può lanciare attacchi su sessioni attive e dirottarle, è obbligatorio impostare i timeout di scadenza per ogni sessione, stabilendo per quanto tempo una sessione rimarrà attiva. Una scadenza insufficiente della sessione da parte dell'applicazione web aumenta l'esposizione di altri attacchi basati sulla sessione, poiché per poter riutilizzare un ID di sessione valido e dirottare la sessione associata, l'aggressore deve essere ancora attivo^[4].

Minore è l'intervallo di sessione, minore è il tempo a disposizione di un utente malintenzionato per utilizzare l'ID di sessione valido. I valori di timeout di scadenza della sessione devono essere impostati in base allo scopo e alla natura dell'applicazione Web e bilanciare sicurezza e usabilità, in modo che l'utente possa completare comodamente le operazioni all'interno dell'applicazione Web senza che la sua sessione scada frequentemente.

Entrambi i valori di inattività e di timeout assoluto dipendono fortemente dalla criticità dell'applicazione Web e dei suoi dati. Gli intervalli di timeout di inattività comuni sono 2-5 minuti per applicazioni di alto valore e 15-30 minuti per applicazioni a basso rischio. I timeout assoluti dipendono da quanto tempo un utente utilizza normalmente l'applicazione. Se l'applicazione è destinata all'uso da parte di un impiegato per un'intera giornata, un intervallo di timeout assoluto appropriato potrebbe essere compreso tra 4 e 8 ore.

Quando una sessione scade, l'applicazione web deve intraprendere azioni attive per invalidare la sessione su entrambi i lati, client e server. Quest'ultimo è il più rilevante e obbligatorio dal punto di vista della sicurezza.

Per la maggior parte dei meccanismi di scambio di sessioni, le azioni lato client per invalidare l'ID di sessione si basano sulla cancellazione del valore del token. Ad esempio, per invalidare un cookie si consiglia di fornire un valore vuoto (o non valido) per l'ID di sessione e impostare l'attributo Expires(o Max-Age) su una data passata (nel caso in cui venga utilizzato un cookie persistente):Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT

Al fine di chiudere e invalidare la sessione lato server, è obbligatorio che l'applicazione web intraprenda azioni attive quando la sessione scade, o l'utente si disconnette attivamente, utilizzando le funzioni e le modalità offerte dai meccanismi di gestione della sessione, quali come HttpSession.invalidate()(J2EE), Session.Abandon()(ASP.NET) o session_destroy()/unset()(PHP).

Tutte le sessioni dovrebbero implementare un timeout di inattività o inattività. Questo timeout definisce la quantità di tempo in cui una sessione rimarrà attiva nel caso in cui non vi siano attività nella sessione, chiudendo e invalidando la sessione dopo il periodo di inattività definito dall'ultima richiesta HTTP ricevuta dall'applicazione Web per un determinato ID di sessione.

Il timeout di inattività limita le possibilità che un utente malintenzionato abbia di indovinare e utilizzare un ID di sessione valido di un altro utente. Tuttavia, se l'aggressore è in grado di dirottare una determinata sessione, il timeout di inattività non limita le azioni dell'aggressore, poiché può generare periodicamente attività sulla sessione per mantenerla attiva per periodi di tempo più lunghi.

La gestione e la scadenza del timeout della sessione devono essere applicate sul lato server. Se il client viene utilizzato per imporre il timeout della sessione, ad esempio utilizzando il token di sessione o altri parametri del client per tenere traccia dei riferimenti temporali (ad esempio il numero di minuti dall'ora di accesso), un utente malintenzionato potrebbe manipolarli per estendere la durata della sessione.

Tutte le sessioni dovrebbero implementare un timeout assoluto, indipendentemente dall'attività della sessione. Questo timeout definisce la quantità massima di tempo in cui una sessione può essere attiva, chiudendo e invalidando la sessione dopo il periodo assoluto definito da quando la sessione data è stata inizialmente creata dall'applicazione web. Dopo aver invalidato la sessione, l'utente è costretto a (ri) autenticarsi nuovamente nell'applicazione web e stabilire una nuova sessione.

La sessione assoluta limita la quantità di tempo che un utente malintenzionato può utilizzare una sessione dirottata e impersonare l'utente vittima.

In alternativa, l'applicazione web può implementare un timeout di rinnovo aggiuntivo dopo il quale l'ID di sessione viene automaticamente rinnovato, a metà della sessione utente, e indipendentemente dall'attività della sessione e, quindi, dal timeout di inattività.

Dopo un determinato periodo di tempo dalla creazione iniziale della sessione, l'applicazione Web può rigenerare un nuovo ID per la sessione utente e provare a impostarlo o rinnovarlo sul client. Il valore dell'ID di sessione precedente sarebbe ancora valido per un po' 'di tempo, adattando un intervallo di sicurezza, prima che il client sia a conoscenza del nuovo ID e inizi a usarlo. A quel punto, quando il client passa al nuovo ID all'interno della sessione corrente, l'applicazione invalida l'ID precedente.

Questo scenario riduce al minimo la quantità di tempo in cui un determinato valore di ID sessione, potenzialmente ottenuto da un utente malintenzionato, può essere riutilizzato per dirottare la sessione dell'utente, anche quando la sessione dell'utente vittima è ancora attiva. La sessione utente rimane attiva e aperta sul client legittimo, sebbene il valore dell'ID di sessione associato venga rinnovato periodicamente in modo trasparente durante la durata della sessione, ogni volta che scade il timeout di rinnovo. Pertanto, il timeout di rinnovo integra i timeout di inattività e assoluti, specialmente quando il valore di timeout assoluto si estende in modo significativo nel tempo (ad esempio, è un requisito dell'applicazione mantenere aperte le sessioni utente per lunghi periodi di tempo).

A seconda dell'implementazione, potenzialmente potrebbe esserci una condizione di competizione in cui l'attaccante con un ID di sessione precedente ancora valido invia una richiesta prima dell'utente vittima, subito dopo che il timeout di rinnovo è appena scaduto, e ottiene prima il valore per l'ID di sessione rinnovato. Almeno in questo scenario, l'utente vittima potrebbe essere a conoscenza dell'attacco poiché la sua sessione verrà interrotta improvvisamente perché il suo ID di sessione associato non è più valido.

Le applicazioni Web dovrebbero fornire meccanismi che consentano agli utenti sensibili alla sicurezza di chiudere attivamente la propria sessione una volta terminato di utilizzare l'applicazione Web.

Le applicazioni Web devono fornire un pulsante di disconnessione (disconnessione, uscita o chiusura sessione) visibile e facilmente accessibile, disponibile nell'intestazione o nel menu dell'applicazione Web e raggiungibile da ogni risorsa e pagina dell'applicazione Web, in modo che l'utente possa chiudere manualmente la sessione all'indirizzo in qualsiasi momento. Come descritto nella sezione Session_Expiration, l'applicazione web deve invalidare la sessione almeno sul lato server.

NOTA: Sfortunatamente, non tutte le applicazioni Web facilitano agli utenti la chiusura della sessione corrente. Pertanto, i miglioramenti sul lato client consentono agli utenti coscienziosi di proteggere le proprie sessioni aiutando a chiuderle diligentemente.

Anche dopo la chiusura della sessione, potrebbe essere possibile accedere ai dati privati o sensibili scambiati all'interno della sessione tramite la cache del browser web. Pertanto, le applicazioni Web devono utilizzare direttive di cache restrittive per tutto il traffico Web scambiato tramite HTTP e HTTPS, come le intestazioni Cache-Controle PragmaHTTP e/o tag META equivalenti su tutte o (almeno) le pagine Web sensibili.

Indipendentemente dalla politica della cache definita dall'applicazione Web, se è consentito il caching dei contenuti dell'applicazione Web, gli ID di sessione non devono mai essere memorizzati nella cache, quindi si consiglia vivamente di utilizzare la direttiva Cache-Control: no-cache="Set-Cookie, Set-Cookie2", per consentire ai client Web di memorizzare nella cache tutto tranne l'ID di sessione.

Le applicazioni Web possono integrare le difese di gestione delle sessioni descritte in precedenza con contromisure aggiuntive sul lato client. Le protezioni lato client, in genere sotto forma di controlli e verifiche JavaScript, non sono a prova di proiettile e possono essere facilmente sconfitte da un aggressore esperto, ma possono introdurre un altro livello di difesa che deve essere aggirato dagli intrusi^[4].

Le applicazioni Web possono utilizzare il codice JavaScript nella pagina di accesso per valutare e misurare il tempo trascorso da quando la pagina è stata caricata e è stato concesso un ID di sessione. Se viene tentato un tentativo di accesso dopo un determinato periodo di tempo, il codice client può notificare all'utente che è trascorso il tempo massimo per l'accesso e ricaricare la pagina di accesso, recuperando così un nuovo ID di sessione.

Questo meccanismo di protezione aggiuntivo cerca di forzare il rinnovo della pre-autenticazione dell'ID di sessione, evitando scenari in cui un ID di sessione precedentemente utilizzato (o impostato manualmente) viene riutilizzato dalla vittima successiva utilizzando lo stesso computer, ad esempio, negli attacchi di correzione della sessione.

Le applicazioni Web possono utilizzare il codice JavaScript per acquisire tutte le schede del browser Web o gli eventi di chiusura (o anche indietro) della finestra e intraprendere le azioni appropriate per chiudere la sessione corrente prima di chiudere il browser Web, emulando che l'utente ha chiuso manualmente la sessione tramite il logout pulsante.

Le applicazioni Web possono utilizzare il codice JavaScript una volta che l'utente ha effettuato l'accesso e una sessione è stata stabilita per forzare l'utente a eseguire nuovamente l'autenticazione se una nuova scheda o finestra del browser Web viene aperta per la stessa applicazione Web. L'applicazione Web non desidera consentire a più schede o finestre del browser Web di condividere la stessa sessione. Pertanto, l'applicazione tenta di forzare il browser Web a non condividere lo stesso ID di sessione contemporaneamente tra di loro.

Il codice JavaScript può essere utilizzato dall'applicazione Web in tutte le pagine (o critiche) per disconnettersi automaticamente dalle sessioni client allo scadere del timeout di inattività, ad esempio reindirizzando l'utente alla pagina di logout (la stessa risorsa utilizzata dal pulsante di logout menzionato in precedenza).

Il vantaggio di migliorare la funzionalità di timeout di inattività lato server con codice lato client è che l'utente può vedere che la sessione è terminata per inattività, o può anche essere avvisato in anticipo che la sessione sta per scadere tramite un conto alla rovescia e messaggi di avviso. Questo approccio intuitivo aiuta a evitare la perdita di lavoro nelle pagine Web che richiedono dati di input estesi a causa di sessioni scadute lato server.

Se un utente malintenzionato tenta di indovinare o forzare un ID di sessione valido, deve avviare più richieste sequenziali contro l'applicazione Web di destinazione utilizzando ID di sessione diversi da un singolo (o set di) indirizzi IP. Inoltre, se un utente malintenzionato cerca di analizzare la prevedibilità dell'ID di sessione (ad esempio utilizzando l'analisi statistica), deve lanciare più richieste sequenziali da un singolo (o insieme di) indirizzi IP contro l'applicazione web di destinazione per raccogliere nuovi validi ID di sessione^[4].

Le applicazioni Web devono essere in grado di rilevare entrambi gli scenari in base al numero di tentativi di raccogliere (o utilizzare) ID di sessione diversi e avvisare e/o bloccare gli indirizzi IP offensivi.

Le applicazioni Web dovrebbero concentrarsi sul rilevamento delle anomalie associate all'ID di sessione, come la sua manipolazione. Il progetto OWASP AppSensor fornisce un framework e una metodologia per implementare funzionalità di rilevamento delle intrusioni integrate all'interno di applicazioni Web incentrate sul rilevamento di anomalie e comportamenti imprevisti, sotto forma di punti di rilevamento e azioni di risposta. Invece di utilizzare livelli di protezione esterni, a volte i dettagli della logica di business e l'intelligence avanzata sono disponibili solo dall'interno dell'applicazione Web, dove è possibile stabilire più punti di rilevamento relativi alla sessione, ad esempio quando un cookie esistente viene modificato o eliminato, un nuovo cookie viene aggiunto, l'ID di sessione di un altro utente viene riutilizzato o quando la posizione dell'utente o l'agente utente cambia durante una sessione.

Con l'obiettivo di rilevare (e, in alcuni scenari, proteggere da) comportamenti scorretti dell'utente e dirottamento della sessione, si consiglia vivamente di associare l'ID di sessione ad altre proprietà utente o client, come l'indirizzo IP del client, utente-agente o client certificato digitale basato su. Se l'applicazione Web rileva qualsiasi cambiamento o anomalia tra queste diverse proprietà nel mezzo di una sessione stabilita, questo è un ottimo indicatore della manipolazione della sessione e dei tentativi di dirottamento e questo semplice fatto può essere utilizzato per avvisare e/o terminare la sessione sospetta.

Sebbene queste proprietà non possano essere utilizzate dalle applicazioni Web per difendersi in modo affidabile dagli attacchi di sessione, aumentano notevolmente le capacità di rilevamento (e protezione) delle applicazioni Web. Tuttavia, un utente malintenzionato esperto può aggirare questi controlli riutilizzando lo stesso indirizzo IP assegnato all'utente vittima condividendo la stessa rete (molto comune negli ambienti NAT, come gli hotspot Wi-Fi) o utilizzando lo stesso proxy Web in uscita (molto comune in ambienti aziendali) o modificando manualmente il suo agente utente in modo che appaia esattamente come fanno gli utenti vittima.

Le applicazioni Web dovrebbero aumentare le loro capacità di registrazione includendo informazioni riguardanti l'intero ciclo di vita delle sessioni. In particolare, si consiglia di registrare gli eventi relativi alla sessione, come la creazione, il rinnovo e la distruzione degli ID di sessione, nonché i dettagli sul suo utilizzo durante le operazioni di login e logout, le modifiche del livello di privilegio all'interno della sessione, la scadenza del timeout, la sessione non valida attività (se rilevate) e operazioni aziendali critiche durante la sessione.

I dettagli del registro potrebbero includere un timestamp, indirizzo IP di origine, risorsa di destinazione Web richiesta (e coinvolta in un'operazione di sessione), intestazioni HTTP (inclusi User-Agent e Referer), parametri GET e POST, codici e messaggi di errore, nome utente (o ID utente), più l'ID di sessione (cookie, URL, GET, POST...).

I dati sensibili come l'ID di sessione non devono essere inclusi nei registri al fine di proteggere i registri di sessione dalla divulgazione locale o remota dell'ID di sessione o da accessi non autorizzati. Tuttavia, è necessario registrare un certo tipo di informazioni specifiche della sessione per correlare le voci di registro a sessioni specifiche. Si consiglia di registrare un hash salato dell'ID di sessione invece dell'ID di sessione stesso per consentire la correlazione del registro specifica della sessione senza esporre l'ID di sessione.

In particolare, le applicazioni web devono proteggere a fondo le interfacce amministrative che permettano di gestire tutte le sessioni attive correnti. Spesso vengono utilizzati dal personale di supporto per risolvere problemi relativi alla sessione, o anche problemi generali, impersonando l'utente e osservando l'applicazione Web come fa l'utente.

I registri di sessione diventano una delle principali fonti di dati di rilevamento delle intrusioni nelle applicazioni Web e possono anche essere utilizzati dai sistemi di protezione dalle intrusioni per terminare automaticamente le sessioni e/o disabilitare gli account utente quando vengono rilevati (uno o più) attacchi. Se vengono implementate protezioni attive, anche queste azioni difensive devono essere registrate.

È la decisione di progettazione dell'applicazione Web determinare se sono consentiti più accessi simultanei dallo stesso utente dallo stesso o da indirizzi IP client diversi. Se l'applicazione Web non desidera consentire l'accesso simultaneo alla sessione, deve intraprendere azioni efficaci dopo ogni nuovo evento di autenticazione, terminando implicitamente la sessione precedentemente disponibile o chiedendo all'utente (tramite la vecchia, la nuova o entrambe le sessioni) la sessione che deve rimanere attivi.

Si consiglia alle applicazioni Web di aggiungere funzionalità utente che consentono di controllare i dettagli delle sessioni attive in qualsiasi momento, monitorare e avvisare l'utente degli accessi simultanei, fornire funzionalità utente per terminare manualmente le sessioni in remoto e tenere traccia della cronologia delle attività dell'account (registro) mediante registrazione più dettagli del client come indirizzo IP, agente utente, data e ora di accesso, tempo di inattività, ecc.

Ci sono situazioni in cui il codice sorgente dell'applicazione web non è disponibile o non può essere modificato, o quando le modifiche richieste per implementare le molteplici raccomandazioni sulla sicurezza e le migliori pratiche descritte sopra implicano una riprogettazione completa dell'architettura dell'applicazione web e, pertanto, non possono essere facilmente implementate a breve termine^[8][4].

In questi scenari, o per completare le difese dell'applicazione web, e con l'obiettivo di mantenere l'applicazione web il più sicura possibile, si consiglia di utilizzare protezioni esterne come Web Application Firewall (WAF) in grado di mitigare le minacce di gestione delle sessioni già descritte.

I Web Application Firewall offrono funzionalità di rilevamento e protezione dagli attacchi basati sulla sessione. Da un lato, è banale per i WAF imporre l'utilizzo di attributi di sicurezza sui cookie, come i flag Securee HttpOnly, applicando regole di riscrittura di base sull'intestazione Set-Cookieper tutte le risposte dell'applicazione web che impostano un nuovo cookie.

D'altra parte, è possibile implementare funzionalità più avanzate per consentire al WAF di tenere traccia delle sessioni e degli ID di sessione corrispondenti e di applicare tutti i tipi di protezione contro la correzione della sessione (rinnovando l'ID di sessione sul lato client quando i privilegi cambiano vengono rilevati), imponendo sessioni permanenti (verificando la relazione tra l'ID di sessione e altre proprietà del client, come l'indirizzo IP o User-Agent), o gestendo la scadenza della sessione (costringendo sia il client che l'applicazione web a finalizzare la sessione).

Il ModSecurity WAF open source, oltre al set di regole OWASP Core, fornisce funzionalità per rilevare e applicare gli attributi dei cookie di sicurezza, contromisure contro gli attacchi di fissazione della sessione e funzionalità di tracciamento della sessione per applicare sessioni permanenti.

session_start( 	'mySessionName',  	-expires = 1440, 	-usecookie=true ) if(session_result('mySessionName') != 'load') => { 	session_addVar('mySessionName', 'sv_userId') 	session_addVar('mySessionName', 'sv_userName') 	session_addVar('mySessionName', 'sv_userEmail') 	session_addVar('mySessionName', 'sv_favouriteColour') }  !var_defined('sv_userId') ? 	var('sv_userId' = integer) !var_defined('sv_userName') ? 	var('sv_userName' = string) !var_defined('sv_userEmail') ? 	var('sv_userEmail' = string) !var_defined('sv_favouriteColour') ? 	var('sv_favouriteColour' = 'red') 

• Cookie
• Informatica
• Login
• Logout
• Utente

• (EN) Denis Howe, session, in Free On-line Dictionary of Computing. Disponibile con licenza GFDL

Portale Informatica

Portale Telecomunicazioni