Quando disconnettersi da un sito Web è necessario qualcos'altro, quindi distruggere la sessione?

2

In PHP, non sono sicuro di dover avviare la sessione prima di distruggerla quando un utente vuole disconnettersi.

session_start();
session_destroy();

C'è qualcos'altro che deve essere fatto?

EDIT: ho ripostato su Stackoverflow qui ma non riesco ancora a capire appieno.

Fondamentalmente sto chiedendo, dimmi, cosa deve essere fatto al logout? So che da quando creo una sessione utilizzando session_start() all'accesso, devo chiamare session_destroy() . Alcune pagine SO dicono di chiamare session_regenerate_id(true) e session_unset() e non capisco perché.

    
posta Celeritas 07.03.2013 - 00:11
fonte

4 risposte

2

No, non dovresti farlo e non solo per ottenere guadagni minimi. Mi rendo conto di cosa ti ha fatto pensare che sarebbe stata una buona pratica, ma analizziamo un po 'di più queste due citazioni dal manuale PHP:

session_start() creates a session or resumes the current one based on a session identifier passed via a GET or POST request, or passed via a cookie.

session_destroy() destroys all of the data associated with the current session. It does not unset any of the global variables associated with the session, or unset the session cookie. To use the session variables again, session_start() has to be called.

OK, è chiaro. Nel tuo post su SO hai anche la possibilità che l'utente possa navigare direttamente a questo URI da cui verrà eseguito questo codice. In realtà non dovresti farlo e dovresti almeno controllare i dati di accesso dell'utente e la stringa del referrer prima di iniziare la sessione ed eliminare la sessione ogni volta che lo stato dell'utente cambia. Ma diciamo che non hai cambiato il tuo codice e possiamo navigare verso l'URI in questione. Ora immagina questo scenario:

  • Ho accesso a uno dei computer dell'utente legittimo, alla sua rete, posso accedere alla tua applicazione web tramite lo stesso IP e posso raccogliere i dati della sessione sul lato client
  • Faccio una richiesta POST o GET senza dati di sessione all'URI che esegue questo codice
  • Aggiungo manualmente questi frammenti di sessione (cookie di sessione, stringa utente-agente) a cui ho accesso nel mio browser modificato

Voila!

Tutto questo è davvero facile da fare e molte persone con accesso diretto al computer degli utenti designati avrebbero i mezzi e le ragioni per fare una cosa del genere, se solo ne avessero la conoscenza. E stai abbassando leggermente quella barra.

Vediamo cosa accadrà.

session_start() verrà chiamato prima che la sessione sia stata invalidata sul tuo server web (cosa che accade su session_destroy() ), creando effettivamente una nuova sessione utente. Posso quindi sostituire i miei nuovi dati di sessione con quelli vecchi (rubati) e la tua applicazione web avrà (in base ai miei dati di sessione utente-end) nessuna ragione per sospettare che io non sia l'utente per cui la sessione è stata creata per la prima volta posto. Riprenderà come se fossi l'utente precedente che ho rubato i dati della sessione da.

Quindi, in che modo ciò differisce dal sequestro di sessione quando si utilizzano le routine di gestione delle sessioni nell'ordine previsto?

In una lunga discussione con @Xander che ha analizzato le routine di gestione delle sessioni di PHP, siamo giunti alla conclusione che non cambia molto nulla in questo senso. Tuttavia, non guadagni nulla facendo così, e potresti portare a una rottura delle funzionalità di qualsiasi framework di sessione utente di terze parti, se la tua applicazione PHP dipende da. Citando la tua domanda SO correlata "Sono preoccupato che se un l'utente naviga direttamente a questa pagina potrebbe esserci un errore durante la distruzione della sessione " espone un'altra preoccupazione, che stai essenzialmente permettendo allo sfruttatore di dare un'occhiata alla struttura dei dati della sessione utente gratuitamente, senza alcuna autenticazione dell'utente prima di creare esso. Dicendo "Ma lo sto eliminando immediatamente!" non si applica realmente in questo senso, poichè session_destroy() "... non annulla alcuna delle variabili globali associate alla sessione , o disinserire il cookie di sessione. " Dicendolo in modo diverso:

Hai appena semplificato il dirottamento della sessione, non il contrario!

TL; DR - Quindi, in breve, dovrai farlo "il noioso modo standard" in quanto nell'ordine in cui queste due routine di cambio sessione sono state progettato per essere eseguito.

    
risposta data 07.03.2013 - 21:34
fonte
1

Dipende totalmente da ciò che effettivamente fa la tua specifica applicazione, ma una linea guida generale aggiuntiva che suggerirei sarebbe quella di distruggere tutti i cookie che hai creato.

    
risposta data 07.03.2013 - 00:20
fonte
1

Se segui OWASP c'è molto su come proteggere le connessioni e mantenere una sessione sicura state. Ti darebbero una bella spiegazione su come avviare in modo sicuro una nuova connessione. Alcuni sono

  1. Non consentire al processo di accesso di iniziare da una pagina non criptata. Avvia sempre la procedura di accesso da una seconda pagina crittografata con a nuovo o nuovo token di sessione per impedire credenziali o sessioni furto, attacchi di phishing e attacchi di fissazione della sessione.

  2. Considera la possibilità di rigenerare una nuova sessione in seguito all'autenticazione corretta     o modifica del livello dei privilegi.

  3. Limita o riduci il codice dei cookie personalizzati ai fini dell'autenticazione o della gestione delle sessioni, come la funzionalità di tipo "ricordami" o funzionalità single-sign-home. Questo non si applica alle solide e ben collaudate soluzioni SSO o di autenticazione federata.

Ecco il test per il riutilizzo / la risoluzione dei cookie

    
risposta data 07.03.2013 - 19:18
fonte
1

Acadion Security ha pubblicato un white paper su come implementare in modo sicuro le sessioni utente in un'applicazione web. Non solo la sessione dovrebbe essere distrutta al logout, ma la sessione dovrebbe essere distrutta su:

  1. Timeout
  2. Esci
  3. Trasferimento non crittografato
  4. Origine errata
  5. Accesso doppio
  6. Reimpostazione della password
  7. Modifica agente utente
  8. Rigenerazione sessioni occasionali

I dettagli sono disponibili nel documento qui .

    
risposta data 08.03.2013 - 08:55
fonte