Qual è il modo migliore per prevenire il dirottamento della sessione?

In particolare ciò riguarda l'utilizzo di un cookie di sessione client per identificare una sessione sul server.

È la risposta migliore per utilizzare la crittografia SSL / HTTPS per l'intero sito Web e hai la migliore garanzia che nessun uomo in mezzo agli attacchi sarà in grado di annusare un cookie di sessione client esistente?

E forse il secondo migliore per usare una sorta di crittografia sul valore della sessione stessa che è memorizzato nel tuo cookie di sessione?

Se un utente malintenzionato ha accesso fisico a una macchina, può comunque guardare al filesystem per recuperare un cookie di sessione valido e utilizzarlo per dirottare una sessione?

La crittografia del valore della sessione non avrà alcun effetto. Il cookie di sessione è già un valore arbitrario, la crittografia genererà solo un altro valore arbitrario che può essere annusato.

L'unica vera soluzione è HTTPS. Se non vuoi fare SSL su tutto il tuo sito (forse hai problemi di prestazioni), potresti essere in grado di cavartela solo con SSL che protegge le aree sensibili. Per fare ciò, assicurati innanzitutto che la tua pagina di accesso sia HTTPS. Quando un utente accede, imposta un cookie sicuro (il che significa che il browser lo trasmetterà solo su un collegamento SSL) oltre al normale cookie di sessione. Quindi, quando un utente visita una delle tue aree "sensibili", reindirizzalo a HTTPS e verifica la presenza di quel cookie sicuro. Un vero utente lo avrà, un dirottatore della sessione no.

EDIT : questa risposta è stata originariamente scritta nel 2008. Adesso è il 2016 e non c'è motivo di non avere SSL nell'intero sito. Niente più HTTP in chiaro!

SSL aiuta solo con gli attacchi di sniffing. Se un utente malintenzionato ha accesso al tuo computer, suppongo che possano copiare anche il tuo cookie sicuro.

Per lo meno, assicurati che i vecchi cookie perdano il loro valore dopo un po '. Anche un attacco di dirottamento riuscito verrà contrastato quando il cookie smetterà di funzionare. Se l'utente dispone di un cookie di una sessione che ha effettuato l'accesso più di un mese fa, è necessario immettere nuovamente la password. Assicurati che ogni volta che un utente fa clic sul link "disconnetti" del tuo sito, l'UUID della vecchia sessione non possa più essere utilizzato.

Non sono sicuro se questa idea funzionerà, ma qui va: Aggiungi un numero seriale nel cookie della sessione, forse una stringa come questa:

SessionUUID, Numero di serie, Data / ora correnti

Crittografa questa stringa e usala come cookie di sessione. Modifica periodicamente il numero seriale, magari quando il cookie ha 5 minuti e quindi reinvia il cookie. Puoi anche riemetterlo su ogni visualizzazione di pagina se lo desideri. Sul lato server, tenere un registro dell'ultimo numero seriale emesso per quella sessione. Se qualcuno invia un cookie con un numero di serie errato, significa che un utente malintenzionato potrebbe utilizzare un cookie che ha intercettato in precedenza, invalidando l'UUID di sessione e chiedendo all'utente di reinserire la password e quindi riemettere un nuovo cookie.

Ricorda che il tuo utente potrebbe avere più di un computer, quindi potrebbe avere più di una sessione attiva. Non fare qualcosa che li costringe ad accedere nuovamente ogni volta che passano da un computer all'altro.

Hai mai pensato di leggere un libro sulla sicurezza di PHP? Altamente raccomandato.

Ho avuto molto successo con il seguente metodo per i siti non certificati SSL.

1. Disabilita più sessioni con lo stesso account, assicurandoti di non verificarlo solo tramite l'indirizzo IP. Piuttosto controlla tramite token generato al momento dell'accesso che viene archiviato con la sessione degli utenti nel database, nonché l'indirizzo IP, HTTP_USER_AGENT e così via

2. Utilizzo di collegamenti ipertestuali basati su relazioni Genera un collegamento (ad es. Http://example.com/secure.php?token=2349df98sdf98a9asdf8fas98df8 ) Il collegamento viene aggiunto con una stringa MD5 salata casuale x-BYTE (dimensione preferita), al reindirizzamento della pagina generato casualmente il token corrisponde a una pagina richiesta.

   • Alla ricarica, vengono eseguiti diversi controlli.
   • Indirizzo IP di origine
   • HTTP_USER_AGENT
   • Token di sessione
   • ottieni il punto.

3. Cookie di autenticazione di sessione a breve durata. come pubblicato sopra, una buona idea è un cookie contenente una stringa sicura, che è uno dei riferimenti diretti alla validità delle sessioni. Far scadere ogni x minuti, riemettere quel token e risincronizzare la sessione con i nuovi dati. In caso di errata corrispondenza dei dati, disconnettere l'utente o far autenticare nuovamente la sessione.

Non sono affatto un esperto in materia, ho avuto un po 'di esperienza in questo particolare argomento, spero che un po' di questo aiuti qualcuno là fuori.

// Collect this information on every request
$aip = $_SERVER['REMOTE_ADDR'];
$bip = $_SERVER['HTTP_X_FORWARDED_FOR'];
$agent = $_SERVER['HTTP_USER_AGENT'];
session_start();

// Do this each time the user successfully logs in.
$_SESSION['ident'] = hash("sha256", $aip . $bip . $agent);

// Do this every time the client makes a request to the server, after authenticating
$ident = hash("sha256", $aip . $bip . $agent);
if ($ident != $_SESSION['ident'])
{
    end_session();
    header("Location: login.php");
    // add some fancy pants GET/POST var headers for login.php, that lets you
    // know in the login page to notify the user of why they're being challenged
    // for login again, etc.
}

Ciò che fa è catturare informazioni "contestuali" sulla sessione dell'utente, informazioni che non dovrebbero cambiare durante la vita di una singola sessione. Un utente non sarà al computer negli Stati Uniti e in Cina allo stesso tempo, giusto? Quindi, se l'indirizzo IP cambia improvvisamente all'interno della stessa sessione, il che implica fortemente un tentativo di dirottamento della sessione, quindi si protegge la sessione chiudendo la sessione e costringendo l'utente a riautenticare. Questo ostacola il tentativo di hacking, ma anche l'attaccante è costretto a effettuare il login invece di accedere alla sessione. Avvisare l'utente del tentativo (ajax un po '), e vola, leggermente infastidito + utente informato e la loro sessione / informazione è protetta.

Aggiungiamo User Agent e X-FORWARDED-FOR per fare del nostro meglio per catturare l'unicità di una sessione per i sistemi dietro proxy / reti. Potresti essere in grado di utilizzare più informazioni allora, sentiti libero di essere creativo.

Non è al 100%, ma è dannatamente efficace.

C'è altro che puoi fare per proteggere le sessioni, farle scadere, quando un utente lascia un sito Web e torna, forse costringe ad accedere nuovamente. Puoi rilevare un utente che esce e ritorna catturando un HTTP_REFERER vuoto (il dominio è stato digitato nella barra dell'URL) o verificare se il valore in HTTP_REFERER è uguale al tuo dominio o meno (l'utente ha fatto clic su un collegamento esterno / predisposto per raggiungere il tuo posto).

Scade le sessioni, non lasciare che rimangano valide a tempo indeterminato.

Non fare affidamento sui cookie, possono essere rubati, è uno dei vettori di attacco per il dirottamento della sessione.

Prova il protocollo Secure Cookie descritto in questo documento da Liu, Kovacs, Huang e Gouda:

Come indicato nel documento:

Un protocollo cookie sicuro che corre tra un client e un server deve fornire i seguenti quattro servizi: autenticazione, riservatezza, integrità e anti-replay.

Per quanto riguarda la facilità di implementazione:

In termini di efficienza, il nostro protocollo non prevede alcuna ricerca nel database o crittografia a chiave pubblica. In termini di implementabilità, il nostro protocollo può essere facilmente implementato su un server Web esistente e non richiede alcuna modifica alla specifica dei cookie di Internet.

In breve: è sicuro, leggero, funziona perfettamente per me.

Non esiste alcun modo per impedire il dirottamento della sessione al 100%, ma con un certo approccio possiamo ridurre il tempo impiegato da un utente malintenzionato a dirottare la sessione.

Metodo per prevenire il dirottamento della sessione:

1 - usa sempre la sessione con certificato ssl;

2 - invia cookie di sessione solo con httponly impostato su true (impedisce a javascript di accedere ai cookie di sessione)

2 - usa ID rigenerazione sessione all'accesso e alla disconnessione (nota: non utilizzare rigenerazione sessione ad ogni richiesta perché se hai una richiesta Ajax consecutiva hai la possibilità di creare più sessioni.)

3 - imposta un timeout di sessione

4 - memorizza l'agente utente del browser in una variabile $ _SESSION e confronta con $ _SERVER ['HTTP_USER_AGENT'] ad ogni richiesta

5 - imposta un cookie token e imposta il tempo di scadenza di quel cookie su 0 (fino alla chiusura del browser). Rigenera il valore del cookie per ogni richiesta (per la richiesta Ajax non rigenerare il cookie token). EX:

    //set a token cookie if one not exist
    if(!isset($_COOKIE['user_token'])){
                    //generate a random string for cookie value
        $cookie_token = bin2hex(mcrypt_create_iv('16' , MCRYPT_DEV_URANDOM));

        //set a session variable with that random string
        $_SESSION['user_token'] = $cookie_token;
        //set cookie with rand value
        setcookie('user_token', $cookie_token , 0 , '/' , 'donategame.com' , true , true);
    }

    //set a sesison variable with request of www.example.com
    if(!isset($_SESSION['request'])){
        $_SESSION['request'] = -1;
    }
    //increment $_SESSION['request'] with 1 for each request at www.example.com
    $_SESSION['request']++;

    //verify if $_SESSION['user_token'] it's equal with $_COOKIE['user_token'] only for $_SESSION['request'] > 0
    if($_SESSION['request'] > 0){

        // if it's equal then regenerete value of token cookie if not then destroy_session
        if($_SESSION['user_token'] === $_COOKIE['user_token']){
            $cookie_token = bin2hex(mcrypt_create_iv('16' , MCRYPT_DEV_URANDOM));

            $_SESSION['user_token'] = $cookie_token;

            setcookie('user_token', $cookie_token , 0 , '/' , 'donategame.com' , true , true);
        }else{
            //code for session_destroy
        }

    }

            //prevent session hijaking with browser user agent
    if(!isset($_SESSION['user_agent'])){
        $_SESSION['user_agent'] = $_SERVER['HTTP_USER_AGENT'];
    }

    if($_SESSION['user_agent'] != $_SERVER['HTTP_USER_AGENT']){
      die('session hijaking - user agent');
    }

nota: non rigenerare il cookie token con la richiesta ajax nota: il codice sopra è un esempio. nota: se gli utenti si disconnettono, il token cookie deve essere distrutto e la sessione

6 - non è un buon approccio usare l'ip utente per prevenire il dirottamento della sessione perché l'ip di alcuni utenti cambia con ogni richiesta. CHE INTERESSANO GLI UTENTI VALIDI

7 - personalmente memorizzo i dati della sessione nel database, dipende da te quale metodo adotti

Se trovi errori nel mio approccio, per favore correggimi. Se hai altri modi per prevenire l'hyjaking della sessione, per favore dimmelo.

Assicurarsi di non utilizzare numeri interi incremting per gli ID di sessione. Molto meglio usare un GUID o qualche altra stringa di caratteri generata in modo casuale lungo.

Esistono molti modi per creare protezione contro il dirottamento della sessione, tuttavia tutti riducono la soddisfazione degli utenti o non sono sicuri.

• Controlli IP e / o X-FORWARDED-FOR. Funzionano e sono abbastanza sicuri ... ma immagina il dolore degli utenti. Arrivano in un ufficio con WiFi, ottengono un nuovo indirizzo IP e perdono la sessione. Devi accedere di nuovo.

• Controlli dell'agente utente. Come sopra, la nuova versione del browser è fuori uso e si perde una sessione. Inoltre, questi sono davvero facili da "hackerare". È banale per gli hacker inviare stringhe UA false.

• token localStorage. All'accesso generare un token, archiviarlo nella memoria del browser e archiviarlo in cookie crittografato (crittografato sul lato server). Ciò non ha effetti collaterali per l'utente (localStorage persiste attraverso gli aggiornamenti del browser). Non è così sicuro - come è solo la sicurezza attraverso l'oscurità. Inoltre, potresti aggiungere un po 'di logica (crittografia / decrittografia) a JS per oscurarla ulteriormente.

• Ristampa dei cookie. Questo è probabilmente il modo giusto per farlo. Il trucco è consentire a un solo client di utilizzare un cookie alla volta. Pertanto, l'utente attivo riceverà nuovamente i cookie ogni ora o meno. Il vecchio cookie viene invalidato se viene emesso uno nuovo. Gli hack sono ancora possibili, ma molto più difficili da fare: sia un hacker che un utente valido riceveranno l'accesso rifiutato.

Consideriamo che durante la fase di accesso client e server possono concordare un valore salt segreto. Successivamente il server fornisce un valore di conteggio ad ogni aggiornamento e si aspetta che il client risponda con l'hash del (salt + segreto). Il potenziale dirottatore non ha alcun modo per ottenere questo valore salato segreto e quindi non può generare l'hash successivo.

AFAIK l'oggetto sessione non è accessibile sul client, poiché è memorizzato sul server web. Tuttavia, l'id di sessione viene memorizzato come cookie e consente al server Web di tenere traccia della sessione dell'utente.

Per impedire il dirottamento della sessione utilizzando l'id di sessione, è possibile memorizzare una stringa con hash all'interno dell'oggetto sessione, creata utilizzando una combinazione di due attributi, addr remoto e porta remota, a cui è possibile accedere sul server Web all'interno dell'oggetto richiesta. Questi attributi associano la sessione utente al browser in cui l'utente ha effettuato l'accesso.

Se l'utente accede da un altro browser o da una modalità di navigazione in incognito sullo stesso sistema, l'indirizzo IP rimarrà lo stesso, ma la porta sarà diversa. Pertanto, quando si accede all'applicazione, all'utente verrà assegnato un ID sessione diverso dal server Web.

Di seguito è riportato il codice che ho implementato e testato copiando l'id di sessione da una sessione a un'altra. Funziona abbastanza bene. Se c'è una scappatoia, fammi sapere come l'hai simulata.

@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    HttpSession session = request.getSession();
    String sessionKey = (String) session.getAttribute("sessionkey");
    String remoteAddr = request.getRemoteAddr();
    int remotePort = request.getRemotePort();
    String sha256Hex = DigestUtils.sha256Hex(remoteAddr + remotePort);
    if (sessionKey == null || sessionKey.isEmpty()) {
        session.setAttribute("sessionkey", sha256Hex);
        // save mapping to memory to track which user attempted
        Application.userSessionMap.put(sha256Hex, remoteAddr + remotePort);
    } else if (!sha256Hex.equals(sessionKey)) {
        session.invalidate();
        response.getWriter().append(Application.userSessionMap.get(sessionKey));
        response.getWriter().append(" attempted to hijack session id ").append(request.getRequestedSessionId()); 
        response.getWriter().append("of user ").append(Application.userSessionMap.get(sha256Hex));
        return;
    }
    response.getWriter().append("Valid Session\n");
}

Ho usato l'algoritmo SHA-2 per eseguire l'hashing del valore usando l'esempio fornito da Hashing SHA-256 su baeldung

In attesa di vostri commenti.

Per ridurre il rischio è anche possibile associare l'IP di origine alla sessione. In questo modo un utente malintenzionato deve trovarsi all'interno della stessa rete privata per poter utilizzare la sessione.

Anche il controllo delle intestazioni dei referer può essere un'opzione, ma possono essere falsificati più facilmente.

Proteggi da:

$ip=$_SERVER['REMOTE_ADDER'];
$_SESSEION['ip']=$ip;