2013-07-01 13 views
7

Sto codificando un sito Web in PHP contenente il valore booleano $_SESSION['logged_in']. È impostato su true quando una corrispondenza nome utente e password sono presenti nel database.Sessione spoofing (PHP)

Sono abbastanza nuovo per le sessioni e mi chiedevo solo se fosse possibile per un utente non registrato (o, per quella materia, registrato) ignorare il processo di login impostando questo valore booleano su true, come sarebbe possibile con un biscotto.

Capisco che l'utente debba manipolare una variabile lato server dal lato client, ma le mie domande sono la facilità con cui ciò avverrebbe, in che modo l'utente dovrebbe compiere tale compito, ci sono exploit noti? e quali sono le migliori pratiche/misure preventive per evitare questo tipo di attacco?

+2

Se un client può modificare i dati di sessione sul server senza che lo si consenta espressamente, si riscontrano problemi maggiori. Sarei più preoccupato per qualche schifoso hosting condiviso con qualche directory temporanea condivisa in cui sono archiviati i dati della sessione. O anche la fissazione della sessione. – PeeHaa

+0

@PeeHaa, concordato .. – verbumSapienti

+0

http://stackoverflow.com/questions/6912223/is-it-possible-to-change-a-session-variable-client-side –

risposta

14

Iniziamo con la buona notizia: l'array $_SESSION è di default completamente invisibile e inmanipibile dal client: esiste sul server e solo sul server, in un ambiente di esecuzione, che non è aperto al client.

Ora di nuovo a terra: è abbastanza semplice, per ottenere il codice PHP "quasi a destra" e quindi aprire una porta tra il client e la sessione come visto dal server. Oltre a questo, rubare una sessione client (incluso un cookie) è abbastanza facile.

vi consiglio un paio di mitigazioni, che si sono dimostrati molto efficaci:

  • Non conservare un "loggato" Valore - invece memorizzare un valore "cookie di sessione", e impostare il cookie al client. Su richiesta di un cliente, fare qualcosa sulla falsariga di $loggedin=($_SESSION['cookie']==$_COOKIE['session']). Ciò rende l'utente malintenzionato necessario: cookie e ID sessione.
  • Aggiorna il cookie di sessione abbastanza spesso, in un cookie sbagliato, la sessione viene interrotta. Se un black hat ruba cookie e sessione, il prossimo clic da parte dell'utente reale si disconnetterà entrambi e creerà un evento logabile.
  • Se le vostre richieste provengono da JS, pensate di creare una semplice funzione di autenticazione: invece di inviare il token di autenticazione, salatelo, passatelo con un timestamp, quindi cancellatelo. Invia sale, timestamp e hash. Fai in modo che il server controlli il timestamp.
+0

grazie per le informazioni e ottimi suggerimenti – verbumSapienti

+1

Ho amato la cosa del sale pepe –

1

Non è possibile per nessuno tranne il proprio codice manipolare i valori in una sessione. Perché qualcuno possa ignorarlo, dovrebbe avere il permesso di eseguire il codice sul server o sfruttare un buco di sicurezza nel codice o nel server (in entrambi i casi un exploit di sicurezza). Se un utente è in grado di farlo, probabilmente non ha bisogno di preoccuparsi di manipolare i valori di sessione, dal momento che può fare praticamente qualsiasi altra cosa sul server direttamente.

0

L'unico modo in cui posso vedere dove questo attacco sarebbe possibile è se c'è qualche altro exploit nel tuo codice, o se hanno accesso al tuo server (con altri mezzi). Ovviamente, se hanno accesso al tuo server, hanno accesso al tuo database, codice sorgente, probabilmente registri web, possibilmente tutto il traffico Internet grezzo incluso password ....

1

Il problema più comune riscontrato nel dominio delle sessioni è Session Hijacking. Ciò è dovuto al fatto che le sessioni sono associate a un parametro di sessione. Questo parametro deve essere fornito dall'utente ogni volta che invia una richiesta al server. Come puoi immaginare se qualcuno è in grado di indovinare o recuperare il parametro, dovrebbero poter "dirottare" la sessione.

Modifica: Per le misure di sicurezza contro di esso date un'occhiata al post di Eugen Reck.