On 12/01/2016 11:06, Thomas Scheffler wrote: > Am 11.01.16 um 22:05 schrieb Mark Thomas: >>> >>> <Valve className="org.apache.catalina.authenticator.BasicAuthenticator" >>> changeSessionIdOnAuthentication="false" /> >>> >>> Found on >>> http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection >>> the description how to switch the "feature" off. >>> >>> I will file two bugs soon describing the issues I had. Hopefully they >>> will be fixed. >>> >>> 1.) if using HttpServetRequest.login(String, String) further request in >>> the session are loosing the users Principal. >>> >>> 2.) After changing sessionId, old sessionIds should still be valid for a >>> short period of time of to the same client. >> >> The second request will get closed as INVALID on security grounds. If >> the old ID is valid for any period of time it makes a session fixation >> attack possible. You might as well disable changing the session ID on >> authentication. >> >> For the first the description above isn't clear enough to be sure >> exactly what you are asking for. However, based on the second request >> and what I have read of this thread I suspect that request will get >> closed as INVALID or WONTFIX. > > Hi Mark, > > if you choose to use login() and this modifies the session ID. Further > calls to login() should either: > > 1.) are not required as every request belonging to the same session are > already authenticated. After login() other request of the same session > will not return 'null' on getRemoteUser() or getUserPrincipal() > > 2.) are not required, as authenticate() use the information provided by > the first login() call. > > 3.) do not modify the session ID as the same user was authenticated > before and the session is therefor safe to session fixation attacks
Those 3 all boil down to essentially the same requirement. Requests are populated with cached authentication information from the session at the start of the request (if the authenticator is configured to do so - all but DIGEST are by default). This request is asking that any method call on the request relating to authentication checks the session if the authenticator is configured to cache authentication information in the session. While this is possible, it won't solve the problem. There will still be a race condition in the application. Consider the following: Request1 - getRemoteUser() == null; Request2 - getRemoteUser() == null; Request2 - login() - OK Request1 - login() - ServletException as user is already logged in Given that the requested change will add complexity without actually solving the problem any enhancement request opened asking for such a change will be resolved as WONTFIX. Therefore, I come back to my earlier point that the correct solution is for the application accesses authenticated resources in a sane way and then these issues simply won't be possible. In the specific example for this thread, the page that generates the list of thumbnails needs to require authentication as well as (some of) the thumbnails. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
