-----BEGIN PGP SIGNED MESSAGE-----
On 2/8/18 11:30 AM, Peter Kreuser wrote:
> Forgive the top-post!
iOS mail lets you type anywhere you want!
> Going back to the root-cause of the question:
> In my opinion the security requirement stems from the idea, that a
> logout must invalidate the session and thus make the data
> practically inaccessible - instead of just removing a typical
> loggedin flag and keeping the once used session with stored values
The container has no "logout" mechanism, the application must
implement it -- usually by invalidating the session. Invalidating the
session removes that session from the list of valid sessions.
There is no "logged-in flag", at least not in the container. The
application may have such a flag -- possibly in a database?
The user may simply leave the site without formally logging-out --
like closing the browser window. The server has no idea that the user
will never return. That's why sessions expire after a certain period
of inactivity... 30 minutes is the default.
> That is essentially not a requirement to tomcat but to the
> developer who implements the webapp.
The container must implement the timeout, but the application must
implement the explicit-logout.
> If that would always be the case (and of course for tomcat to keep
> track of active ids) would make session id reuse not a big deal.
Session id reuse is in fact not a big deal conceptually. Except you
don't want to use an MRU queue and intentionally re-use session ids in
the near future, because...
> PS: Please also review “session fixation” as a side note to this
If I get session id abcd1234 and then log out, and Tomcat implements a
"session id re-use" policy, then someone in the very near future will
end up using the session id abcd1234. Knowing a user's session id is
equivalent to being logged-in as that user (in the absence of any
other authentication mechanism, of course), so I simply have to wait a
few minutes and then try to use session abcd1234 again. Once I can see
that it's been re-used (because I don't get a login prompt when
requesting a protected resource), I can take control of that user's
This is why it is important to require sensitive operations to
re-authenticate the user. For example, changing the current password
to a new one should require that the old password be provided as proof
that you are STILL who you said you were when you logged-in.
Many mitigations for session-fixation attacks exist. Some examples I
can think of off the top of my head:
1. Use source-IP as an additional factor. When the user logs-in,
record their IP address in the session and validate it for every
subsequent against that session. No match == invalidate the session.
2. Generate a nonce when the user authenticates (logs-in) and store it
in the session. Also send that value as a cookie to the user. Match
the cookie value against the session-value for each request. This
*sounds* like just another re-implemenation of the JSESSIONID cookie,
but it's not. The session-id can be "fixated" (by predicting the
session id), but the nonce is independent of the cookie. The attacker
would have to predict not only the session id (which can be done by
tricking the victim into using a chosen session id) but also the nonce
generated by the application, which should be extremely difficult.
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org