Le variabili di sessione dovrebbero essere evitate?

Se hai una variabile di sessione nella tua applicazione, chiediti:

When I click the back button of my browser, what value do I want my variable to have?

Se la risposta è "il valore corrente", le variabili di sessione possono essere utili. Un esempio potrebbe essere un carrello della spesa: non ti aspetti che le cose vengano rimosse dal carrello della spesa mentre passi indietro nella cronologia. È sempre allo stato attuale.

Se la risposta è "un valore precedente", non dovresti usare le variabili di sessione. Usi errati che ho visto includono il passaggio di un parametro tra le pagine. Se faccio clic sul pulsante Indietro per tornare a una pagina, la pagina non ottiene necessariamente il parametro corretto. Inoltre, se apro due schede, come si comporterà il mio sito?

Il corretto funzionamento del pulsante back non è affatto il tutto-e-fine-tutto, ma ti aiuta a pensare a un sito web come a un'applicazione stateless. In generale, trovo che gli usi appropriati delle variabili di sessione siano pochi e distanti tra loro.

Il protocollo HTTP è senza stato. Le sessioni sono un modo per preservare lo stato del client attraverso le richieste HTTP. È possibile scegliere di farlo con la gestione della sessione integrata di una piattaforma o eseguirla da soli con i parametri della stringa di query. In ogni caso, alcuni concetti di sessione sono necessari per molte attività.

Probabilmente al tuo collega non piace un'implementazione specifica o non hai utilizzato le sessioni per gli scopi previsti. Se è necessario conservare le informazioni su una specifica connessione client attraverso richieste HTTP, è necessaria una qualche forma di persistenza della sessione.

I seguenti problemi sono specifici dell'implementazione:

Untyped nature of session variables

Global scope nature of session variables

Load balancing servers losing sessions

Application pools/servers restarting

Ad esempio, lavoro spesso in PHP e memorizzo le mie informazioni sulla sessione in un database relazionale. Quindi le mie variabili di sessione sono state digitate. Il bilanciamento del carico e il riavvio del server non causano problemi di sessione.

Questo è più interessante:

Session time-outs causing loss of state

Le sessioni vengono spesso conservate tramite i cookie. Questi possono essere cancellati dal cliente in qualsiasi momento. Ma possono anche essere preservati tramite un parametro stringa di query e quindi non scadono mai il tempo sul client. Il timeout del server dipende da te. Quindi anche questo problema è specifico per l'implementazione.

Non buttiamo fuori l'intero concetto di sessioni solo perché non ci piace una particolare implementazione. Qualsiasi buon framework per applicazioni web faciliterà l'uso corretto delle sessioni per preservare gli accessi degli utenti o conservare qualsiasi altra cosa specifica per la visita corrente dell'utente. Il record del database di un utente può (e dovrebbe) essere utilizzato per memorizzare elementi specifici quando si accede. I visitatori anonimi, tuttavia, possono avere informazioni temporanee che meritano di essere conservate nella loro sessione, come un breve elenco di pagine visitate o la preferenza a nascondi un avviso che hanno già visto. Generalmente solo le informazioni temporanee più piccole sono appropriate per l'archiviazione di sessione.

Gli altri hanno fatto molti buoni punti (che eviterò di ripetere), ma c'è un aspetto della tecnica del tuo amico che non è stato ancora discusso: sicurezza .

È impossibile sapere quale tipo di vulnerabilità si apre senza guardare il codice, ma ecco alcune cose che mi vengono in mente.

• Fissazione della sessione : un attacco potente che è leggermente più semplice se puoi semplicemente fare in modo che l'utente faccia clic su un link che ha già le informazioni necessarie nell'URL (piuttosto che provare a far usare all'utente un computer che ha i cookie sono impostati in modo appropriato).
• Iniezione SQL (o altro input dannoso) : non fidarti mai di nulla che proviene dall'utente. Le variabili di sessione hanno il vantaggio di non lasciare mai il server, quindi l'utente non può cambiarle direttamente. Mentre dovresti disinfettare i dati prima di metterli nella sessione, puoi sempre fidarti dei valori che ottieni dopo. Se tutto viene passato attraverso la stringa di query, hai un sacco di convalida che devi fare per assicurarti di non accettare input dannosi.
• Corruzione dei dati utilizzando input falsificati : simile all'iniezione SQL, quanti dati stai passando avanti e indietro? Quanto è cruciale? Posso modificare il comportamento della tua app modificando un valore nella stringa della query? Posso danneggiare i dati sul tuo server modificando i valori? Se riesco a danneggiare i dati sul server, interesserà altri utenti? (Se la tua risposta era "no", la mia risposta è "sei sicuro? hai un sacco di posti che devi controllare.").

Tutti questi possono ancora accadere quando usi Sessioni, ma possono ottenere un molto più facile se il tuo amico non sa cosa sta facendo.

Le variabili di sessione sono come le vecchie variabili globali di base in una certa misura. L'onere è sull'utente di tenerne traccia, cosa c'è in loro, il loro scopo e il modo in cui vengono utilizzati; proprio come nelle vecchie versioni di BASIC. Detto questo, perché qualcuno dovrebbe assolutamente scartare l'uso di un meccanismo che è ovviamente progettato per essere parte integrante e molto importaint del modello di programmazione (ASP, MVC ecc.)?

L'unica cosa negativa che ho incontrato nell'uso delle variabili Session è che ti mette l'onere di tenerne traccia, assicurandoti che siano popolati con dati relavent e di eliminarli.

Non è quello che facciamo quando programmiamo in qualche modo?

Ero abituato a pensare come il tuo collega a causa di alcune brutte esperienze che avevo avuto problemi di debug relativi alle variabili di sessione, che erano in realtà solo incompetenza da parte mia. Sì, è possibile ottenere in una certa misura senza variabili di sessione, utilizzando stringhe di query, campi nascosti nei moduli e altre cose. Tuttavia, diventa molto fastidioso farlo in questo modo se l'applicazione ha qualcosa che va oltre il flusso logico di base per determinare lo stato. C'è anche il rischio per la sicurezza di mostrare il funzionamento interno della tua applicazione tramite stringhe di query e campi nascosti, ognuno dei quali può servire come vettori di attacco.

Quando si lavora con le variabili di sessione, è sufficiente tenere traccia di quando vengono impostate e disattivate, in quanto ciò determinerà il flusso logico dell'applicazione. È come la gestione della memoria in un linguaggio come C.

Si noti che questo è dovuto alla mia esperienza con PHP su un progetto relativamente piccolo senza framework, le cose potrebbero essere diverse su altre piattaforme, ma penso che il principio generale sia ancora valido.

Come precedentemente affermato, HTTP è stateless e Session Variable interrompe quello. La progettazione HTTP per essere senza stato aiuta a memorizzare le risorse nella cache. Per le risorse che sono pubblicamente disponibili.

È possibile progettare un sito Web senza variabile di sessione ma è più difficile. Il più difficile (IMHO) è il login / logout di fantasia, gli schemi di autenticazione HTTP non forniscono gli strumenti necessari per l'autenticazione tramite un modulo HTML (potresti hackerare qualcosa con javascript - XHR a link ) ed è ancora più difficile eseguire il logout ed essere compatibile con più browser. c'è stata qualche discussione sulle liste di mailling su questo, ma se ricordo bene l'idea è stata abbandonata.

Per il resto, dovresti essere in grado di vivere senza variabili Session. Avrai qualche stato su un database, file o ovunque ma l'uso delle variabili Session dovrebbe essere raro.

Se il tuo utente ha un carrello della spesa, è una sessione variabile solo se si suppone che l'utente sia in grado di navigare su due computer / browser senza condividere il carrello.