2010-04-26 15 views
6

Conosco tutti i problemi relativi alla fissazione della sessione e al dirottamento. La mia domanda è davvero elementare: voglio creare un sistema di autenticazione con PHP. Per questo, dopo il login, vorrei solo memorizzare l'id utente nella sessione.Cosa memorizzare in una sessione?

Ma: ho visto alcune persone fare cose strane come generare un GUID per ogni utente e sessione e archiviarlo invece dell'id utente nella sessione. Perché?

Il contenuto di una sessione non può essere ottenuto da un cliente - o no?

risposta

2

La risposta breve è che $ _SESSION è sicuro e non è necessario preoccuparsi che il suo contenuto venga divulgato a un utente o un utente malintenzionato.

Il contenuto della sessione non è normalmente accessibile all'utente. Dovresti essere in grado di memorizzare la chiave primaria dell'utente e starai bene. Ci sono casi in cui la sessione può essere trapelata, su un normale sistema Linux la cartella di sessione è in/tmp, tuttavia questo potrebbe essere cambiato nel tuo php.ini nella web root (/ var/www/tmp) e quindi potrebbe essere accessibile . L'unico altro modo è se l'utente è in grado di accedere a $ _SESSION super global dirottando una chiamata a eval() o dalla variabile stampata normalmente.

Se si sta eseguendo su un host condiviso e si utilizza una versione precedente di PHP e/o il server non è configurato correttamente, potrebbe essere possibile per un altro utente su questo sistema leggere o persino modificare un file di sessione memorizzato in/tmp /. Non conosco una singola applicazione che tenga conto di questo attacco. Se questo è un problema, è possibile memorizzare le informazioni in una tabella session nel database.

4

Sei corretto. Il client vede solo un token ID di sessione generato a caso. Ci sono modi in cui questo token può essere utilizzato in modo improprio (dirottato, ecc.), Ma avere un GUID in cima non aggiunge nulla. Al contrario, opzioni come session.cookie_httponly (JavaScript non può vedere il cookie di sessione) session.cookie_secure (il cookie può essere trasmesso su HTTPS) proteggere da determinati scenari di attacco.

1

A volte, per maggiore sicurezza, gli sviluppatori possono assegnare una lunga stringa alla sessione dell'utente per rendere ancora più difficile il dirottamento. Impostando un cookie con questa nuova stringa al momento della creazione della sessione, l'app può verificare la stringa corretta nelle richieste successive per assicurarsi che sia effettivamente la persona che ha effettuato l'accesso.

E 'solo aggiungendo un'altra cosa un aspirante il dirottatore dovrebbe indovinare. Tuttavia, può essere un falso senso di sicurezza poiché fa poco per proteggere la sessione se è coinvolto lo sniffing perché il nuovo cookie viene inviato insieme al cookie di sessione php. Inoltre, gli ID di sessione sono molto difficili da indovinare così com'è (come sono sicuro lo sai, basta non inserirlo nell'url ma, piuttosto, nel cookie).

Le informazioni sulla sessione vengono memorizzate sull'unità disco rigido, quindi non sono ottenibili dai client senza l'intervento dell'applicazione.

+0

Non capisco come questo dovrebbe migliorare la sicurezza: se un hacker mette le mani sulle intestazioni HTTP di qualcun altro, copierà semplicemente l'intera intestazione del cookie - e così via. Come dovrebbe un hacker ottenere un ID di sessione senza sniffare? – eWolf

+0

Ecco perché ho detto "fa poco per proteggere la sessione se è coinvolto lo sniffing perché il nuovo cookie viene inviato insieme al cookie di sessione php". Ho modificato per aggiungere "il falso senso di sicurezza" per guidare il punto a casa. – webbiedave

+0

@eWolf Puoi ottenere un id di sessione senza sniffare in scenari stupidi in cui la sessione viene inviata tramite GET e non tramite POST: quando l'utente copia l'URL e lo incolla da qualche parte, ha dato via il suo id di sessione. Ad ogni modo, questo è irrilevante. –

1

Non ho mai visto i GUID utilizzati per le sessioni, ma ci sono un paio di metodi aggiuntivi che ho visto che aggiungono un po 'più di sicurezza.

  • Memorizzazione IP dell'utente - se avete bisogno di forzare un cambiamento sessione basata su posizioni (a volte cose GeoIP lo farà)
  • Memorizzazione stringa di intestazione HTTP_USER_AGENT dell'utente. Può fornire un po 'di sicurezza contro il dirottamento se il dirottatore sta usando un browser diverso.

C'è un grande articolo su session hijacking countermeasures su Wikipedia, in realtà.

Detto questo, immagino che chiunque memorizzi un GUID come parte di una sessione da utilizzare nella sicurezza della sessione potrebbe non riuscire a vedere una soluzione migliore (come la rigenerazione della sessione). Riesco a vedere altri usi per un GUID da memorizzare (forse fa parte di un generatore casuale per un gioco), ma non per l'uso con la sicurezza di sessione.

+3

Solo per aggiungere, ci sono persone con gli ISP sfortunati che cambiano il loro indirizzo IP spesso (a volte ogni due minuti!), Quindi avvolgere l'IP nella sessione può causare troppi mal di testa. – webbiedave

+1

@webbiedave - sì, non lo uso a meno che non ci sia una buona ragione. Ci sono molte ragioni per non usarlo a meno che tu non sia disposto ad accettare i problemi che ne derivano. – zombat

+0

HTTP_USER_AGENT fornisce una protezione zero contro qualsiasi attacco perché è una variabile controllata dall'utente. – rook

Problemi correlati