2

On one of my sites, I have ini_set('session.use_trans_sid', 1) set which allows users with no Cookies to use the site. It does this be keeping track of the Session via the URL.

However, I'm experiencing a serious security issue that is allowing Sessions to be easily hijacked.

Basically, Google is indexing pages with the Session ID it was given at the time of its Crawl since the Googlebot does not use Cookies.

Then, when someone searches for my site and then clicks the search result in Google that includes the old Session URL, that old Session ID now becomes their Session ID (rather than a new one being generated).

So then when that user logs in, their account is logged in using the Session ID indexed all over Google! That means any other users searching for our site and clicking one of the search results in Google gets automatically logged in to that other users account!

Talk about a massive security hole!

How can I fix this? I would have thought that PHP would recognize that a Session ID is no longer valid (or no longer exists) and then generate a new one, but it doesn't seem to be doing that. It seems like if it did do that, it would fix this issue.

Please help!

EDIT:

What is essentially happening here is that PHP is allowing anyone to create their own custom Session ID by simply entering whatever they want for the Session ID parameter in their URL, and PHP will start using that as their Session ID. I can literally make the Session ID = "securityflaw" in the URL and it will literally use that as the Session ID even after logging in! So when someone clicks a link on Google with the Googlebot's old Session ID, PHP is making the users "custom" Session ID be that. Surely something is amiss!

ProgrammerGirl
  • 3,157
  • 7
  • 45
  • 82
  • Isn't it that when someone follows a link to your site from a Google search results page, only the (dummy) session ID used by Google temporary at the time of crawling gets exposed so none of user accounts actually gets compromised? – Desmond Hume Dec 01 '12 at 18:24
  • @DesmondHume: Yes, but then if someone logs in using the Session ID from Google, then that becomes their active and logged-in Session ID, which means that anyone else who clicks a link on Google, will be logged in to that person's account since they will have the same Session ID in their URL! – ProgrammerGirl Dec 01 '12 at 18:27
  • Bind the session to the IP? – kittycat Dec 01 '12 at 18:31
  • So it means that when a user closes the tab with your site just for a few minutes, the session is lost? Well I dunno what site it is but this is a BAD user experience for one thing.. – Desmond Hume Dec 01 '12 at 18:32
  • @cryptic: Surely there is a better way built-in to PHP? I can't fathom this being the default behavior in PHP as it's a massive security flaw. – ProgrammerGirl Dec 01 '12 at 18:33
  • session.use_trans_sid is known to be insecure, just as many other things in PHP are, but are recommended against being used. – kittycat Dec 01 '12 at 18:34
  • @DesmondHume: For users without Cookies, a URL-based Session ID is their only option. So I agree it's "bad", but it's better than "nothing". That said, I need to find a way to fix this urgently without having to limit the site to users with Cookies. – ProgrammerGirl Dec 01 '12 at 18:35
  • Btw session.use_trans_sid on is not default behavior. It was changed to off by default long ago due to the security issues associated with in. – kittycat Dec 01 '12 at 18:37
  • @cryptic: Are you saying that the default behavior of PHP when `session.use_trans_sid` is enabled is to allow anyone to create a custom Session ID? Because that's precisely what's happening here. I can literally make the Session ID "securityflaw" in the URL and it will literally use that as the Session ID! Surely something is amiss! – ProgrammerGirl Dec 01 '12 at 18:38
  • Yeah, but that is why no one is suppose to use it for managing account sessions. Now to store prefs like search queries, etc it is safe to use, but you are never to use it for account sessions. – kittycat Dec 01 '12 at 18:41
  • @cryptic: So you are 100% sure this is the default behavior? Please confirm. If what you say is true, then how is PHP meant to handle users with no cookies? – ProgrammerGirl Dec 01 '12 at 18:42
  • Your best option is to use http://us1.php.net/manual/en/function.session-set-save-handler.php and have the session binded to the IP if you want to continue using this insecure method for user friendliness. – kittycat Dec 01 '12 at 18:42
  • http://php.net/manual/en/session.security.php its documented behavior, nothing is amiss. It's the developers responsibility to have good judgment and choose the correct session method they need for the task which adequately protects what the are creating a session for. – kittycat Dec 01 '12 at 18:47
  • @cryptic: Thanks, but there is a problem with your solution, as per your link: "In addition to ip-address binding not always being effective, it can also prevent users connecting through a proxy-pool from even being able to use your site." Surely, allowing the user to set their own Session ID cannot be right, so I still need to get to the root of the issue that's permitting that. – ProgrammerGirl Dec 01 '12 at 18:52
  • You are aware, if the user modifies their cookie value as well they can set their own session as well? User supplied data is untrusted, this is the case for any language, any site that uses session cookies. – kittycat Dec 01 '12 at 18:55

1 Answers1

2

You should look into http://php.net/manual/en/function.session-regenerate-id.php to regenerate the SID when user logs in so any SID in Google searches will become invalid if they used it to login with.

kittycat
  • 14,983
  • 9
  • 55
  • 80
  • Thanks, this looks more like what I need. Generally speaking, will this affect users using Cookies and the "Remember me" feature ? – ProgrammerGirl Dec 01 '12 at 20:56
  • @Programmer session_regenerate_id should have no effect on cookie sessions, since PHP keeps track of what data is bound to what session ID and automatically updates it when you regenerate the id. – Joe Malt Dec 01 '12 at 22:51
  • @yttriuszzerbus read the doc, the function will create a new session id with the session data copied over, and old session id will no longer be available thus making any indexed session ids by Google invalid as long as the 2nd parameter is set to TRUE the old session file will be removed so any cookies or links pointing to that will not be associated with old session data. – kittycat Dec 02 '12 at 05:51
  • @cryptic: I'm confused, so in general, will enabling session_regenerate_id() affect users using Cookies and the "Remember me" feature ? For example, will the "Remember me" feature stop working because a new Session ID/Cookie was generated? If so, how can I work around this so that I can secure non-Cookie users while not affecting Cookie users? Thanks. – ProgrammerGirl Dec 02 '12 at 18:18
  • PHP will determine the current session id sent by user, replace the id associated with the session id with a new one, invalidating the old one, but also send new id to user. So it should affect remember me. Remember me is usually just a cookie that does not expire or get deleted when browser is closed. So that same cookie will be used to determine current id by PHP to be changed. You can always test if in doubt. – kittycat Dec 02 '12 at 18:34
  • @cryptic: I'm still confused, you seem to suggest it will NOT affect "Remember me", but you actually said "So it **should** affect remember me". Which one is it? Thanks in advance for clarifying. – ProgrammerGirl Dec 02 '12 at 20:41
  • @cryptic: Thanks for confirming. Answer accepted! Thanks again for all your help, this is **exactly** the solution I was looking for. :) – ProgrammerGirl Dec 02 '12 at 21:13