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.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
