[documentation] Fwd: [Drupal bug] Cannot stay logged in on more
than one site on the same server
Karoly Negyesi
karoly at negyesi.net
Thu Mar 30 08:56:49 UTC 2006
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
More information about the documentation
mailing list