Gestione della sessione: le funzionalità del server delle applicazioni sono sufficienti?

Question

Gestione della sessione: le funzionalità del server delle applicazioni sono sufficienti?

#1 da (4 voti)
#2 da (2 voti)

1

HTTP è un protocollo stateless. Tuttavia, quando l'utente accede a un'applicazione Web, gli piace che alcune informazioni sulla sessione vengano conservate, in modo che non debba effettuare nuovamente il login quando vuole andare avanti e indietro tra le pagine web della stessa applicazione.

Associato a ogni sessione è una durata della vita. Inoltre, alcune sessioni sono "transitorie", il che significa che vengono chiuse non appena l'utente chiude la pagina Web (anche se la sessione non è ancora scaduta).

Molti server applicazioni forniscono la nozione di sessione. Ad esempio, le documentazioni di WebLogic (che stiamo attualmente lavorando) discutono "Uso di sessioni e persistenza della sessione" (consultare il Capitolo 10 di Sviluppo di applicazioni Web, servlet e JSP per Oracle WebLogic Server 11g versione 1 ).

La domanda è:

Given the variety of possible attacks on sessions (session hijacking, session fixation, etc.), is it enough to rely on the session management features of the application server? In other words, can the application be "session agnostic," and everything be handled by proper configuration of the application server? (One can also assume that connections are over a properly implemented HTTPS connection.)

Credo che la risposta sia NO, ma ho bisogno di una giustificazione concreta su cosa possiamo e cosa non possiamo aspettarci dal server delle applicazioni.

Apprezzare le best practice e le possibili minacce / attacchi alla gestione delle sessioni è molto apprezzato.

Modifica (riguardante il commento di Andrew): Nella tua risposta, supponi che tutto il resto (firewall, file system, database, ecc.) sia configurato correttamente. Ora, il server delle applicazioni può essere configurato in modo tale che l'applicazione stessa non debba gestire le sessioni? Cioè, possiamo scrivere un'applicazione totalmente "agnostica di sessione" e inserirla in un ambiente che (tramite l'uso appropriato di server applicazioni, firewall, ecc.) Impedisce il dirottamento di sessione, la fissazione della sessione e altri attacchi relativi alla sessione? p>

web-application appsec session-management session-fixation

posta M.S. Dousti 25.07.2012 - 14:56

fonte

2 risposte

Leggi altre domande sui tag web-application appsec session-management session-fixation

Informazioni su password_hash () in PHP e memorizzazione (parte di) sale su DB perché i primi caratteri di una chiave privata DSA sono simili?

score 4 · Answer 1

No. Non è sufficiente utilizzare solo le funzionalità di gestione delle sessioni del framework dell'applicazione e non fare altro. È sicuramente una buona idea usare la gestione delle sessioni del framework dell'applicazione (fare non eseguire la propria gestione delle sessioni) - ma è necessario anche fare alcuni passi aggiuntivi.

L'esatta divisione delle responsabilità tra lo sviluppatore e il livello di gestione delle sessioni dipenderà dal particolare livello di gestione delle sessioni, ma qui ci sono alcuni problemi che sono tipicamente di competenza dello sviluppatore e non sono gestiti dal livello di gestione della sessione:

Devi implementare o abilitare la difesa CSRF (token CSRF). Normalmente il livello di gestione delle sessioni non lo farà per te.
Se vuoi utilizzare https, devi impostare l'attributo secure su tutti i cookie. Se stai utilizzando https sitewide, è tua responsabilità abilitare HSTS.
È necessario configurare il livello di gestione della sessione in modo che non accetti gli ID di sessione in un parametro GET. Questo è importante, per evitare le vulnerabilità della fissazione della sessione.
Probabilmente dovrai dire al sistema di generare un nuovo token CSRF subito dopo l'accesso, per difendersi dal login CSRF.
Se si desidera utilizzare l'attributo del cookie HTTPOnly, è responsabilità dell'utente impostarlo. È discutibile che questo attributo cookie fornisca un qualsiasi aumento misurabile della sicurezza nei confronti di un aggressore sofisticato, ma alcune persone lo raccomandano come una pratica di sicurezza "non dannosa".

Raccomando di leggere le risorse rese disponibili da OWASP. Ciò ti aiuterà a capire che cosa devi fare per proteggere la tua applicazione web.

score 2 · Answer 2

In generale, l'errore più fatale che puoi fare quando sviluppi un'applicazione sta tentando di "lanciare il tuo", quando tale funzionalità è già fornita dalla tua piattaforma (come provare a implementare nuovamente ssl). Le vulnerabilità sono inevitabili, facendo affidamento sulla tua piattaforma stai guadagnando la forza della community per controllare la tua sicurezza per GRATIS , il manutentore della tua piattaforma quindi correggerà il tuo sistema per GRATIS .

Detto questo, ci sono alcuni attacchi di cui essere a conoscenza. Forse per impostazione predefinita il gestore della sessione non è strong come potrebbe essere. Dovrai abilitare sia il cookie "sicuro" sia gli attributi HTTPOnly dei cookie . L'attributo "sicuro" del cookie obbliga il cookie a essere trasmesso su https, che è un buon modo di gestire il potenziale owasp a9 violazioni. Un'altra trappola di cui dovresti essere a conoscenza è che tutti gli ID di sessione dovrebbero essere trasmessi solo come cookie e non come variabile GET. La trasmissione dell'ID di sessione come variabile GET apre la porta per la correzione della sessione .

Devi anche essere a conoscenza di altri saggi CSRF conosciuti come "Session Riding", ma questo attacco è qualcosa devi difenderti contro e non è responsabilità del tuo gestore di sessioni.