Menu
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)
838
If a cookie is exchanged via HTTP, then it's vulnerable to MITM attacks and session hijacking. To overcome the issue, we can use HTTPS when issuing the cookie and add the Secure flag to it. This instructs browsers to never send the cookie in plain HTTP requests.
Session cookies store information about a user session after the user logs in to an application. This information is very sensitive, since an attacker can use a session cookie to impersonate the victim (see more about Session Hijacking). You can configure an OutSystems environment to have secure session cookies.
Cookies are client-side files on a local computer that hold user information. Sessions are server-side files that contain user data. Cookies end on the lifetime set by the user. When the user quits the browser or logs out of the programmed, the session is over. It can only store a certain amount of info.
Sessions are more secure than cookies, since they're normally protected by some kind of server-side security. This does not make them infallible, however.
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:
127
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).
36
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
