On 12.01.2016 12: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
If login() modifies the session and the session does not track the
authentication
information, session tracking is not deterministic due to side effects for
multiple
requests at a time.
Fixing either #1, #2 or #3 does not harm security at all but will fix this bug
in Tomcat.
I also tried to use authenticate() on the request, but instead of using the
last login()
credentials it forced the use of Basic Authentication. So really I do not see a
option
left on the developer side, how to use login() in a reliable manner.
Thomas,
what I was trying to explain to you previously, is this :
Any "serious" webserver software is written so that it conforms to the rules defined in
the HTTP protocol specification (RFC 2616/2617 and related). That is the case for Tomcat,
for Apache httpd, and all other webservers. In addition, Tomcat being a java servlet
engine, also adheres to the rules defined in the Java Servlet Specification.
The HTTP specification and the Java Servlet Specification
(https://java.net/downloads/servlet-spec/Final/servlet-3_1-final.pdf) have things to say
about /some/ authentication schemes. When they do, the corresponding webservers / servlet
engines respect these things, and applications should do the same. When the specs do not
say anything about a particular aspect of user authentication e.g., then the webserver and
the applications are free to do what they want, as long as what they do does not violate
another aspect of the specs.
There is no specification which dictates exactly what should happen in terms of
authentication, for multiple simultaneous requests by a client, for webserver resources
that require authentication. There is also no specification which dictates exactly in what
order such simultaneous requests should be processed, nor exactly how long the processing
of each individual request should take. That is because, at the very basic level, HTTP 1.1
is such that multiple requests, even if they originate from the same client over a short
period of time, are still seen as individual, separate requests, from the webserver point
of view; and according to the protocol specs, the webserver could even "delegate" each of
these requests to separate distinct processes in the background (think of a front-end
proxy with a load-balancer for example), and each of these background processes would know
nothing about any other parallel process handling one of these requests for the same
client at the same time. (For example, one of these processes would never know that some
other related process is "just about" at the point of issuing a new session-id to that
same client).
That is just the way it is, and you are not going to be able to get every producer of
webserver code, and of browser code, to change this in a way that suits your own idea of
how things should happen. (It is not forbidden to try, but it will be a long process, much
longer than changing your application).
So, if you want your HTTP-based application to be portable across different webservers and
configurations, it is /you/ who must make sure, in the design and logic of your
application, that a case such as the one you encounter, cannot happen.
One way of doing this would be to design your application in such a way as to /force/ a
client to always go through a first call to a page which triggers the authentication and
returns a result to the browser/client, *before* this client has any chance to make
further calls to other resources which require authentication.
Note that neither Mark nor I are saying that your basic idea is wrong. It may indeed be
better, and more friendly to web application developers, if the HTTP protocol had been
designed in such a way as to avoid this kind of issue. But it wasn't, and considering the
number of browsers and webservers in circulation, making any change to the protocol itself
is a long and protracted process.
You can always try to propose a new HTTP 3.0 version though. If you do, please incorporate
also the premise that all character exchanges should be Unicode/UTF-8 by default.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
