Cwikius-Spring/spring-security
1
0
Fork 0
mirror of https://github.com/spring-projects/spring-security.git synced 2025-07-17 07:43:30 +00:00
Code Issues Packages Projects Releases Wiki Activity

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.

Browse Source
This commit is contained in:
Luke Taylor 2011-01-21 16:24:18 +00:00
parent 6b1b012e2c
commit b542c73907
1 changed files with 12 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
docs/faq/src/docbook/faq.xml
View File

@ -247,9 +247,18 @@
switching back to HTTP afterwards. It doesn't work - I just end up back at switching back to HTTP afterwards. It doesn't work - I just end up back at
the login page after authenticating. </para></question> the login page after authenticating. </para></question>
<answer><para> This happens because sessions created under HTTPS, for which the session cookie is marked as <answer><para> This happens because sessions created under HTTPS, for which the session cookie is marked as
<quote>secure</quote>, cannot subsequently be used under HTTP. The browser will not send the cookie <quote>secure</quote>, cannot subsequently be used under HTTP. The
back to the server and any session state will be lost (including the security context information). browser will not send the cookie back to the server and any session
Starting a session in HTTP first should work as the session cookie won't be marked as secure.</para></answer> 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
<link xlink:href="http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html#ns-session-fixation">
Session Fixation Protection</link> 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 <link xlink:href="http://www.thoughtcrime.org/software/sslstrip/">sslstrip</link>.
</para></answer>
</qandaentry> </qandaentry>
<qandaentry> <qandaentry>