Seaside session stealing

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:

   http://en.wikipedia.org/wiki/Wikipedia:AOL

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 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?

Nevin

               



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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.

Nevin

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:

   http://en.wikipedia.org/wiki/Wikipedia:AOL

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 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?

Nevin

               

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
  

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

---

De: [hidden email] [mailto:[hidden email]] 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 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.

Nevin

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:

   http://en.wikipedia.org/wiki/Wikipedia:AOL

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 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?

Nevin

               

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
  

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>>>>> "Nevin" == Nevin Pratt <[hidden email]> writes:

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

Please don't make the mistake of presuming "ip == user".

You've already identified the case (behind a NAT) where many users share the
same IP, but consider also the "walled garden" of AOL users, where the same
user can come in from different IPs during a single session.

You must allow for that.

In general, IP-based checks are broken.  Don't rely on them.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Are you sure we still have to allow for that?  AOL made changes in late
2006:

      http://en.wikipedia.org/wiki/Wikipedia:AOL

But, it really doesn't matter if AOL "walled gardens" are still a
problem or not, because the NAT problem is still there.  So, doing a
simple IP check is still a problem anyway.

Nevin
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

If one can sniff the TCP traffic between server and user, there is no
difference how you pass a session id - using cookies or unique URL -
because both can be extracted from packets.
I think that except SSL, there is no really secure solution.


2009/4/22 Nevin Pratt <[hidden email]>:


--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Yes, but sometimes there's a "good enough" solution.  It depends on your security needs.

On my Seaside site, all that a security breach reveals is the postal address of the person that got "breached".  No financial data is compromised.  And, if a person is sophisticated enough to sniff the packets, they are sophisticated enough to discover a person's postal address some other way anyway (for example, by looking through a local phone book).

I don't know that SSL is needed for such a small security issue.

But, if a normal user shares a URL with another normal user, it might upset them to see the address of the first person on the website due to a session hijacking.

So, I just need to detect these simple cases, and handle it gracefully.

Nevin

If one can sniff the TCP traffic between server and user, there is no
difference how you pass a session id - using cookies or unique URL -
because both can be extracted from packets.
I think that except SSL, there is no really secure solution.


2009/4/22 Nevin Pratt [hidden email]:
  

Please don't make the mistake of presuming "ip == user".

You've already identified the case (behind a NAT) where many users share
the
same IP, but consider also the "walled garden" of AOL users, where the
same
user can come in from different IPs during a single session.

You must allow for that.


      

Are you sure we still have to allow for that?  AOL made changes in late
2006:

    http://en.wikipedia.org/wiki/Wikipedia:AOL

But, it really doesn't matter if AOL "walled gardens" are still a problem or
not, because the NAT problem is still there.  So, doing a simple IP check is
still a problem anyway.

Nevin
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

    

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

WASessionProtector + Cookies + SSL? We recently passed a strict audit which deemed this solution to be just that, "good enough". There are no perfectly secure applications out there.

-Boris (via BlackBerry)

---

From: [hidden email]
To: Seaside - general discussion
Sent: Tue Apr 21 20:58:54 2009
Subject: Re: NAT'd IP's Re: [Seaside] Seaside session stealing

Yes, but sometimes there's a "good enough" solution.  It depends on your security needs.

On my Seaside site, all that a security breach reveals is the postal address of the person that got "breached".  No financial data is compromised.  And, if a person is sophisticated enough to sniff the packets, they are sophisticated enough to discover a person's postal address some other way anyway (for example, by looking through a local phone book).

I don't know that SSL is needed for such a small security issue.

But, if a normal user shares a URL with another normal user, it might upset them to see the address of the first person on the website due to a session hijacking.

So, I just need to detect these simple cases, and handle it gracefully.

Nevin

If one can sniff the TCP traffic between server and user, there is no
difference how you pass a session id - using cookies or unique URL -
because both can be extracted from packets.
I think that except SSL, there is no really secure solution.


2009/4/22 Nevin Pratt [hidden email]:
  

Please don't make the mistake of presuming "ip == user".

You've already identified the case (behind a NAT) where many users share
the
same IP, but consider also the "walled garden" of AOL users, where the
same
user can come in from different IPs during a single session.

You must allow for that.


      

Are you sure we still have to allow for that?  AOL made changes in late
2006:

    http://en.wikipedia.org/wiki/Wikipedia:AOL

But, it really doesn't matter if AOL "walled gardens" are still a problem or
not, because the NAT problem is still there.  So, doing a simple IP check is
still a problem anyway.

Nevin
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

    

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2009/4/22 Nevin Pratt <[hidden email]>:
If you care about such issues, as you obviously do, use SSL.

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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

Code like this was one of my first contributions to Seaside. Have a
look at WASessionProtector. As its says in the class comment this
trick does not work for a group of people that share the same external
IP, as this is often the case in companies or universities.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside