Thomas, On 1/13/16 1:04 PM, Thomas Scheffler wrote: > Am 13.01.16 um 15:48 schrieb Christopher Schultz: >> Thomas, >> >> On 1/13/16 8:31 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. >>>> >>>> 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). >>> >>> Hi, >>> >>> "all but DIGEST are by default" was my case. >>> >>> As I walked through the code I found most of the features I requested >>> are already in place. There is already the tracking of the Principal in >>> the session. To use the values of login() later in authenticate() in >>> Tomcat 8.0.30 I had to insert "/foo" as my login page and "/bar" as my >>> login-error-page. I think any value will do here ;-) >>> >>> <login-config> >>> <auth-method>FORM</auth-method> >>> <realm-name>Restricted</realm-name> >>> <form-login-config> >>> <form-login-page>/foo</form-login-page> >>> <form-error-page>/bar</form-error-page> >>> </form-login-config> >>> </login-config> >>> >>> This activates the FormAuthenticator which correctly does, what I was >>> hoping for. >>> >>> I think every authenticator can/should use the information stored by >>> login() if it is available. >> >> Which argument to login() carries the server-generated nonce used for >> login? Which argument includes the realm name? >> >> https://en.wikipedia.org/wiki/Digest_access_authentication > > Hi Chris, > > the login() method gets the username and the password. It has nothing to > do with configured auth-method in the web.xml.
I'm familiar with this method and how it works. > Tomcat uses a generic > method[1] located in a super class do perform the login. The Principal > is stored in the session, if caching is enabled and a session is present > or created. > Depending on the configured auth-method the Principal is used later, if > found or not. My suggestion was to always use it, when it is stored in > the session. Tomcat can't verify that the incoming credentials match those credentials that were used in a previous login. How could Tomcat decide if new credentials were being used if Tomcat doesn't actually try to use them? Then, if Tomcat uses the credentials and they are valid, the session id must be changed for session-fixation prevention. If there is a difference between the BasicAuthenticator and the DigestAuthenticator, then that gap should probably be closed. -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
