Potential to hijack a logged-in user's session

[mjgardes]

Opened up chrome, like I normally do, typed in the URL to our CRM and was greeted with "Welcome, Platt, Edward L."

It appears to be fully logged in as someone else, with all of their permissions. Could the server have hit a session ID collision or something? Smells like a gaping security hole to me.

[elplatt]

How widespread is this problem? Does it happen every time? Can you reproduce it in other browsers or computers?

[mjgardes]

It has only happened to me once so far, but I don't access the CRM often.
I was wondering if this has happened to anyone else.
On Oct 24, 2014 11:19 AM, "Edward L Platt" notifications@github.com wrote:

How widespread is this problem? Does it happen every time? Can you
reproduce it in other browsers or computers?

—
Reply to this email directly or view it on GitHub
#338 (comment).

[mjgardes]

Looks like the CRM only checks the PHPSESSID cookie to auth users. Since we have other sites on the same domain name, there are many ways that someone may be able to stick code in the right place (for example this comment on our blog: http://i3.lc/425) to steal an unsuspecting user's cookies.
We ought to have some secondary check since it's well known that cookies can't be trusted.
I know an IP address check isn't perfect, but it would be better than nothing.

[NateLapT]

I have also randomly been logged in as Ed at one point. I don't have any data for how it happen. I'm pretty sure it was on my computer I use mostly for lan parties. At the time I figured I must have had the computer where Ed was some time in the past and he checked the crm on it and forgot to log out.

[elplatt]

This is obviously a serious bug. Can anyone think of a fix? Is there a
standard way to isolate php session variables between apps on the same
server?

On Fri, Dec 19, 2014 at 12:43 PM, NateLapT notifications@github.com wrote:

I have also randomly been logged in as Ed at one point. I don't have any
data for how it happen. I'm pretty sure it was on my computer I use mostly
for lan parties. At the time I figured I must have had the computer where
Ed was some time in the past and he checked the crm on it and forgot to log
out.

—
Reply to this email directly or view it on GitHub
#338 (comment).

Edward L. Platt
http://elplatt.com
http://civic.mit.edu/users/elplatt
http://i3detroit.com
@elplatt http://twitter.com/elplatt

This electronic mail message was sent from my desktop personal computer.
Please forgive any long-winded, overly-prosaic ramblings.

[mjgardes]

I've turned off access to the session cookie via javascript on our server, and I recommend others who use this cookie do the same. That will at least make it more difficult to get at the session ID.

[elplatt]

So is the problem that (possibly malicious) client-side code can set the
uid session variable to an arbitrary value? I didn't know js could modify
php session vars.

On Fri, Dec 19, 2014 at 1:04 PM, mjgardes notifications@github.com wrote:

I've turned off access to the session cookie via javascript on our server,
and I recommend others who use this cookie do the same. That will at least
make it more difficult to get at the session ID.

—
Reply to this email directly or view it on GitHub
#338 (comment).

Edward L. Platt
http://elplatt.com
http://civic.mit.edu/users/elplatt
http://i3detroit.com
@elplatt http://twitter.com/elplatt

This electronic mail message was sent from my desktop personal computer.
Please forgive any long-winded, overly-prosaic ramblings.

[mjgardes]

I think there are two closely related problems here. The most dangerous
thing is we trust clients to not mess with their cookies, even though it's
trivial to do, for example with a browser extension. JS anywhere on
i3detroit.org is just one of the ways an attacker might be able to get
their hands on a logged-in sesson variable.

The fact that multiple people have been "accidentally" logged in as cid 1
without even trying might be related. For now I want to have that account
not be so privileged so if it happens again they'll at least get a
read-only account.

On Fri, Dec 19, 2014 at 1:09 PM, Edward L Platt notifications@github.com
wrote:

So is the problem that (possibly malicious) client-side code can set the
uid session variable to an arbitrary value? I didn't know js could modify
php session vars.

On Fri, Dec 19, 2014 at 1:04 PM, mjgardes notifications@github.com
wrote:

I've turned off access to the session cookie via javascript on our
server,
and I recommend others who use this cookie do the same. That will at
least
make it more difficult to get at the session ID.

—
Reply to this email directly or view it on GitHub
#338 (comment).

Edward L. Platt
http://elplatt.com
http://civic.mit.edu/users/elplatt
http://i3detroit.com
@elplatt http://twitter.com/elplatt

This electronic mail message was sent from my desktop personal computer.
Please forgive any long-winded, overly-prosaic ramblings.

—
Reply to this email directly or view it on GitHub
#338 (comment).

[mjgardes]

Steps to reproduce:
Navigate to ...payment/ipn.php
observe the pretty blank page
Navigate to /crm/
You are now Ed.

[mjgardes]

The problem here seems to be some scripts trying to log out with $_SESSION['userId'] = 0;. Trouble is 0 is an actual user with all the permissions.

Traditionally, the nobody user is -1 or -2, but I don't know what that will break in the CRM.

[elplatt]

Admin user should be cid=1 and all others should be nonzero. This might be
an install-specific database inconsistency.

On Tue, Apr 14, 2015 at 12:07 PM, mjgardes notifications@github.com wrote:

The problem here seems to be some scripts trying to log out with
$_SESSION['userId'] = 0;. Trouble is 0 is an actual user with all the
permissions.

Traditionally, the nobody user is -1 or -2, but I don't know what that
will break in the CRM.

—
Reply to this email directly or view it on GitHub
#338 (comment).

Edward L. Platt
http://elplatt.com
http://civic.mit.edu/users/elplatt
http://i3detroit.com
@elplatt http://twitter.com/elplatt

This electronic mail message was sent from my desktop personal computer.
Please forgive any long-winded, overly-prosaic ramblings.