-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Peter,
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 > alive. 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 > problem. 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 session. 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. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlp8ip4dHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFg1DA/+K/ZKa2gLkCskcl8c O0YsT7fu4e+9gRJkM4oQJdTG5FgweplXz+9kj8v3N+xIdWsX4GbmfdnlRuiA68Hp x2aZYoO/phngj9uD5odUohtOFDxU/xnTOS3w5WPdicSxvHV5Ctdi+0Rn+9EeQESK LaBjy0O98xDhY7nO2doCCebtm07JuNVdTJd9Itu6KvYavOJOGnrTWnFTREwc1inD RWHn+npEF4ue2TktqS9xD8d1RKQkAQVazg+WPKjOHgZxKALI4p24zdAIImUIob6Z +YmIbXcSHbU0sjM7FIciCdVm4fEL9HSaI9qcUwvlFQW5UL7FRocc/7RRthzYhvov U1cPKi7tQgJKT6MyVWEwMA5E4MaZ/uX0oU+WAfARcEBV1NdSqBVoDKI+lrX18IKy Ff1AP03sycwT6xBWPQlAkKBIqxRDeNI4W0ysmzEYkxSa7uzm0oCBHVJ05BQdBksO pszI5EJv1sN6n4V/QrVsbYFXQT1XYmPy5j5uBh6z6/NPVaPyMY/AZRokAfsfhgGC xOQc0QSNZZXH/v6Lc+DukhNOCBJD+KAhS0NDbUmcf3bJ7KTQVoupY4djdrGz+t1M bUrUZDhyXu5w+1pjJL7o40iDiksc8zKVY17FU+BoM+Hd0DscEN+HWfWCZ2C6dcJP 1mVfPAV5+Rf6iaPafbh27Q67p2Q= =LOii -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
