NAT'd IP's Re: [Seaside] Seaside session stealing
nevin at bountifulbaby.com
Wed Apr 22 00:49:30 UTC 2009
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 IP.
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 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 stolen"].
> (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
> 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 lists.squeakfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the seaside