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.