URGENT: 0.9.2.6 and SessionID

MrNase

One very URGENT problem which should be fixed AS SOON AS POSSIBLE.. Some indexed sites of my community include the sessionID.. See here: http://www.google.de/search?q=moo.fx+ajaxtalk With this links visitors are LOGGED IN even if they are not registered!!

Minisweeper

that really is extremely wierd, but as far as i know there's nothing vanilla can do about it. There is nothing strange about the way vanilla uses sessions and to my knowledge it never explicitly passes the sessionid in the url (this is a failback for when cookies arent working, usually dependant on your server, i think). Whats even wierder is how the googlebot managed to get a sessionid anyway?

Mark

This has been discussed before, and it is a PHP configuration issue. PHP can be configured to NOT pass the session id in the url, and you should definitely set up your server to NOT do so.

Read the PHP documentation here:

The session module cannot guarantee that the information you store in a session is only viewed by the user who created the session. You need to take additional measures to actively protect the integrity of the session, depending on the value associated with it.

Assess the importance of the data carried by your sessions and deploy additional protections -- this usually comes at a price, reduced convenience for the user. For example, if you want to protect users from simple social engineering tactics, you need to enable session.use_only_cookies. In that case, cookies must be enabled unconditionally on the user side, or sessions will not work.

There are several ways to leak an existing session id to third parties. A leaked session id enables the third party to access all resources which are associated with a specific id. First, URLs carrying session ids. If you link to an external site, the URL including the session id might be stored in the external site's referrer logs. Second, a more active attacker might listen to your network traffic. If it is not encrypted, session ids will flow in plain text over the network. The solution here is to implement SSL on your server and make it mandatory for users.

php.net/session

For the record, Vanilla 0.9.3 has explicitly set the session.use_only_cookies to true. You can do so in vanilla 0.9.2.6 by adding the following line to your appg/headers.php file:

// DO NOT ALLOW PHP_SESS_ID TO BE PASSED IN THE QUERYSTRING ini_set("session.use_only_cookies", 1);

Mark

Also for the record, I don't see any links with session ids in those results.

Minisweeper

the top one has one, (when i did it atleast) mark. Though when i clicked it i wasnt logged in as anyone. I still dont see how the googlebot could have a sessionid?

dsan

my god if someone seriously thinks this is a problem with PHP then im worried, This HAS NOTHING to do with PHP, its a vulnerability in the way Vanilla parses the incoming GET request to ensure that: a: its a valid session ID b: the request is coming from the same IP which the session ID was generated (cookie is set mainly using IP+password and md5'd) If any of the above isnt valid, then the GET request should be denied and the user forced to a login page to reauthenticate. Secondly, no sessionID should be passed in the URL and should only be set using the cookie function. Why is vanilla not performing any session state checking? Why is it possible to inject valid ID's into the application and then have the application fully trust those ID's and execute them? Possible solution: On creation of the session, when the user logs in,save the user's ip address in the session.Vanilla should then check the ip address in the session with the user's current ip address, when this ip address isnt the same, the user is forced to the login page to re-authenticate and prove themselves to the application. Furthermore, the session that was active for the user should be torn down. Why cant vanilla do that? Code: if($_SESSION['ip'] != $_SERVER['REMOTE_ADDR']) { //delete session $_SESSION = array(); if (isset($_COOKIE[session_name()])) setcookie(session_name(), '', time()-42000, '/'); session_destroy(); } Lets not confuse whats the problem of PHP and whats down to lack of knowledge of web application security Daniel OWASP Guide to building secure web applications http://OWASP.org

Mark

I've always had an opposition to using IP addresses to validate users. IP addresses can be easily spoofed, and IP addresses change all the time - which can lead to people being signed out over and over again if this method is used.

I realize that this is a problem, and I had assumed that setting use_only_cookies was enough to handle the problem. I am willing to give the ip checking a go for a while. I'd really like to see if a lot of people get kicked out repeatedly as a result of it. I know that in the distant past this did happen - but maybe things have changed.

dsan

yes ip addresses can be spoofed, but remember that TCP is a three way handshake. If you do spoof the IP and still require some information to be sent back to you, how will it get to you? This is a big misconception of IP spoofing and unless the person has taken over the switch and done some arp poisoning, then its a mute point. Im more than happy to help as this is a common problem with all web applications and not just php

Mark

Well, I've changed the authentication class in this version of Vanilla to require matching session/current ip addresses as you suggested. The new code is active and live on this very version of vanilla and anyone can get the latest code from the svn. If you just want a visual peek at the code, check it out here: http://lussumo.com/svn/people/trunk/People.Class.Authenticator.php The "GetIdentity" and "AssignSessionUserID" methods are where your code is implemented.

lech

This probably still will not prevent the sessionID variable from appearing in the url, but should work nice in the long run towards preventing anyone attempting to exploit it.

Mark

For the record: Since I implemented that code one hour ago, I have had eleven people complain about being constantly logged out.

giginger

I'm one of them. I was in another thread, logged in fine, I was happy. Click to come into this one. I'm logged out. It's not too much bother as Firefox has filled my Username and Password in. The fact remains that this isn't a good solution right now.

dsan

Mark, Ill spend sometime on this tomorrow and whip up a better piece of code to resolve this issue, but its brilliant you've added the code already (better than microsoft who are still dragging their feet with a vulnerability i found 6 months ago)

dsan

Ok I decided to spend time doing it now, rather than later :0) the best way forward is for Vanilla to store the sessionID in the cookie and not the url. Now I know many people say that cookies arent meant for anything secure, and im one of those people who say this all the time, but its a case of managing risk at the same time. Yes cookies can be easily manipulated by the attacker, but by placing the sessionID in the cookie, your stopping the likes of GoogleBot from grabbing a valid sessionID transmitted by a harmless refer and then bypassing your logon function. So the flow should be something like this: 1st Stage: User visits Vanilla and enters their username/password and they are checked to ensure they are valid. Once this is the case, the application uses PHP builtin sessionID 2nd Stage: Vanilla verifies that the session is valid on each page being called using the GET/POST HTTP query. Yes the user logged in, but how does Vanilla know its actually the same person. The easiest way is to verify each request using something like this: function verify_session() { $username = $this->db->quote($_SESSION['username']);
$cookie = $this->db->quote($_SESSION['cookie']);
$session = $this->db->quote(session_id());
$ip = $this->db->quote($_SERVER['REMOTE_ADDR']); $sql = "SELECT * FROM member WHERE " .
"(username = $username) AND (cookie = $cookie) AND " .
"(session = $session) AND (ip = $ip)"; $result = $this->db->getRow($sql); if (is_object($result) ) {
$this->_setSession($result, false, false);
} else {
$this->_logout();
} } Simply having a piece of code within Vanilla which calls the verify_session each time allows for more secure sessions. The above piece of code would check the cookie to see if it contains the right sessionID, IP address of person who set logged in initially. Now with regards to the people who are using shared IP's and whatnot, I need to spend some more time looking at better methods, so yes for the meantime it may be a hassle (but would you rather login or have your account/server hijacked?) comments?

Bergamot

Well if it lets me log in, that's got to be better than what we have right now.

Mark

Okay, well, I have another idea for how to tackle it. I don't want to add another query to every page load. But I already do query the database for rudimentary user information, so I'm going to try to work it into that query somehow. In the meantime I've disabled the code from above so that people don't get kicked out all the time. Gotta go patch some holes in my appetite right now.

lech

Mark, I was logged out twice, but I sensed that a codebase was undergoing an update so I just went with it. Everything now is fine though.