[documentation] Fwd: [Drupal bug] Cannot stay logged in on morethan one site on the same server

[Steven Peck]

Well, that looks like an all day writing spree

-sp 

-----Original Message-----
From: documentation-bounces at drupal.org
[mailto:documentation-bounces at drupal.org] On Behalf Of Karoly Negyesi
Sent: Thursday, March 30, 2006 12:57 AM
To: documentation at drupal.org
Subject: [documentation] Fwd: [Drupal bug] Cannot stay logged in on
morethan one site on the same server

I am forwarding you the relevant part of http://drupal.org/node/56357 .

Please make a handbook page out of it. It's very important for anyone
who is trying to run a multisite with 4.6.6/4.7.

------------------------------------------------------------------------

Wed, 29 Mar 2006 13:09:44 +0000 : markus_petrux

Maybe you could try to set a different session.name [1] for each site in
its own settings.php file. Something like this:
ini_set('session.name', 'PHPSESSID');
where PHPSESSID is the default, but you could use something unique for
each site.


Otherwise, cookies visible from different sites will get overridden, if
not correctly protected by browser security settings. You could also
tweak this by setting different cookie domain/paths with (for
configuration 3 above) something like:
ini_set('session.cookie_domain', '.example.com');
ini_set('session.cookie_path', '/sub1');
ini_set('session.cookie_domain', '.example.com');
ini_set('session.cookie_path', '/sub2/sub21);
ini_set('session.cookie_domain', '.example.com');
ini_set('session.cookie_path', '/sub2/sub22'); Maybe something like that
would work, but then, it may fail for users who doesn't have cokkies
correctly secured in their browser settings.
[1] http://www.php.net/manual/en/ref.session.php#ini.session.name




------------------------------------------------------------------------

Wed, 29 Mar 2006 14:54:27 +0000 : Zen

Markus + fgm,


   Thanks for your input. Can someone please explain why the
session_regeneration creates this issue in the first place ? Could this
perhaps be fixed there? chx noted that the downside of the above patch
could be that admin sessions might be affected during the upcoming
upgrade..


Thanks
-K




------------------------------------------------------------------------

Wed, 29 Mar 2006 15:00:17 +0000 : moshe weitzman

what most people want is to share their session cookie across sites. i
think markus code makes each site distinct. if thats what you want, then
no problem.




------------------------------------------------------------------------

Wed, 29 Mar 2006 17:34:58 +0000 : markus_petrux

Why worked? Well, we need to see what session fixation is (I'll try be
short as possible).


Session fixation is a vulnerability that allows anyone to fix anything
for the session id, and PHP will just use that until it expires (the
attcker could take care of keeping the session alive by generating
requests at intervals). If you followed a link of the form
http://example.com?PHPSESSID=vivalavida, PHP would just use that and
when you log in, PHP would still use that session id, now logged in. So
the attacker (the one who managed to make you follow that link) could
then use that session id to impersonate you. Now, if you are the site
admin, the attacker could do anything, even execute PHP code, read your
database password, etc.etc.etc. more references [2]


Before chx's session regeneration fix, Drupal had no defense against a
session fixation attack. Hence, what was happening is that the first
session opened on a Drupal site generated a session id, stored in the
browser's cookies. That session id, was reused when the user visited the
other sites. Let's say, Drupal let you deploying a session fixation
attack.


Now, the session id is regenerated everytime the user logs in. That is,
the session id changes and it is updated in the corresponding cookie,
the same one that has been shared between several sites. The problem now
is that that session id is only known to the database of the site where
it was created. When the other sites read that cookie, get a value (a
MD5 hash) that is probably unknown to them (different sessions
database), hence they see that user as a guest.


No problem, if you try the tips above you can make each site look for
its own cookie (the session.name value is the name of the cookie,
PHPSESSID by default). Even if those cookies are visible from different
sites, each will look at its own. Such a configuration, of course, opens
a door to a possible attack, 'cause you could read from one site the
other cookies, so you could get access to the other sites. That would be
a session hijacking attack. So it would be best to correctly set the
other session.cookie parameters, to take advantage of the browser
security zones.
[2] http://drupal.org/node/19845#comment-81050


--
Pending work: http://drupal.org/project/issues/documentation/
List archives: http://lists.drupal.org/pipermail/documentation/