Cwikius-Spring
/
spring-security
mirror of https://github.com/spring-projects/spring-security.git
1
0
Fork 0
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.

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
the login page after authenticating. </para></question>
<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
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.</para></answer>
<quote>secure</quote>, 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
<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>