Thomas, On 1/12/16 8:03 AM, Thomas Scheffler wrote: > Am 12.01.16 um 13:24 schrieb Mark Thomas: >> 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. > > Sorry, I do not see this leed to the same requirement. > > 1.) The Servlet-Spec notes: > > 13.6.3: > "The login method of the HttpServletRequest interface provides an > alternative means for an application to control the look and feel of > it’s login screens." > > 13.6.3.1: > "If the user is authenticated using form login and has created an HTTP > session, the timeout or invalidation of that session leads > to the user being logged out in the sense that subsequent requests must > cause the user to be re-authenticated." > > This defines a call to login() should be handled like Form-Login and not > as Basic-Authentication - like Tomcat currently does. It further states > the the user is logged-out on session timeout and not with every new > request. > >> 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). > > As stated above, if I use the authenticate() method. The user get a > Basic Authentication window asking for a login. At latest there should > be a usage of the already known credentials used by login(). > >> 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. > > Oh come on. It's the same case with the logout() method. No problem > there. Tomcat could handle this gracefully without any problems. > >> 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. > > It boils down to this problem: > > It's the servlet containers duty to do the session tracking. I showed, > that there is a racing condition and *Tomcat* currently fails to do so. > The client (every browser on the market) are not the problem here, they > behave like they should (Tomcat tells to value of the session cookie!) > > I file the bug, that's all a user can do.
The race condition is with the application's behavior. Tomcat cannot protect against the use-case you present here in any sane way. The problem is that you are issuing many requests simultaneously, some which do and some which do not require authentication. Those that do not require authentication are irrelevant, since they should not have any binding to the session (right)? Why do you allow your users to make multiple simultaneous requests to the app server that require authentication instead of authenticating them a single time and then giving them access to protected resources? Maybe I just don't understand your use case very well. It sounds like you want to have a page with mixed-use content and the first request to require authentication triggers an authentication dialog. Combine that with the fact that you are issuing your own login() calls means that you are actually fighting against the process that Tomcat would normally use for authentication. Even if things could be locked-down within a single server node in the way you request, extending this "feature" to a cluster would basically be impossible. That would mean different semantics depending upon the deployment model, which is pretty much a deal-breaker all-around. -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
