tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kulessa <kule...@flexsecure.de>
Subject Re: HttpServletRequest - getHeaders() vs getCookies()
Date Wed, 16 Jul 2014 08:02:29 GMT
Hello Christopher,

thanks for your answer.

Am 15.07.2014 16:12, schrieb Christopher Schultz:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Simon,
>
> On 7/9/14, 4:51 AM, Simon Kulessa wrote:
>> I had a look at the documentation and the tomcat source to get a
>> better understanding of what the
>> '|org.apache.catalina.connector.RECYCLE_FACADE' parameter actually
>> does.|
>>
>> I have seen that Tomcat objects like Cookies, Request etc. are
>> designed to be reusable.
> Requests, yes. I haven't looked to see if Cookies would be re-usable
> but it seems plausible.
>
>> What I currently do not understand is: In which scenario and what
>> context are they going to be reused? I see there are Endpoints
>> classes (like NIOEndpoint) which are used to process the different
>> requests. This seems to be the most likely entry point into the
>> scenario.
>>
>> Maybe somebody can provide some general outline of how requests and
>> the reusing of the object actually works together? Is there some
>> kind of relation to the IP of an incoming request?
> The client's IP is irrelevant: Tomcat uses a pool of objects and
> re-fills each object with data from an incoming request. These
> objects, as far as the web application should be concerned, should
> have a valid lifetime equal to the request itself. The servlet spec
> requires these semantics, so this isn't some weird Tomcat thing.
> Tomcat has chosen to pool these objects for a small performance gain
> when it comes to memory management and garbage collection.
>
> If your application retains references to these objects after they
> become invalid, they may contain invalid data or valid data from
> another request after they should have become invalid form the
> perspective of the original request.
>
> If you need data from a request, cookie, etc. then you should copy it
> somewhere safe before the request ends.
We do not cache any request specific information.

The IP relation itself is irrelevant - it seems that the reused object's 
contains more 'old' informations
than I previously assumed. The header itself and the requestedSessionId 
seems to be changed,
the sourceIP and the cookie stay the same.

>
>> In our code we hold a reference to the httpSession outside of the
>> request (in a application scoped map).
> HttpSession objects should be cacheable in this way. You do have to be
> careful that when the HttpSession expires, you remove those object
> references from your application-scoped Map or you risk memory exhaustion.
We remove them we one of the methods (onError, onTimeout, onComplete)
of the javax.servlet.AsyncListener is called. So this should not be an 
issue.
>> We use this session object to read the SessionId, to invalidate or
>> to adjust the session timeout from outside a client request.
> That should be okay. Are you storing request or response objects in a
> similar way?
No, we do not store any request or response objects.

What I noticed is that if you invalidate the session from outside, while 
a request (in another Thread)
is still alive for this session, request.getSession().getId() may return 
a different sessionId than before.

Is that supposed to be the case or is this a bug in Tomcat?

>> I finally received the logs where the session itself was created:
>> Basically there is some communication ongoing between client and
>> server, then the server receives an unexpected command and decides
>> to invalidate the session because of this.
> Good so far.
>
>> Later another command of the client with the old cookie arrives and
>> is rejected by our server.
> Seems reasonable.
>
>> After this any other request coming from the same IP fails.
> Fails how? Exception? Unexpected behavior? Please be specific.
We added some logic to check the content of the cookies. But the cookies 
does
not contain a valid data (for our application) at this point this it is 
not the
cookie that was part of the header.

>> As mentioned in the logs we see the httpHeader that does contain a
>> cookie with a different value, but the getCookies() method always
>> provides the cookie value of the 'original session'.
> How many cookies do you see? The client can provide more than one
> JSESSIONID cookie. Also, when the request arrives with the "old"
> JSESSIONID cookie, it does not mean that the old session id is valid.
> It's just that the client still thinks the session is valid.
>
> Are you using Tomcat-managed sessions, or are you doing your own
> session management?
I see only one cookie in the header.
I know that the cookie does not need to be valid, but this is not the 
issue here.

At this point I assume that the client does not even send the 'old' cookie.

>> Around the same time when the original session was still alive I
>> found an error message in the Catalina log:
>>
>> ... org.apache.coyote.AbstractProtocol$AbstractConnectionHandler
>> process SEVERE: null java.lang.IllegalStateException: Calling
>> [asyncPostProcess()] is not valid for a request with Async state
>> [STARTED] at
>> org.apache.coyote.AsyncStateMachine.asyncPostProcess(AsyncStateMachine.java:202)
>>
>>   at
>> org.apache.coyote.AbstractProcessor.asyncPostProcess(AbstractProcessor.java:116)
>>
>>   at
>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
>>
>>   at
>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1653)
>>
>>   at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
>> Source) at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>> at java.lang.Thread.run(Unknown Source)
>>
>> I am not sure whether this is somewhat related to the problem
>> scenario, but at least this looks like something that should not
>> happen.
> I believe there are some edge cases related to acync processing that
> have been identified and fixed in the versions between yours (7.0.29)
> and the current release version (7.0.54). You should really upgrade
> regardless of whether or not this fixes your particular problem(s):
> there have been many security fixes classified as "important" since
> your version (which is nearly 2 years old).
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJTxTbEAAoJEBzwKT+lPKRYwAkP/0b2PRsnC0ppCWOBg7Y2r7pO
> TIH/w8J+BXCfJqkr9mnj9dHpTdb9XM824NTWaQaIc4fbyUtreDoTp9zPBi0+/n/v
> RPTNuEmbPpvCa/imhs0VfOBTTslC9Il22tF9CxqvtzqtSEFyiS1Npdvyxl8zy/rJ
> heksVx3nKX6oaZTsdJ8taWpRAcm2ZCwmacEzHYFpgLZ2ml56Kgds+Q5K+PpPS9jH
> ydg5jNoDCzUqs7cMcW5uRCdnUbEFLS2P0ON6c8l263glhI/D68ljd6eL7He8J8RQ
> lp5vZ70jktp9gS8K2Nz0qSpHkI7HhgvKUFO/gG33lvcAAWtmZPkOS5xEe7lCNLzQ
> RuBwMMmgY7nvtXkeSeJVX/YH1kQkIUwiIv84K9O4c9jjIZHTR4VU4jCRiSQAQaR8
> tlQgZ9dNJAlfXE5FtYYZsCJ3lMg6meWNJkqP3XZtqVPfX3A2K1o+phAvcSCLEFpz
> Hy/dcnhTYQyfvovex982zPavj7Q9Ou+KXLw6UZRGhCmqxMA8VATyHNlUmD2zomnl
> 6IveC51hmt36HAwYk9QWZPGeLt8BucCnTkfkSpPU0igzfHXMiSjoZLdTw5RemVDx
> aLo5a+4ii/t6rJeYfuIGtYRZFNYnu8/tuOEdGjNygY4qKKDwHP9dkBhDaRs4AU6K
> ClFG16OUDuEqTGkGiA9f
> =Auy4
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Regards,
Simon

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


Mime
View raw message