È possibile dirottare una sessione se l'utente viene reindirizzato da HTTPS a HTTP dopo l'accesso?

Question

È possibile dirottare una sessione se l'utente viene reindirizzato da HTTPS a HTTP dopo l'accesso?

#1 da (9 voti)
#2 da (4 voti)
#3 da (2 voti)
#4 da (-1 voti)

6

Sto sviluppando un'app Web, che effettua chiamate HTTP a condizione che l'utente non abbia effettuato l'accesso.
Una volta che l'utente fa clic sul pulsante login , viene inviato a una "pagina di accesso" che è HTTPS.

L'accesso effettua una chiamata Ajax a un servlet, in cui alcuni attributi specifici vengono aggiunti alla sessione.
Quindi, per risolvere il problema della "risoluzione della sessione" , la sessione corrente viene invalidata e viene creata una nuova sessione.

Dopo l'accesso, l'utente viene reindirizzato alla pagina dell'applicazione ma utilizzando HTTP.

Ora in ordine da non perdere gli attributi di sessione (tra HTTPS e HTTP) ho scavalcato il meccanismo predefinito Glassfish memorizzando nella cache il cookie JSESSIONID e inviandolo in risposta: ( questa è un'applicazione j2ee)

  Cookie cookie = new Cookie("JSESSIONID", request.getSession().getId());
  cookie.setMaxAge(-1);
  cookie.setSecure(false);
  cookie.setPath(request.getContextPath());
  response.addCookie(cookie);

Funziona bene, ma ho letto su Stack Overflow, Sicurezza IT e generalmente online che la sessione potrebbe ancora essere dirottata. Ad esempio questa risposta indica che è una pessima idea, e che un uomo nel mezzo possa dirottarlo.

Non sono un esperto di sicurezza, ma vorrei il tuo feedback sul seguente meccanismo che ho creato:

Quando digiti l'URL dell'app Web, la prima pagina di destinazione è HTTP. Tutti i meccanismi sono HTTP.
Quando l'utente decide di "accedere", viene reindirizzato a una pagina e quella pagina "di destinazione" è HTTPS (applicata tramite il j2ee CONFIDENTIAL )
Sul servlet, la risoluzione della sessione viene gestita invalidando la sessione e creando una nuova. Quindi vengono aggiunti gli attributi di sessione.
Per non perdere gli attributi di sessione mentre si torna a HTTP, un cookie viene sovrascritto manualmente con lo stesso "ID sessione" e impostato su "non sicuro".
Tutte le richieste di app sono nuovamente HTTP.

Questo è ancora un obiettivo facile per il dirottamento di sessione / MITM / o altri difetti di sicurezza?
Apprezzerei il feedback in quanto non ho molta esperienza con i dettagli di sicurezza.

cookies tls session-management

posta shadesco 27.04.2012 - 21:01

fonte

4 risposte

4

Sì. La sessione può essere dirottata. Il tuo approccio non è sicuro. L'unico modo per fornire una sicurezza ragionevole è utilizzare HTTPS per tutto.

Stai inviando l'ID di sessione su HTTP, il che significa che sta andando in chiaro, il che significa che può essere intercettato. Una volta intercettato, l'utente malintenzionato ha tutto il necessario per assumere il controllo dell'account dell'utente (incluse, eventualmente, le parti dell'applicazione che hai relegato a HTTPS).

Ti incoraggio a leggere su Firesheep, che sfrutta esattamente questo tipo di architettura. I siti devono utilizzare HTTPS per tutto, se vogliono essere protetti dagli attacchi di tipo eavesdropping e man-in-the-middle (ad es., Se vogliono essere sicuri per gli utenti che si connettono tramite Wifi aperto).

Vedi le seguenti domande su questo sito: Quali sono i pro e i contro dell'SSL del sito (https)? , Quando i cookie di sessione HTTP sono a rischio tramite Wi-Fi? e Quali siti sono ancora vulnerabili a FireSheep? .

Ecco cosa suggerisco per il tuo sito:

Utilizza SSL in tutto il sito: ad esempio, utilizza solo HTTPS, non HTTP. Non usare HTTP per nulla; utilizzare solo HTTPS. Abilita la sicurezza del trasporto rigoroso HTTP. Imposta il flag di sicurezza su tutti i cookie.
Pensa attentamente a come autenticerai gli utenti.

risposta data 28.04.2012 - 09:00

fonte

2

Uno dei più grandi vettori di attacco quando si tratta di HTTPS si basa sull'ingannare l'utente. È sempre responsabilità dell'utente verificare che HTTPS sia utilizzato quando lo si aspetta. Solo gli utenti possono verificare se non sono stati sottoposti a downgrade su HTTP semplice (e che i certificati sono validi).

Il "j2ee CONFIDENTIAL constraint security" è a malapena utile a tale riguardo. Sì, imporrà un reindirizzamento, ma questo reindirizzamento potrebbe essere gestito da un MITM attivo. Assicurati che i link delle sezioni HTTPS utilizzino https:// (ulteriori dettagli qui ).

Come ha detto @martinstoeckli, se puoi, usa HTTPS ovunque. In caso contrario, assicurati che laddove hai giudicato che l'HTTPS fosse più importante, gli utenti dovrebbero aspettarsi di utilizzare HTTPS (e si sposteranno se tali pagine utilizzano solo HTTP).

Esistono pochissime soluzioni tecniche per assicurarsi che l'utente effettui le verifiche corrette. Uno di questi è che gli utenti utilizzino un browser che supporta la Sicurezza del trasporto rigoroso HTTP , sebbene essi (a) debbano avere un tale browser e (b) aspettare HTTPS la prima volta (questo è meglio se c'è un precaricato elenco di siti abilitati per HSTS ).

risposta data 27.04.2012 - 22:53

fonte

-1

Questi sono un tipico tipo di domande in cui la risposta non ha importanza.

Se la risposta è Sì, può essere dirottata, sai che devi prendere contromisure.

Se la risposta è No ... tutto ciò che viene detto è: "Non sono a conoscenza di alcun vettore di attacco", ma non puoi mai essere sicuro al 100% e comunque devi prendere contromisure.

Quindi qualunque sia la risposta, prendere contromisure o non reindirizzare a http.

Non puoi mai essere sicuro che qualcosa sia 'fail-safe', puoi solo provare che qualcosa non funziona.

risposta data 27.04.2012 - 22:06

fonte

Leggi altre domande sui tag cookies tls session-management

Sovrascrivere il disco rigido per eliminare in modo sicuro un file? Il pinning DNS protegge da tutti gli attacchi di rebinding DNS?

score 9 · Accepted Answer

Ogni volta che richiedi una pagina con HTTP, tutto viene inviato in chiaro, il che significa che anche il cookie di sessione che contiene l'id viene inviato in chiaro (anche per le richieste di immagini). Ciò lo rende un obiettivo facile per gli attacchi MITM. Puoi configurare il cookie solo per l'invio alle pagine HTTPS, ma ovviamente perderai la sessione quindi su pagine HTTP.

Il modo migliore per affrontare questo problema è, per rendere l'intero sito HTTPS solo, è possibile evitare un sacco di problemi in questo modo. Finché il tuo sito non ha molto traffico, non dovrebbe esserci problemi per i server di oggi.

Se devi davvero passare da una pagina all'altra HTTP e HTTPS, puoi separare le due preoccupazioni relative al mantenimento della sessione e dell'autenticazione. È possibile aggiungere un secondo cookie solo per l'autenticazione e limitarlo solo alle pagine HTTPS. Il cookie di sessione può quindi essere utilizzato per entrambe le richieste HTTP e HTTPS. Ho scritto un esempio su come questo potrebbe essere implementato (è scritto in PHP, ma l'idea può essere implementata anche in altri ambienti).