> On 25/01/2012 02:43, Alex Rojkov wrote:
> > I don't think it should be default behaviour because it definitely
> > breaks the session id contracts established by previous versions of
the spec.
>
> Whether or not the session id is changed on authentication should be
up to
> the container. My own view is that they should but I only get a vote
on what
> Tomcat does. The specification should not mandate either doing this or
not doing this.
>
> > So adding the method onto an HttpSessionListener is fine and no
need to
> create an extra class.
>
> I'm happy with doing this and letting the containers make the decision
> re backwards compatibility. I'd also be happy with a new interface.
This is a pretty serious security issue. Just so everyone is on the
same page here, the attack scenario is something like this. Attacker
visits site and gets valid <sessionid> but does not log in. Attacker
creates a URL that includes ;jsessionid=<sessionid> and sends that to
victims via email, malicious web pages, tinyurl, etc... The attacker
sits back, keeps those sessions alive, and waits for victims to
authenticate, at which time he owns their account.
Granted some user interaction is required, but this is an easy attack
and virtually guaranteed to work if the victim pool is big enough.
So I definitely think session rotation should be the default behavior,
with a clear warning to developers that disabling secure sessions
exposes their users to attack.
--Jeff