[undertow-dev] ChangeSessionIdOnLogin unexpected behavior during SPA initialization

[Matthieu BROUILLARD]

Hi all,

first of all sorry if some of you already answered on my IRC request on
freenode but due to network policy in my company I could only connect via
web and have been disconnected without access to channel history.
I apologize if you already took time to answer on the channel but I could
not see your answer.

The problem I have is around the 'ChangeSessionIdOnLogin' feature
implemented in undertow. I understand that the feature is there in order to
avoid attacks via session reuse (exposing a link with an already provided
JSESSIONID for example).

In one of our application, a SPA application with some server side
HttpSession caching, during initialization a bunch of asynchronous calls
are performed. Due to the 'ChangeSessionIdOnLogin' feature several of them
are failing.
I have implemented a simple reproducer application exposing the problem and
possible workarounds (examples are self runnable using maven :
https://github.com/McFoggy/jsessionid-concurrency).

In the provided reproducer app we workaround the JSESSIONID regeneration by
either:
  - making a fake call before the asynchronous calls are performed
(changing the JSESSIONID before parallel calls occure)
  - disabling the 'ChangeSessionIdOnLogin' feature using an undertow
ServletExtension

The real question I have is why the created session is not trusted (see
https://github.com/undertow-io/undertow/blob/master/servlet/src/main/java/io/undertow/servlet/handlers/security/CachedAuthenticatedSessionHandler.java#L93)
when the HttpSession is created by an authenticated call without incoming
JSESSIONID?

Is this a bug? I'll fill an issue if so.
Is this a feature? In this case what is the recommendation to avoid this
when several calls are issued before JSESSIONID stabilization like in the
demo project?

Thanks for any hint & answer.

Matthieu
- - - - - - - - - - - - - - - -
http://blog.matthieu.brouillard.fr/
http://oss.brouillard.fr/
https://github.com/McFoggy
https://twitter.com/alightinthefog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170208/46ba3db2/attachment.html