2013-10-03 15 views
6

Stavo cercando di creare la mia classe PHP Sessions protetta, quando mi stavo chiedendo in realtà cosa impedisce a qualcuno di emulare la sessione?PHP Session Hijacking e relativi metodi

IE, perché non sarebbe un codice sul test.php

$_SESSION['logged_in'] = true; 

non essere in grado di lavorare su index.php dove

if($_SESSION['logged_in'] == True){ 
echo 'logged in'; 
} 

Capisco che il modo in cui questo è quello di garantire la sessione generando un ID sicuro bloccandolo sull'indirizzo IP e sull'agente utente, ma come funziona esattamente?

Se si è in grado di indovinare l'ID sessione, sarei in grado di impostare $ _SESSION ['logged_in'] = true ed emulare il login? Dovrei quindi modificare la variabile SESSION per verificare l'accesso a uno più sicuro?

Scusate le mie domande e spero di dare un senso ...

+0

Avete 'session_start();' su ogni pagina? –

+1

Dovresti prendere le lezioni di WebGoat da OWASP, ti aiutano a capire meglio le cose, che è un requisito per creare cose sicure.https: //www.owasp.org/index.php/Category: OWASP_WebGoat_Project – pduersteler

+1

Altre lezioni [qui - Damn Vulnerable Web App] (http://www.dvwa.co.uk/) –

risposta

7

Prima di tutto, i dati di sessione vengono memorizzati solo sul server, quindi un client esterno non può semplicemente creare i propri dati di sessione e inviarlo al server.

Si tratta quindi di indovinare effettivamente l'identificativo di sessione di qualcun altro e assumere la propria identità; questo è abbastanza difficile, ma non impossibile. In una situazione in cui un utente malintenzionato può sfruttare il traffico di rete tra la vittima e il server, è assolutamente impossibile fermarli.

Ci sono alcune cose che si possono adottare per rendere le cose più sicuro, però:

  1. Usa SSL; vedi anche session.cookie_secure.
  2. Genera identificatori da una buona fonte casuale, ad esempio /dev/urandom su macchine Linux; vedi anche session.entropy_file.
  3. Rigenera l'identificatore quando un utente esegue l'accesso o l'uscita; vedere anche session_regenerate_id()
  4. Utilizzare i cookie HttpOnly (e solo i cookie) per perpetuare un identificatore di sessione; vedere anche session.use_only_cookies e session.cookie_httponly.
  5. Utilizzare sessioni rigorose; vedi anche session.use_strict_mode.
  6. Mantenere un hash calcolato dell'agente utente nella sessione e assicurarsi che non cambi, ad es.:

    $_SESSION['_agent'] = sha1($_SERVER['HTTP_USER_AGENT']); 
    
  7. cercare di ridurre la durata di una sessione più breve possibile e utilizzare un avanzato "remember me" feature per rigenerare le sessioni della loro scadenza.

E 'anche importante sapere quando un potenziale dirottamento ha avuto luogo e prendere i provvedimenti opportuni quando ciò accade. Dovrai tenere traccia di quali sessioni appartengono a quale utente in modo che tu possa invalidarle tutte quando una di esse è stata violata.

Btw, bloccare la sessione su un indirizzo IP è complicato; alcuni ISP faranno sembrare che un utente provenga da vari indirizzi o più utenti provengano dallo stesso indirizzo. In entrambi i casi, potrebbe essere meglio tenere traccia dello user agent, poiché è meno probabile che cambi.

+0

+1 Ora questa è una risposta. – samayo

+0

Ottima risposta! Grazie :) – user2587774

+0

@ user2587774 Prego; se ha aiutato a rispondere alla tua domanda, considera di accettarla come risposta :) –

3

Indovinare l'id di sessione non è dirottamento di sessione. È più difficile che indovinare una password. Ma sì, se qualcuno ha ottenuto un id di sessione, otterrebbe pieno accesso all'account in questione.

Il blocco tramite l'indirizzo ID significa semplicemente che si memorizza l'indirizzo IP originale che l'utente ha utilizzato quando ha effettuato l'accesso nella sessione stessa e lo controlla all'inizio di ogni richiesta per vedere se non è stato modificato. In questo modo, anche se un utente malintenzionato ottiene l'ID di sessione corretto, non sarà ancora in grado di utilizzarlo.

C'è una buona Wikipedia article on the topic, nonché domande relative a StackOverflow: 1, 2.

+0

Sapete che le variabili '$ _SERVER' possono essere falsificate. Quindi, non puoi fare affidamento su '$ _SERVER ['REMOTE_ADDR']' per l'autenticazione, e specialmente nell'era in cui [IP dinamico] (http://www.noip.com/blog/2012/05/24/what -is-a-dynamic-ip-address /) è ampiamente utilizzato. Significa che un utente può essere disconnesso perché il server cambia l'IP in modo dinamico. – samayo

+0

'$ _SERVER ['REMOTE_ADDR']' può essere facilmente modificato dal client, ma non può essere facilmente impostato su un valore arbitrario uguale a quello di un altro client. – Denis

+0

@Simon_eQ Quindi, come si potrebbe spoofare '$ _SERVER ['REMOTE_ADDR']'? – Gumbo