jsr340-experts@servlet-spec.java.net

[jsr340-experts] Re: SERVLET_SPEC-13: Make session fixation protection part of the spec

From: Alex Rojkov <alex_at_caucho.com>
Date: Thu, 19 Jan 2012 14:52:04 -0800

>>>>> I am looking at http://java.net/jira/browse/SERVLET_SPEC-13
>>>>> ("SERVLET_SPEC-13: Make session fixation protection part of the spec")
>>>> As the container would use this automagically, it would break existing
>>>> applications (the session id is used often as a key).
>>> I've seen little evidence of that on the Tomcat users list since Tomcat
>>> 7 introduced this behaviour by default.
>>>
>>> There was one instance where an applet broke because it continued to use
>>> the old session ID and didn't pick up the new one.
>>>
>>> That said, it would be advisable for containers to make any automatic
>>> use of this API configurable.
>>>
>>>> The new changeSessionId API method, if added, must be added on the
>>>> request object (since the request has fields about the session that must
>>>> be updated, and a new cookie must be added). So -1 for adding it on
>>>> HttpSession, I think this won't work well.
>>> Makes sense to me. Tomcat's implementation already has this so plumbing
>>> it in to the Servlet API would be trivial.
>> I notice one more different: a String argument.
>> In Tomcat (and also GlassFish), we have
>> org.apache.catalina.connector.Request#changeSessionId(String newSessionId)
>
> In my opinion the session ids must be container managed. We can't rely on the users
> of the API to be able to generate good IDs. I am not in favour of letting users
> generate Ids.
>
> ]
>> In other words, the caller of the API need to know a newSessionId as follows:
>> a) javax.servlet.http.HttpServletRequest:
>> public void changeSessionId(String newSessionId);
>
> -1. See above.
>
> public void changeSessionId() is OK.
>
> public String changeSessionId() can be considered as alternative.
>
> It's likely that the new sessionId will be needed right after it's generated.
>
> Alex
>
>>
>> Also, in previous bug comments and discussion, there is a suggestion to add a new method:
>> b) javax.servlet.http.HttpSessionListener
>> public void sessionIdChanged(HttpSessionEvent se);

Possibly also pass the oldId.
public void sessionIdChanged(HttpSessionEvent event, String oldSessionId);

Alex

>>
>> Note that (b) may break some of the user applications. Is it ok?
>>
>> Shing Wai Chan
>>
>>
>>
>
>
>