10

The issue I'm having, which may not be solvable, is as follows:

I have a client that is a large organization of 1,500+ users at 7-8 different locations. The application is a PHP application build on the Kohana v3.0 framework. The organization sits behind a proxy filtering server at the ISP level. Each location has one main public IP address that funnels through the proxy then to the web. Each user has a Mac or Windows workstation issued by the employer.

What they are experiencing appears to be cookie collisions. Example: One user logs in at their workstation then another user logs in from the same location, different workstation, with the same OS and browser type. The second user receives the first users' active session by receiving a newly generated cookie (token) that matches the first user. This appears to only be related to the 'authautologin' cookie (set when the remember me check-box is engaged on the login screen), but I'm keeping my options open to caching from the proxy (I can't prove that the proxy is caching yet).

Because of the network setup, the server sees hundreds of users logging in from the same IP address with the same user agent. My initial thought is that the Kohana v3's way of generating cookies that are unique to the browser (user agent) is not unique enough for this real-world application.

Has anyone ever experienced anything like this? And what would be the proper actions to take in cookie and session generation? Would managing cookies and active sessions in the database be better?

  • Kohana Modules: Jelly-Auth, Jelly, and Auth

  • Server: Apache/2.2.9 (Debian) mod_fastcgi/2.4.6 mod_jk/1.2.26 PHP/5.2.6-1+lenny8 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g

  • Known Browsers: IE 8 & 9, Firefox (OS and Win), and Safari (OS)

hakre
  • 193,403
  • 52
  • 435
  • 836
norris-md
  • 306
  • 2
  • 10
  • +1: Carefully asked question - with good detail available. Well done. – Jonathan Leffler Dec 19 '11 at 16:15
  • I agree, but isn't this a problem with the proxy that would apply to any service that uses an auto-login cookie? – Pekka Dec 19 '11 at 16:17
  • @Pekka that has been my thought/frustration for the last week. Then after asking their in-house IT staff, I learned that the purpose of the proxy filter was to block sites like GMail, Facebook, Twitter, etc... So I am lead to believe that they do not have access to sites outside the network where they login. This application may very well be the only one were they can be issued an auto-login cookie that is outside the network. – norris-md Dec 19 '11 at 16:29

3 Answers3

2

Wow thats a nasty vulnerability, good catch!

By far the best way to generate cookies under PHP is to let PHP do it: session_start(). And thats all! If you are generating your own cookie, then you really messed up somewhere. Now you can use the $_SESSION[] super global. The best practice is to call session_start() in a common header file before you access $_SESSION in your application.

There are probably other problems you should take into consideration such as owasp a9, csrf, and the cookie flags: HTTP_Only, and the "secure" flag (forcing the cookie over https).

rook
  • 66,304
  • 38
  • 162
  • 239
  • @Rock thanks! I've dug through the code a couple of times and can verify that yes I am utilizing PHP to manage sessions (session_start(), session_name(), session_set_cookie_params(), session_destroy(), etc...). But just because you mentioned it I'll go digging again, double check, and give credit where credit is do when I come up for air. It is an SSL site and the secure and HTTP_ONLY flags are set. – norris-md Dec 19 '11 at 16:59
  • Sorry @Rook didn't mean to f-up your name there. – norris-md Dec 19 '11 at 17:10
  • @ixasilent You should never need to set a cookie value. I think you are relying upon the kohana_cookie class for identifying a user. This is using setcookie(), which is evil. – rook Dec 19 '11 at 17:50
  • are you referring to [this](http://php.tonnikala.org/manual/en/function.setcookie.php#81398) method as an alternative to setcookie()? – norris-md Dec 19 '11 at 18:45
2

It's just an idea but there is / used to be (depending on your Debian and PHP version) a bug with PHP sessions. What I suggest you to try:

  1. Check this link - this may not be related to your problem but it's worth a try
  2. Switch to database driver - I'd give 90% chance that this will fix everything
  3. Test on different then Debian server - this may not be easy to accomplish though
matino
  • 17,199
  • 8
  • 49
  • 58
  • I don't think that the link is applicable, but duly noted for future reference. The application uses MySQL PDO through the Kohana 3.0 Database and Jelly modules. Any other drivers in mind? There are about 15 other sites that are identical (- the database content) on this server for other clients that do not report this issue, so I'm pretty sure that it has to do with the network make-up and the need to fine tune Cookie generation for this one site. Good link! I'll bookmark it, cause it might address a session timeout issue with a wiki that has been on my back burner for a month. – norris-md Dec 19 '11 at 18:54
  • I meant switch to session database driver, not give up PDO/Jelly if that's what you thought ;) – matino Dec 19 '11 at 18:59
  • you are right storing the session in the database fixes this. To be honest I am not happy with this solution, but will enjoy it as a hack for now. Of course when thousands of users start to use the application again and I end up looking like a fool... I'll be back! Just to be safe I will rewrite the kohana_cookie class' set method to be RFC 2109 compatible. That's at least the responsible thing to do. Thanks! – norris-md Dec 19 '11 at 19:40
0

I'm not sure if I understood you correctly, but... I understood that request goes like this:

user (workstation) ==> proxy () ==> internet ==> company website (and response in reverse direction).

Check if proxy sets "HTTP_X_FORWARDED_FOR" (in $_SERVER superglobal variable). It could be the only way to determine user's workstation IP address. If so, you're done.

Andrzej Bort
  • 21
  • 1