tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Ström <jo...@headweb.com>
Subject Re: PATCH: Session ID from URL; would like some input!
Date Tue, 13 Oct 2009 11:01:22 GMT
Hi Mark,
thanks for your response!

On Oct 13, 2009, at 10:29 , Mark Thomas wrote:

> Johan Ström wrote:
>> Hello list!
>> First of all, this maybe better suited for the dev list, but a quick
>> peek only showed svn log mails etc soo.. Sending here instead, let me
>> know if its wrong!
>
> It is 50/50. The patch is of more interest to the dev list but if the
> patch is rejected then the users list is the best place to get ideas
> about other ways of doing things. The mailing lists block most patches
> so an enhancement request in Bugzilla is the best place for your  
> patch.


I see, it's available here if you'd like to take a quick look:

https://dev.headweb.com/johan/pub/Request.java.patch


>
> Without seeing the patch it is hard to comment but SRV.7.1 makes it
> clear that cookies override URL parameters. It doesn't make a  
> comment on
> what if the cookie session is invalid and the URL one not. There might
> be some scope for flexibility here.

Correct, cookies override URL parameter, but as you said, not when the  
session in cookie is invalid. I guess one could make it configurable  
but I have no idea how that would be done, haven't dug that deep into  
the tomcat source :)

>
>> We're having a problem related to Tomcat, in a pretty unusual  
>> scenario.
>> Basicly the problem is with old expired sessions, and reading  
>> session ID
>> from URL instead of cookie.
>> An example, in our case browser A is a main browser, and browser B  
>> is a
>> slave "browser" (actually only a webkit rendering engine) which we  
>> only
>> call with an URL to show a specific page, and we do not have control
>> over cookies in browser B.
>
> Any way to "close" "browser B"? That should delete the session cookie.

Unfortunately not, so not a solution.

>
>> So, browser B sends both the old session ID in the cookie (which is  
>> an
>> expired session), and the new sessionid on the URL. This confuses  
>> tomcat.
>> In catalina/connector/Request.java and CoyoteAdaptor, we first  
>> check for
>> a sessino ID on the URL, store it in Request, and then we check  
>> for  a
>> cookie, and if we got one, we just overwrite the session ID from  
>> the URL.
>>
>> My solution? The attached patch!
>> Now, what I'd like to know, can anyone of you developers see any  
>> nasty
>> side effects that I might have missed about this?
>
> In principle, it sounds OK but I'd want to see the patch first. If it
> were implemented, then it would go into Tomcat 7 and may not be
> back-ported to earlier versions. It may also be made optional.

See URL above.

>
> Keep in mind that session handling is more configurable in the Servlet
> 3.0 spec (not that I think it helps with this issue) and that changing
> the session ID on authentication to protect against session fixation  
> is
> an open enhancement request that should also get included in Tomcat 7.

Me changing the session ID is not what I'm doing, its rather that the  
old session ID has timed out, and browser A is assigned a new session  
which i need to tell browser B to use too.

>
>> One thing that was concerned about was that it would introduce  
>> session
>> hijacking risks, but the only difference is that the evildoer have to
>> erase his (already expired) cookie.. Normal tomcat accepts  
>> jsessionid on
>> URL anyway, as long as there is no cookie, so that should not be a
>> security concern.
>
> Agreed.

Great :)

Johan


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message