NAT'd IP's Re: [Seaside] Seaside session stealing

Sebastian Sastre ssastre at
Wed Apr 22 00:55:11 UTC 2009

you may found interesting to check this:


De: seaside-bounces at
[mailto:seaside-bounces at] En nombre de Nevin Pratt
Enviado el: Tuesday, April 21, 2009 21:50
Para: Seaside - general discussion
Asunto: NAT'd IP's Re: [Seaside] Seaside session stealing

Sorry to follow up to my own post, but obviously a simple IP check doesn't work
for multiple users behind the same router, whose IP got NAT'd to all be the same

So, I'm still thinking a combination of a "remember me" cookie, and an IP check,
is still needed.  But I accidentally reversed their order in my post below.
Here it is again, in proper order:

1. Check for a "remember me" cookie.  If a proper "remember me" cookie exists,
then the session is NOT stolen.

2. If we don't get a proper "remember me" cookie back from the user, then check
to see if cookies are enabled in the user's browser.  If they are not even
enabled, then default to an IP check-- if the IP is the same, consider that the
session is NOT stolen.

3. If the above two checks fail, then assume the session is stolen.

The hole in the above, though, is users whose IP is being NAT'd, *and* have
cookies turned off, could hijack sessions between each other.  But, for
non-banking, non-financial data, this is probably secure enough, and lets the
website reach the widest audience, whether they have cookies enabled or not.

At least, that's my thought.


Hi everyone,

Seaside sessions can be "stolen" with something as simple as user's sharing a
URL (one person emailing a URL to another person, for example).  There are
various ways to guard against this problem.  This email is a discussion of some
of those ways.

The obvious (non)solution is to configure Seaside to use cookies for the session
data.  The reason I say it is a *non*-solution is because users cannot have more
than one window open to your website with this method, because the cookie is
shared with all windows of the browser.  Also, some users have browser cookies
turned off, thereby cutting off all access to a Seaside website that is using
session cookies.

Another idea is to look at the IP of the user.  But, at one time, AOL users
(using AOL's proxy servers) would often have their IP changed with (potentially)
*every* request, thus making it completely unpractical to rely on the user's IP.

However, in late 2006, AOL agreed to send X-Forwarded-For headers, which now are
supposed to accurately identify AOL users' home IP addresses.  Here is a
Wikipedia reference for more information on this:

With this change in AOL, I am thinking that *maybe* it is now practical to guard
against Seaside session stealing via simple IP checks, with something like the
following code:

   | currentAccessIP |
    currentAccessIP :=  self session currentRequest nativeRequest  
                                         headerAt: 'x-forwarded-for'
                                         ifAbsent: [].
    currentAccessIP ~= lastClientAccessIP ifTrue: ["the Seaside session has been

(obviously "lastClientAccessIP" would have had to have already been set, via the
user's very first hit to the website)

But I'm not sure if this would be sufficient.  That's my question to everyone--
do you think IP checks can now be relied upon to guard against session stealing,
or not?

I've looked at some PHP code that approached the session-stealing problem with a
simple "remember me" cookie.  The "remember me" cookie is uniquely set when the
user first starts interacting with the website, and then if a subsequent request
does not have the cookie, the session is deemed to have been stolen.  But,
obviously this approach does not work for users that turn cookies off.

Another approach I've wondered about (and seems quite secure) is the following:

1. Use an IP check-- if the IP is the same, the session is NOT stolen.

2. If the IP is different, then check for a "remember me" cookie.  If a proper
"remember me" cookie exists, then the session is NOT stolen.

3. If the above two checks fail, then assume the session is stolen.

But I'm not sure if something that elaborate is really needed any more.  I'm
thinking that possibly a simple IP check will suffice these days.  But I'm
scared to try only doing an IP check, and nothing else :-) :-)

Does anybody else have any thoughts on this?





seaside mailing list

seaside at


-------------- next part --------------
An HTML attachment was scrubbed...

More information about the seaside mailing list