2010-08-18 17 views
11

Consente solo di considerare la fiducia che il server ha con l'utente.Sessione di dirottamento e PHP

fissazione sessione: per evitare la fissazione uso "session_regenerate_id()" SOLO in autenticazione (login.php)

Sessione sidejacking: la crittografia SSL per l'intero sito.

Sono sicuro?

Grazie.

+0

Che tipo di sito è? –

+9

@MrXexxed un sito in cui gli sviluppatori non vogliono che venga violato. – rook

+0

@The Rook, stavo parlando con l'OP, era una domanda vera, il tuo commento è sia faceto che del tutto inutile. –

risposta

28

Leggi OWASP A3-Broken Authentication and Session Management. Leggi anche su OWASP A5-CSRF, che a volte viene chiamato "session riding".

È necessario utilizzare questo codice in un file di intestazione php:

ini_set('session.cookie_secure',1); 
ini_set('session.cookie_httponly',1); 
ini_set('session.use_only_cookies',1); 
session_start(); 

Questo codice impedisce session fixation. Aiuta anche a proteggere contro xss dall'accesso document.cookie che è un modo che può verificarsi Session Hijacking. Applicare i cookie HTTPS è un buon modo per indirizzare OWASP A9-Insufficient Transport Layer Protection. Questo modo di utilizzare HTTPS viene talvolta chiamato "cookie sicuri", che è un nome terribile per questo. Anche STS è una funzionalità di sicurezza molto interessante, ma non tutti i browser lo supportano (ancora).

+1

La tua risposta merita almeno un +10, e con il mio voto ce l'hai. Un paio di domande solo per essere sicuro di aver capito: 1) 'cookie_secure' mi avrebbe imposto di lavorare sempre su https quando sono in sessione, no ?! 2) Che cosa fa 'cookie_httponly'? Ho letto la spiegazione PHP, ma non ottengo quando dice che impedisce al modulo JS di leggere i cookie, in realtà i cookie dovrebbero essere letti da JS in molte circostanze. Grazie, e FYI: dal momento che PHP 5.3.0 'session.use_only_cookies' è 1 di default http://it.php.net/manual/en/session.configuration.php#ini.session.use-only-cookies –

2

Vorrei anche suggerire di memorizzare l'agente utente e le informazioni IP nella sessione e verificarlo su ogni richiesta. Non è a prova di proiettile, ma è un aumento abbastanza significativo della robustezza. Mentre forgiare UA è davvero facile, la forgiatura IP, mentre possibile, è MOLTO più difficile ... Ma potresti avere problemi con gli utenti che stanno dietro un sistema IP round robin come gli utenti AOL ...

+5

" ip forging "o più comunemente chiamato ip spoofing, è impossibile per una connessione TCP su Internet a causa dell'handshake a tre vie. Tuttavia, l'indirizzo IP di un utente legittimo può cambiare durante una sessione a causa del bilanciamento del carico su una rete aziendale o della modifica di hot spot wifi. – rook

+0

È abbastanza possibile. Richiede solo un attacco in stile MITM (in cui l'attaccante accede a uno dei router endpoint e quindi può fare ciò che desidera) ... – ircmaxell

+1

Non è "forging" se è possibile accedere ai pacchetti indirizzati a quell'IP. –

0

le migliori pratiche i hanno mai trovato è salvare i dati di sessione nel database o un file di testo. il database avrà un agente utente e un record IP e controllerà ogni richiesta per assicurarsi che la sessione non sia mai stata dirottata da altri.

per esempio come la sessione salvata nel database è possibile vedere l'implementazione nella libreria di sessione codeigntier. secondo me in questo modo risparmia abbastanza per evitare che qualcuno faccia una sessione di hijact.

+3

Controllare l'agente utente non ha senso perché si tratta di una variabile controllata da un utente malintenzionato. Memorizzare l'ID di sessione nel database significa che sql injection fornisce all'utente l'accesso immediato al sistema, quindi non avrà bisogno di rompere un hash della password per accedere. Il controllo dell'indirizzo IP è soggetto a errori perché questo può cambiare su un sistema legittimo, ad esempio se si trova dietro un sistema di bilanciamento del carico su una rete aziendale. – rook

+0

@Rook - Si presume che il database sia vulnerabile all'iniezione SQL. L'uso corretto di istruzioni preparate o stored procedure e un'adeguata sanificazione dei parametri non consentirà l'iniezione SQL. – AgmLauncher

+0

@AgmLauncher questo è l'equivalente di memorizzare una password in chiaro nel database. Uno deve pianificare il fallimento. – rook