[Helma-dev] session cookie security revisited

[Hannes Wallnoefer]

Update: Since yesterday evening, I'm testing a Helma snapshot on 
antville.org that uses the first 3 octets of the remote IP address in 
the session cookie, plus the first 3 octets of the original client 
address if it is available in a proxy request.

This has solved the problems with the chello/univie proxy while making 
it even slightly more secure: It's not enough to share the same proxy 
anymore to use a stolen session cookie, but you also have to be on the 
same class C network. While it's easy to fake the X-Forwarded-For or 
Client-ip headers per se (from which the originating client address is 
taken), it shouldn't be easy to fake them when going through the proxy 
which generates them.

The problem with dienste.wien.at still persist. I'm still looking for 
ways to get that fixed.

Hannes

Hannes Wallnoefer wrote:

> As you may know I received some complaints of users unable to log int 
> to antville.org. Some further digging 
> <http://project.antville.org/stories/412775/> made clear that (as 
> expected) most of them are related to the inclusion of the client IP 
> address in the HopSession cookie.
>
> For example, UPC chello and the university of vienna have a proxy that 
> is split over multiple servers:
>
> Name:   tk-proxy.univie.ac.at
> Address: 131.130.1.143
> Name:   tk-proxy.univie.ac.at
> Address: 131.130.1.150
> Name:   tk-proxy.univie.ac.at
> Address: 131.130.1.135
>
> Or, people working at the magistrate of Vienna access the internet 
> through a number of gateways which often change during sessions:
>
> gate1.dienste.wien.at
> gate2.dienste.wien.at
> gate3.dienste.wien.at
> gate11.dienste.wien.at
>
> This means that Helma services are just not accessible for people with 
> this kind of setup, which is kind of unacceptlable.
>
> I'm currently pondering some counter-measures, but this is a complex 
> issue so I'm asking for your help.
>
> Session cookie security is obviously a big concern, not only for sites 
> like antville.org, but for all sites where cross-site-scripting issues 
> can't be completely ruled out. So getting rid of the IP address check 
> is not a solution.
>
> What might help is to get rid of the last byte of IP addresses, just 
> checking for the three class C subnet bytes (FF.FF.FF.00). This would 
> solve the problem cases listed above (except gate11.dienste.wien.at) 
> and still offer a similar level of security.
>
> As an addition, we might include some other HTTP headers in the 
> checksum which usually do not change during a session, e.g. 
> User-Agent, Accept, Accept-Encoding.
>
> Finally, for proxies we may consider looking for the originating 
> client's address, which is passed in the X-Forwarded-For or Client-ip 
> headers by most proxies. Although these are easy to fake, they might 
> make attacks yet a little harder. Here too it would be advisible to 
> drop the smallest byte, otherwise dial-up users or other people with 
> variable IP addresses might be affected.
>
> What does everybody think?
>
> H--
>
> _______________________________________________
> Helma-dev mailing list
> Helma-dev at helma.org
> http://grazia.helma.at/mailman/listinfo/helma-dev
>