You can't configure undertow with org.apache.catalina.* system property. Changing session is default behaviour in undertow  from some point. Can you upgrade?
Sorry for asking. we are on WildFly 10 and facing same issue. Do we have to do some configuration changes to enable such behaviour. If yes, can you help me with needed cofiguration change for undertow ?
What mechanism are you using to authenticate users? This behavior only triggers when standard servlet authentication is used.
we are using form based authentication.
To update , I overcome it by writing a custom filter for it. It works nicely.
The jsessionid *must not* change after login,
this would violate the servlet specification. (Chapter Security, Login and Logout):
Containers may create HTTP Session objects to track login state. If a developer
creates a session while a user is not authenticated, and the container then
authenticates the user, the session visible to developer code after login must be the
same session object that was created prior to login occurring so that there is no loss
of session information.''
So the behavour of wildfly is as specified.
Agreed from specification perspective, but per security recommendations , if a user open a form based authentication page ( didn't enter credentials yet ) and a hacker got access to jsessionid , then post real user validation that can be used to gain access to system without knowing credentials.
Not sure , if we have some other way to prevent it.
Yes, imagine hacker send url with sessionId and user click on it. In this case it is good application changes session id after login.
i dont see why changing a jsessionid is increasing the security.
Let us assume the communication between client and login page is https,
then an attacker can get the jsessionid only on two ways
(1) The attacker was able to get it from the login page
==> Then you have a much bigger problem
(2) From the client directly
==> The he will also be able to get a new jsessionid.
From where did you get this security recommendation ?
1 of 1 people found this helpful
Internally we get recommendations from internal product security, but its a common session fixation issue.
i thought we are talking about jessionid with cookies.
jsessionid in URL allows session fixation attacks.
The solution here is easy: ,,disable jsessionid with URL rewriting''.
From the servlet specifiaction ==>
,, URL rewriting should not be used as a session tracking mechanism where
cookies or SSL sessions are supported and suitable.''
Or do you have a reason to allow browsers access to your application that
dont accept cookies ?
<secure>true</secure> <!-- only https -->
hope this helps.