Session Fixation Security Issue(2)Session Lost Problem

Session Fixation Security Issue(2)Session Lost Problem

1. First Problem.
When we click back space button, our browser will go from HTTPS to HTTP. And the sesssion created in HTTPS will not share with HTTP. So our session get lost here.
We can fix this problem, details are here http://sillycat.iteye.com/blog/1562131.

But from the official website of spring security, it suggest us not to do that, just let this problem there:
http://static.springsource.org/spring-security/site/faq.html#faq-tomcat-https-session

2. How can we face the 'repeat submit' problem

I go over the latest spring security 3.1.0 source codes, in this strategy, the related classes are here:
org.springframework.security.web.authentication.session.SessionFixationProtectionStrategy
org.springframework.security.web.session.SessionManagementFilter

I use these thread sleep codes in my action, the "repeat submit" problem will reproduce very easily.
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
log.error(e);
}

Log from my server:
06-26 09:59:16 [DEBUG] com.sillycat.easywebflow.filter.SessionFixationProtectionFilter.doFilter(SessionFixationProtectionFilter.java:71) - http-bio-443-exec-1 filter count = 1 sessionId_fromCookie=D79D7D2BFA59B418AFCE9988C7B940AF
06-26 09:59:16 [DEBUG] com.sillycat.easywebflow.filter.SessionFixationProtectionFilter.doFilter(SessionFixationProtectionFilter.java:112) - http-bio-443-exec-1 Invalidating session with Id D79D7D2BFA59B418AFCE9988C7B940AF start!
06-26 09:59:16 [DEBUG] com.sillycat.easywebflow.filter.SessionFixationProtectionFilter.doFilter(SessionFixationProtectionFilter.java:117) - http-bio-443-exec-1Invalidating session with Id D79D7D2BFA59B418AFCE9988C7B940AF end!
06-26 09:59:16 [DEBUG] com.sillycat.easywebflow.filter.SessionFixationProtectionFilter.doFilter(SessionFixationProtectionFilter.java:125) - http-bio-443-exec-1Started new session: B7A65024778B407FFAB964FCC69A6D03
06-26 09:59:16 [DEBUG] com.sillycat.easywebflow.filter.SessionFixationProtectionFilter.doFilter(SessionFixationProtectionFilter.java:129) - http-bio-443-exec-1getting session value from map: D79D7D2BFA59B418AFCE9988C7B940AF
GET username = null password = null sessionId = B7A65024778B407FFAB964FCC69A6D03
06-26 09:59:38 [DEBUG] com.sillycat.easywebflow.filter.SessionFixationProtectionFilter.doFilter(SessionFixationProtectionFilter.java:71) - http-bio-443-exec-2 filter count = 2 sessionId_fromCookie=B7A65024778B407FFAB964FCC69A6D03
06-26 09:59:38 [DEBUG] com.sillycat.easywebflow.filter.SessionFixationProtectionFilter.doFilter(SessionFixationProtectionFilter.java:112) - http-bio-443-exec-2 Invalidating session with Id B7A65024778B407FFAB964FCC69A6D03 start!
06-26 09:59:38 [DEBUG] com.sillycat.easywebflow.filter.SessionFixationProtectionFilter.doFilter(SessionFixationProtectionFilter.java:117) - http-bio-443-exec-2Invalidating session with Id B7A65024778B407FFAB964FCC69A6D03 end!
06-26 09:59:38 [DEBUG] com.sillycat.easywebflow.filter.SessionFixationProtectionFilter.doFilter(SessionFixationProtectionFilter.java:125) - http-bio-443-exec-2Started new session: AA6C79D5794A3E312B1AC679EA0E20D9
06-26 09:59:38 [DEBUG] com.sillycat.easywebflow.filter.SessionFixationProtectionFilter.doFilter(SessionFixationProtectionFilter.java:129) - http-bio-443-exec-2getting session value from map: B7A65024778B407FFAB964FCC69A6D03
GET username = null password = null sessionId = AA6C79D5794A3E312B1AC679EA0E20D9
06-26 09:59:38 [DEBUG] com.sillycat.easywebflow.filter.SessionFixationProtectionFilter.doFilter(SessionFixationProtectionFilter.java:71) - http-bio-443-exec-3 filter count = 3 sessionId_fromCookie=B7A65024778B407FFAB964FCC69A6D03
06-26 09:59:38 [DEBUG] com.sillycat.easywebflow.filter.SessionFixationProtectionFilter.doFilter(SessionFixationProtectionFilter.java:81) - http-bio-443-exec-3 how did this happen, there is no session!!!!!!!!!!!! + sessionId_fromCookie=B7A65024778B407FFAB964FCC69A6D03
GET username = null password = null sessionId = 0DCB304D4CC459BBF8D27B598D260DA7
06-26 09:59:38 [DEBUG] com.sillycat.easywebflow.filter.SessionFixationProtectionFilter.doFilter(SessionFixationProtectionFilter.java:71) - http-bio-443-exec-4 filter count = 4 sessionId_fromCookie=B7A65024778B407FFAB964FCC69A6D03
06-26 09:59:38 [DEBUG] com.sillycat.easywebflow.filter.SessionFixationProtectionFilter.doFilter(SessionFixationProtectionFilter.java:81) - http-bio-443-exec-4 how did this happen, there is no session!!!!!!!!!!!! + sessionId_fromCookie=B7A65024778B407FFAB964FCC69A6D03
GET username = null password = null sessionId = 3B97E2391A371BF696760570DEB3801C
06-26 09:59:39 [DEBUG] com.sillycat.easywebflow.filter.SessionFixationProtectionFilter.doFilter(SessionFixationProtectionFilter.java:71) - http-bio-443-exec-5 filter count = 5 sessionId_fromCookie=B7A65024778B407FFAB964FCC69A6D03
06-26 09:59:39 [DEBUG] com.sillycat.easywebflow.filter.SessionFixationProtectionFilter.doFilter(SessionFixationProtectionFilter.java:81) - http-bio-443-exec-5 how did this happen, there is no session!!!!!!!!!!!! + sessionId_fromCookie=B7A65024778B407FFAB964FCC69A6D03
GET username = null password = null sessionId = 05322091B48BD8E096B12E077B7602C6

We can easily find that, there are multi requests from the browser with the same old jsessionid, certainly, the first thread will invalidate the session with that old jsessionid. And the other requests, precisely the latest thread will lost all value/data, because it will go no where to find these value/data. The getSession(false) API will return null at that moment. And the browser will only remember the latest request.

We can go through the log message.
http-bio-443-exec-3 how did this happen, there is no session!!!!!!!!!!!! + sessionId_fromCookie=B7A65024778B407FFAB964FCC69A6D03

The thread exec-3 is executing with cookie value JSESSIONID=B7A65024778B407FFAB964FCC69A6D03, but this session is invalidated by exec-2. And the latest thread exec-5
http-bio-443-exec-5 how did this happen, there is no session!!!!!!!!!!!! + sessionId_fromCookie=B7A65024778B407FFAB964FCC69A6D03

exec-5 is doing the same thing as exec-3, certainly, empty session and null=session is what we get from getSession(false).

There is 2 ways to fix this problem if we really need to keep our session id changing strategy.
1. Avoid 'repeat submit' at server side. I just use the client side codes, but the end user can press the fresh button:
<script language="javascript">
    var submit=0;
    function CheckIsRepeat()
    {
        if (++submit>1)
        {
            return false;
        }
        var form = document.getElementById("loadingForm");
        form.submit();
        return true;
    }
&lt;/script&gt;<form action="../order/fetchprice.do" id="loadingForm">
</form>
<a href="###" class="button_refresh"></a>

This client side strategy is refused by QA, because they verify this by pressing the refresh button.

If I choose the server side way, when 'repeat submit' happen, I will redirect the end user to an error page to say 'Do not submit repeatly'. And there is really plenty work to do to generate token, store token in session, compare the token.

2. Another way is to make a local cache to store the session data, key is the session id, value is the session value map. And we need to refresh the map depend on time. If one value is not visited more than 5 seconds, I will remove that from local cache. This can solve our problem from my testing, but it is really wired. It seems that I am using a complex way to deal with session instead of web container.

3. Change to Deal with fixation session issue with other strategy.
Verify that additional information is consistent throughout session
if($_SERVER['REMOTE_ADDR'] != $_SESSION['PREV_REMOTEADDR']) {
   session_destroy(); // destroy all data in session
}
session_regenerate_id(); // generate a new session identifier
$_SESSION['PREV_REMOTEADDR'] = $_SERVER['REMOTE_ADDR'];

User Agent
if ($_SERVER['HTTP_USER_AGENT'] != $_SESSION['PREV_USERAGENT']) {
   session_destroy(); // destroy all data in session
}
session_regenerate_id(); // generate a new session identifier
$_SESSION['PREV_USERAGENT'] = $_SERVER['HTTP_USER_AGENT'];

references:
http://stackoverflow.com/questions/10637497/spring-security-session-management-session-fixation-protection-not-working
http://stackoverflow.com/questions/9004878/spring-security-3-1-0-cannot-switch-from-https-to-http
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html#session-mgmt
http://static.springsource.org/spring-security/site/faq.html#faq-tomcat-https-session

http://www.blogjava.net/zhip/archive/2007/06/12/123510.html
http://my.oschina.net/CoderAJ/blog/16079

https://jira.springsource.org/browse/SEC-1462