[End User]

I've been working with a friend on a web application and have a question about PHP sessions. Here's a little background:

His login system is session-based and doesn't use any explicit cookie-handling code; that is, whatever cookies are used are strictly the result of the PHP session handler. His app doesn't set or check any cookies anywhere.

He told me today that a user emailed him reporting that he could see other people's entries in his account, specifically in a "daily journal" page. I looked at the SQL that pulls the user's entries and I didn't see anything wrong with it, it looks pretty standard. Here's a sample:

$journalquery = "SELECT * FROM journal
WHERE user_id='$account_id'
ORDER BY journal_date DESC";

Pretty basic stuff, and I see no obvious way to go wrong. The "$account_id" is pulled from a session and matched to a column in the 'journal' table. The query is very straightforward, so I don't see how one user_id could be accessing another user_id, unless somehow the "$account_id" that's being pulled from the session is somehow getting mixed up or substituted.

As I said, the only cookies generated that might be used for the session are done by PHP itself, he's got nothing that sets a cookie or assigns values to a cookie, nothing like that, he's using just the native (automatic) PHP cookie handling that's used to maintain a session.

So, here's what I'm wondering: if his client is at a large company that's funneling all of the users through a single IP, and *another* user there happened to be logged into the same application (but under a different user_id), could the session(s) be getting mixed up, or somehow 'seeing' them both as the same user because the IPs are the same? Is this possible, or should I be looking somewhere else?

If this sounds like the cause, what's the best fix? Add some cookie handling code, or regen the sessions, or....? I'm not all that familiar with cookies and PHP...how much work would it be to add code to make a unique cookie for an existing login system that doesn't already have it?

[wirehopper]

Session ids aren't guarenteed to be unique. If it's a real busy server, the site has been up for a long time, and it's and real busy site, it's possible that people's session ids are duplicated.

It might be good to try using a session variable that has a hashed/encrypted/md5 version of the account id. When the person arrives at the site, it can get $account_id perform the same conversion and test for a match. If it's not a match, destroy the session.

[End User]

Originally Posted by wirehopper

Session ids aren't guarenteed to be unique. If it's a real busy server, the site has been up for a long time, and it's and real busy site, it's possible that people's session ids are duplicated.

It's not a very busy server, not a lot of traffic overall. I'm not sure what to think at this point.

[wirehopper]

Ideas:

Check the size of the account_id field against the size of the session id.
Look around in the database, searching for patterns (many of the same account_ids, etc).
It's also possible that the user last used a publicly accessible computer and that someone posted on his account.
What happens if someone has disabled cookies?

I think the best fix is to find a unique identifier (other than session id) for each user, and use that to control access.

Interesting page: PHP 101 (part 10): A Session In The Cookie Jar

[End User]

Originally Posted by wirehopper

Ideas:
Check the size of the account_id field against the size of the session id.
Look around in the database, searching for patterns (many of the same account_ids, etc).
It's also possible that the user last used a publicly accessible computer and that someone posted on his account.
What happens if someone has disabled cookies?

I think the best fix is to find a unique identifier (other than session id) for each user, and use that to control access.

1) Hmmm, I'm not sure what checking the id size against the session id would do...could you elaborate?

2) All of the users have unique IDs (this is one of the first things I speculated about).

3) The user says he was on his own PC at work, so I don't think it was another user posting from his account. If he did, the data would still be there. After logging out and back in, the extra entries were gone.

4) If someone disables cookies, PHP automatically appends the SID to the end of the URL (and in some cases also rewrites the form HTML, from what I understand).

[wirehopper]

I may have misunderstood the issue. I thought the account_id was the session id, that's why I suggested checking the size of the fields. If not - then it's not relevant.

[Jcbones]

Pretty basic stuff, and I see no obvious way to go wrong. The "$account_id" is pulled from a session and matched to a column in the 'journal' table. The query is very straightforward, so I don't see how one user_id could be accessing another user_id, unless somehow the "$account_id" that's being pulled from the session is somehow getting mixed up or substituted.

I'm probably gonna sound stupid (The only thing I'm good at. ), But, did the user see both journal entries? AS in theirs and another person's? The reason I ask is that if you are pulling by an account number, and seeing entries from more than one account, then either the INSERT statement is hosed, OR MySQL took a dump on ya. Probably not gonna be in the session's though.

[wirehopper]

Is the data stored in session files on the server, or in cookies on the clients?

How often are the session files cleared?

What's the lifetime of the cookies?

[Jcbones]

As I said, the only cookies generated that might be used for the session are done by PHP itself, he's got nothing that sets a cookie or assigns values to a cookie, nothing like that, he's using just the native (automatic) PHP cookie handling that's used to maintain a session.

Server Side storage.

[wirehopper]

Last idea - leading zeros that are getting lost for account_ids?

Good luck.