tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <>
Subject Re: CSRF on multiple tomcat instances
Date Wed, 07 Nov 2012 20:24:27 GMT
On 06/11/2012 03:59, Christopher Schultz wrote:
> Wilfred,
> On 11/5/12 4:08 AM, Wilfred Duizers wrote:
>> When a user clicks a link in the webapplication running on Tomcat 
>> instance 1 (portal) an application running on Tomcat instance 2 is 
>> opened. Is it possible to send the nonce with the link? Because
>> it's running another instance.....
>> Do you see a solution anyway....both tomcat instances use the same
>>  domain
>> They use isapi
> I'm not sure ISAPI is relevant, here, but good to know.
> So, first of all -- have you tried it? The CSRFPreventionFilter stores
> its nonce cache (a Serializable object) in the session. If you are
> using clustered sessions, then it should Just Work.

If they are not the same apps it won't.

The alternative is to write a similar component that works as a Valve,
which has access to the Session (not the same as the HttpSession) and
see if you can use the same mechanism as the SSOValve uses, storing the
nonce in a 'note'.

I *think* that might work, but I'm guessing a bit there...


> If you have other (as yet undisclosed) requirements, I'm guessing that
> Tomcat's built-in CSRFPreventionFilter isn't going to meet your needs,
> though it should be trivial to subclass it and customize the parts
> that you need to work differently. If your improvements are decent, I
> would encourage you to contribute back to the community.
> If I had to do this, I would look at modifying the existing
> CSRFPreventionFilter such that its storage mechanism was pluggable, so
> you could specify a class that did something simple like:
>    public LruCache<String> getNonceCache(HttpSession)
>    public void setNonceCache(HttpSession,LruCache)
> If you wanted to make it a bit more high-throughput, you could make
> the methods more fine-grained so you didn't have to push-and-pull the
> whole cache each time. The code is more complicated, but potentially
> more flexible.
> Once that's done, just implement a global nonce cache using something
> like webcache or your favorite key-value store (where the key is
> something like session id + ".csrfCache"). Just remember to expire the
> nonce caches when the user's session dies or you will end up with a
> big, fat, messy database (and might even exhaust system resources if
> you are using an in-memory solution like webcache).
> -chris
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



View raw message