You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Henner Zeller <he...@freiheit.com> on 2002/07/03 12:52:39 UTC
Re: [Bug 10419] - Session-ID grabbing from Request accepts invalid
session cookies in presense of valid URL sessions
Hi,
[-----
this disucsses Bug 10419 and 10418. See details in
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419
and
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10418
with a bug-demonstration servlet
http://www.freiheit.com/users/hzeller/SessionBugDemonstration.java
this works with JServ and tomcat 3.2 but fails with tc 4.x
--- ]
> Your statement is incorrect. URL encoding does work, but it is a all-or-nothing
> situation (ie, either you allow session cookies or you don't).
Users do sometimes allow cookies for one situation and not for another.
The applications shouldn't fail because of this - at least should the
application server (tomcat) not make decisions that only the application
developer can do. And letting an application fail because once the client
used cookies but then in another session chooses not to is not good.
Especially, since you cannot do anything to work around this problem in
the application since this decision is made in tc. This makes things more
fragile which is never good for enterprise quality. And I hope enterprise
quality is what we should expect from the flagship of servlet engines!
We always have the problem, that we might get multiple session ids (from
the URL, from _multple_ cookies). The expected
behaviour of getRequestedSessionId() is of course, that it should return a
session ID that is (if possible) valid in our context, not just _any_ of
the session IDs we got. The servlet spec is not very precise in this point
stating, that the getRequestedSessionId() might not necessarily the same
as the session in use. However, tomcats lookup mechanism for
HttpSessions, does: the id returned by getRequestedSessionId() is the
_same_ that is used to lookup the session in the context -- and if this
is not a valid session id, we don't get _any_ HttpSession.
Or a different problem caused by the same behaviour:
Think of the simple use case that is explained in Bug #7588: if we have
multiple sessions in different contexts that all use cookies, then all
sessions will fail to work but the first one (having the first
cookie)
Problem here is: there are multiple cookies, but only one of it is valid in an
specific context. Just fetching the _first_ cookie ist not possible: only
the first application will work (because it can look up a valid
HttpSession with the session id), but others not: the first cookie does
not denote a valid session id in that context.
So: if we use the result of getRequestedSessionId() to lookup the
HttpSession (which makes sense), that we _have_ to make sure that we
extract the sessionid from the multiple sessionids we might get in the
request that actually makes sense in that context.
Suggestion:
The alternative would be to make getSession()
[ HttpRequestBase.doGetSession() ] look itself in the http-request to look
for a valid session id from the assortment of possible session ids.
instead of using requestedSessionId.
Even better would be to delay the determination of requestedSessionId
until the context is known: on the first call of getRequestedSessionId()
in the application [ and cache the result ].
This would enhance the performance as well in the
HttpProcessor.parseHeaders(), since we do the check only if
it is necessary at all (Delaying expensive operations is always a good
idea).
Ok, I'll prepare a patch for this, then we can discuss this.
ciao,
-hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Bug 10419] - Session-ID grabbing from Request accepts invalid
session cookies in presense of valid URL sessions
Posted by Henner Zeller <he...@freiheit.com>.
Hi,
> OK, but why should the requested session id from the URL be considered any
> more likely to be valid than a session id from the cookie? They both got
> created at the same time (when this page was generated), and will have the
> same value if you did the normal thing of using response.encodeURL() to
> create the rewritten URL.
It should be considered at all. If the cookie does not contain a valid ID,
then check the session id that comes from the URL.
As I pointed out, the session IDs could indeed be different, if in a
previous session the user accepted a cookie and -- after the first session expired
-- starts a new session, but this time rejects the cookie, so URL encoding is
necessary. The browser, however, will still send the old cookie.
In that case the cookies session-id will not lead to a successful
HttpSesison lookup, but the URLs session id will. This is why we need to
check both IDs one after another if the first fails to bring up a
successful session lookup.
Another aspect of the same story is why we have to make the decision,
whether a URL encoding is necessary, make dependent on the fact,
that the requested session id came from a cookie _and_ that this session
id actually is _our_ current, valid session id; this can be fixed
relativly simple:
##########
--- catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java
+++ catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java
@@ -491,7 +491,8 @@
HttpSession session = hreq.getSession(false);
if (session == null)
return (false);
- if (hreq.isRequestedSessionIdFromCookie())
+ if (hreq.isRequestedSessionIdFromCookie()
+ && session.getId().equals(hreq.getRequestedSessionId()))
return (false);
// Is this a valid absolute URL?
##########
The testcase servlet
<http://www.freiheit.com/users/hzeller/SessionBugDemonstration.java>
simulates this.
(probably not a
very likely use-case .. but while testing applications this happens all
the time).
> That's the only scenario I can think of where you'd get a cookie with a
> session id from some other webapp, which seems to be the use case you'd
> want this change of behavior for.
No, the use-case is what I mentioned above. The broken client is
hypothetical; the problem was, that I didn't know about the way the client
should send (and suppress) cookies so I assumed that this might be an
additional problem.
> And if it really is a broken client that causes this, I don't think that's
> a very compelling reason to change the server's behavior :-).
Even if - it would be good if the server would be robust in that case,
right ?
ciao,
-hen
--
Henner Zeller
Dipl.-Inform. Med.
freiheit.com technologies gmbh
Theodorstr. 42-90 / 22761 Hamburg, Germany
fon +49 (0)40 / 890584-0
fax +49 (0)40 / 890584-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Bug 10419] - Session-ID grabbing from Request accepts invalid
session cookies in presense of valid URL sessions
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 3 Jul 2002, Henner Zeller wrote:
> Date: Wed, 3 Jul 2002 21:10:14 +0200 (CEST)
> From: Henner Zeller <he...@freiheit.com>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Developers List <to...@jakarta.apache.org>
> Subject: Re: [Bug 10419] - Session-ID grabbing from Request accepts
> invalid session cookies in presense of valid URL sessions
>
>
> Hi,
> > If you want the *current* session for this request, you should always call
> > request.getSession() instead.
>
> Yes. This is correctly working in tomcat 3.x: the getRequestedSessionId()
> returns one of the IDs with preference to the cookie; the getSession()
> returns the current session. perfect.
>
> However: in tc 4.x this does not work anymore since
> internal lookup uses the requestedSessionId:
>
> (From HttpRequestBase:)
> -------
> if (requestedSessionId != null) {
> try {
> session = manager.findSession(requestedSessionId);
> } catch (IOException e) {
> session = null;
> }
> }
> if ((session != null) && !session.isValid())
> session = null;
> -------
>
> But this should be something like
> -------
> if (requestedSessionIdFromCookie != null) {
> try {
> session = manager.findSession(requestedSessionIdFromCookie);
> } catch (IOException e) {
> session = null;
> }
> }
> if ((session != null) && !session.isValid())
> session = null;
>
> // if the session still is null, then consider the id from the URL.
> if (session == null && requestedSessionIdFromURL != null) {
> try {
> session = manager.findSession(requestedSessionIdFromURL);
> } catch (IOException e) {
> session = null;
> }
> }
> if ((session != null) && !session.isValid())
> session = null;
>
> -------
> Thats my whole point.
>
OK, but why should the requested session id from the URL be considered any
more likely to be valid than a session id from the cookie? They both got
created at the same time (when this page was generated), and will have the
same value if you did the normal thing of using response.encodeURL() to
create the rewritten URL.
>
> > If case (b) happens, your client is broken.
>
> admitted ;-)
>
That's the only scenario I can think of where you'd get a cookie with a
session id from some other webapp, which seems to be the use case you'd
want this change of behavior for. Is there another one that I'm missing?
And if it really is a broken client that causes this, I don't think that's
a very compelling reason to change the server's behavior :-).
> -hen
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Bug 10419] - Session-ID grabbing from Request accepts invalid
session cookies in presense of valid URL sessions
Posted by Henner Zeller <he...@freiheit.com>.
Hi,
> If you want the *current* session for this request, you should always call
> request.getSession() instead.
Yes. This is correctly working in tomcat 3.x: the getRequestedSessionId()
returns one of the IDs with preference to the cookie; the getSession()
returns the current session. perfect.
However: in tc 4.x this does not work anymore since
internal lookup uses the requestedSessionId:
(From HttpRequestBase:)
-------
if (requestedSessionId != null) {
try {
session = manager.findSession(requestedSessionId);
} catch (IOException e) {
session = null;
}
}
if ((session != null) && !session.isValid())
session = null;
-------
But this should be something like
-------
if (requestedSessionIdFromCookie != null) {
try {
session = manager.findSession(requestedSessionIdFromCookie);
} catch (IOException e) {
session = null;
}
}
if ((session != null) && !session.isValid())
session = null;
// if the session still is null, then consider the id from the URL.
if (session == null && requestedSessionIdFromURL != null) {
try {
session = manager.findSession(requestedSessionIdFromURL);
} catch (IOException e) {
session = null;
}
}
if ((session != null) && !session.isValid())
session = null;
-------
Thats my whole point.
> If case (b) happens, your client is broken.
admitted ;-)
-hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Bug 10419] - Session-ID grabbing from Request accepts invalid
session cookies in presense of valid URL sessions
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 3 Jul 2002, Henner Zeller wrote:
> Date: Wed, 3 Jul 2002 20:33:11 +0200 (CEST)
> From: Henner Zeller <he...@freiheit.com>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Developers List <to...@jakarta.apache.org>
> Subject: Re: [Bug 10419] - Session-ID grabbing from Request accepts
> invalid session cookies in presense of valid URL sessions
>
>
> Hi,
> > > We always have the problem, that we might get multiple session ids (from
> > > the URL, from _multple_ cookies).
> >
> > You should not be getting multiple session id cookies for different
> > webapps unless (a) the context paths overlap, or (b) your client is not
> > following the rules of the specs. See my comments on Bug 10419 for more
> > info on how situation (a) is dealt with.
>
> ok, sounds good.
> Considering that the client sends the right cookie for that context first,
> there is the only problem, that we still can get two session-ids in
> a request
> o from the URL
> o from the cookie.
>
> Currently, a cookie overrides a session-id that has been gotten from the
> URL unconditionally.
True.
> The whole point here is: if that session id from the cookie is
> invalid because:
> a) The session in the cookie is expired or has been invalidated
That does not change the fact that this is the session id that the
application originally requested (as opposed to the current one for this
request). That is what things like getRequestedSessionId() are supposed
to return. Also, the session id requested in the URL is just as likely to
have been expired or timed out as the session id requested with a cookie
-- there is no a priori reason to believe that it would be "better".
If you want the *current* session for this request, you should always call
request.getSession() instead.
> b) The session in the cookie comes from a different application
> context because for _this_ application context there is no
> cookie, thus the other cookie is placed first
> we don't get a HttpSession in the application since it tries to look up
> it with the wrong ID.
>
If case (b) happens, your client is broken. It should not be sending the
session id cookies for webapp "/foo" to webapp "/bar" on the same host,
because that would mean it's ignoring the path attribute on the cookie.
> If users have cookies enabled all the time, this is probably not the case.
> Others might be a bit more picky when to allow cookies and in that case
> the 'override anything requested in the URL' scheme might not be a good
> idea. Dealing with both possible session ids and give preference to the
> one that is currently valid in that context should be the goal.
>
> -hen
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Bug 10419] - Session-ID grabbing from Request accepts invalid
session cookies in presense of valid URL sessions
Posted by Henner Zeller <he...@freiheit.com>.
Hi,
> > We always have the problem, that we might get multiple session ids (from
> > the URL, from _multple_ cookies).
>
> You should not be getting multiple session id cookies for different
> webapps unless (a) the context paths overlap, or (b) your client is not
> following the rules of the specs. See my comments on Bug 10419 for more
> info on how situation (a) is dealt with.
ok, sounds good.
Considering that the client sends the right cookie for that context first,
there is the only problem, that we still can get two session-ids in
a request
o from the URL
o from the cookie.
Currently, a cookie overrides a session-id that has been gotten from the
URL unconditionally.
The whole point here is: if that session id from the cookie is
invalid because:
a) The session in the cookie is expired or has been invalidated
b) The session in the cookie comes from a different application
context because for _this_ application context there is no
cookie, thus the other cookie is placed first
we don't get a HttpSession in the application since it tries to look up
it with the wrong ID.
If users have cookies enabled all the time, this is probably not the case.
Others might be a bit more picky when to allow cookies and in that case
the 'override anything requested in the URL' scheme might not be a good
idea. Dealing with both possible session ids and give preference to the
one that is currently valid in that context should be the goal.
-hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Bug 10419] - Session-ID grabbing from Request accepts invalid
session cookies in presense of valid URL sessions
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 3 Jul 2002, Henner Zeller wrote:
>
> We always have the problem, that we might get multiple session ids (from
> the URL, from _multple_ cookies).
You should not be getting multiple session id cookies for different
webapps unless (a) the context paths overlap, or (b) your client is not
following the rules of the specs. See my comments on Bug 10419 for more
info on how situation (a) is dealt with.
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>