Fissazione della sessione in Java

5

Durante lo sviluppo di un'applicazione jsp / servlet vulnerabile, ho tentato di introdurre la vulnerabilità della fissazione della sessione.

In riferimento alla documentazione sono arrivato con il seguente codice che, se usato nel servlet per creare una nuova sessione, dovrebbe restituire la sessione HTTP esistente se esiste e altrimenti dovrebbe restituire null. In ogni caso non dovrebbe essere creata una nuova sessione.

if(obj.checkLogin(username, password))//if credentials are valid
    {
    HttpSession session = request.getSession(false);//return the existing session

    if(session != null)
            response.sendRedirect("LoginSuccess.jsp");
        else
            response.sendRedirect("error.jsp");
    }

Per testare il codice l'ho distribuito usando tomcat 7 e testato per la fissazione della sessione:

  1. Osserva il cookie ( c1 ) quando viene caricata la pagina di accesso (utilizzando un proxy di intercettazione)
  2. Inserisci le credenziali corrette nel modulo di accesso. L'autenticazione ha avuto successo e sono stato reindirizzato a LoginSuccess.jsp
  3. Osserva il cookie ( c2 ) dopo l'autenticazione.

Ho trovato che i cookie c1 e c2 sono diversi. Il che implica che il codice non sia vulnerabile alla fissazione della sessione. Sto avendo problemi a capire questo comportamento. Perché il cookie originale c1 non rimane dopo l'autenticazione?

    
posta Shurmajee 11.11.2014 - 12:58
fonte

1 risposta

-1

Il servlet engine che utilizzi in modo sicuro gestisce i cookie di sessione quando chiami request.getSession () e non è vulnerabile alla risoluzione.

(come discusso nei commenti) Questo comportamento è sia intenzionale che corretto. Sia che venga chiamato getSession (), getSession (true) o getSession (false), il server fa affidamento sulla propria memoria per determinare se esiste una sessione valida corrispondente al valore ricevuto dal client. Se non esiste una tale sessione nella memoria del server, il motore servlet ignora l'ID di sessione dal client. Ciò impedisce la fissazione della sessione, poiché il server non consente mai al client di definire il sessionid di una nuova sessione (nuovo dal punto di vista del server che non ha quel sessionid in memoria.)

È necessario trovare un motore servlet più vecchio e danneggiato che sia vulnerabile alla fissazione della sessione o che sia necessario sostituire il codice di gestione della sessione. Se segui quest'ultimo, dovrai determinare se è possibile sostituire la generazione della sessione o se scriverà il tuo codice di gestione della sessione.

L'approccio che prendi dovrebbe rispecchiare quello che stai cercando di insegnare. Se vuoi che le persone insegnino ...

  • mantieni le tue cose corrette, poi vai con il vecchio motore rotto
  • non scrivere il tuo meccanismo di gestione delle sessioni, scrivi il tuo
  • non modificare un meccanismo di gestione delle sessioni esistente, quindi modificare quello esistente
risposta data 11.11.2014 - 15:21
fonte

Leggi altre domande sui tag