2015-08-04 21 views
5

questo potrebbe essere un duplicato di questa domanda, ma la soluzione proposta non è praticabile per noi: Protect against 3rd party callers of document.execCommand("ClearAuthenticationCache")? Clears our session cookiesCome proteggere il mio JSESSIONID da document.execCommand ("ClearAuthenticationCache")?

farla breve: IE ha un modo per cancellare i cookie di sessione utilizzando JavaScript - document.execCommand(“ClearAuthenticationCache”). Viene utilizzato in una varietà di app Web, tra cui Outlook Web App (e presumibilmente molte altre). Il problema è che MS nella loro infinita saggezza ha deciso che questo comando dovrebbe cancellare i cookie di sessione per tutti i siti aperti (puoi dire che sono un po 'amaro, mi ci sono voluti mesi per trovare l'origine di JSESSIONIDs mancanti a caso).

Utilizziamo JSESSIONID e un altro token per verificare che l'utente sia autenticato. JSESSIONID è protetto e httpSolo. Funziona bene tranne quando il JSESSIONID viene cancellato da una terza parte. Quindi la mia domanda è in due parti:

  1. C'è un modo per proteggere i miei cookies di sessione da questo (supponiamo tutto ciò che coinvolge la configurazione lato client, come ad esempio pinning o hack del Registro di sistema, è un non-option)?

  2. In caso contrario, c'è un modo per recuperare in modo sicuro da questo? Poiché JSESSIONID è httpOnly, il browser non dovrebbe essere in grado di leggerlo, ma forse c'è qualcosa che non sto pensando.

Se rilevante: utilizziamo Tomcat 7 come nostro server web. L'app è un'app SaaS piuttosto complessa e la sicurezza è abbastanza importante.

Grazie a tutti.

risposta

1

credo che una delle seguenti opzioni avrebbe funzionato per proteggere le sessioni servlet da document.execCommand(“ClearAuthenticationCache”):

Si potrebbe set the max-age of your JSESSIONID nel vostro web.xml. In questo modo il tuo cookie JSESSIONID non sarebbe più un cookie di sessione! Ciò renderebbe la tua applicazione web leggermente meno sicura in quanto il cookie sopravviverebbe ancora dopo la chiusura del browser.

È possibile abbandonare del tutto i cookie HTTP e configure Tomcat to do session tracking with the SSL session ID. Non l'ho mai configurato personalmente, ma suppongo che questo sia più sicuro dell'uso dei cookie JSESSIONID. Tuttavia, la replica di sessione non è possibile in questa configurazione.

+1

Grazie mille. La prima opzione non è praticabile, ma la seconda potrebbe risolvere il nostro problema. Abbiamo un'appliance di sicurezza separata che gestisce SSL, ma può passare l'ID SSL in un'intestazione a Tomcat, a quel punto possiamo utilizzarlo come backup dell'identificazione JSESSIONID. – Pyro979