From b542c73907efc756999e1ae3f257ae3cf1e643c7 Mon Sep 17 00:00:00 2001 From: Luke Taylor Date: Fri, 21 Jan 2011 16:24:18 +0000 Subject: [PATCH] SEC-1660: Updated FAQ to explain that session-fixation protection may cause problems if switching between HTTP and HTTPS, and also updated information to advise against switching in the first place. --- docs/faq/src/docbook/faq.xml | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/docs/faq/src/docbook/faq.xml b/docs/faq/src/docbook/faq.xml index 2756ccd641..13e9745671 100644 --- a/docs/faq/src/docbook/faq.xml +++ b/docs/faq/src/docbook/faq.xml @@ -247,9 +247,18 @@ switching back to HTTP afterwards. It doesn't work - I just end up back at the login page after authenticating. This happens because sessions created under HTTPS, for which the session cookie is marked as - secure, cannot subsequently be used under HTTP. The browser will not send the cookie - back to the server and any session state will be lost (including the security context information). - Starting a session in HTTP first should work as the session cookie won't be marked as secure. + secure, cannot subsequently be used under HTTP. The + browser will not send the cookie back to the server and any session + state will be lost (including the security context information). + Starting a session in HTTP first should work as the session cookie won't + be marked as secure (you will also have to disable Spring Security's + + Session Fixation Protection support to prevent it from creating a new secure session. + Note that this is not a good idea in general, as any application which uses HTTP at all is vulnerable to + man-in-the-middle attacks. To be truly secure, the user should begin accessing your site in HTTPS and continue + using it until they log out. Even clicking on an HTTPS link from a page accessed over HTTP is potentially risky. + If you need more convincing, check out a tool like sslstrip. +