Re: [Phpwiki-talk] Security problem in PHPWiki sessions

[Reini U. <ru...@x-...>]

Matthew Palmer schrieb:
> I've just had a bug reported against the Debian version of PHPWiki, whereby
> multiple wikis on the same site share a common session, and so logging into
> one site can possibly give you elevated privileges on another wiki on the
> same website.  The original bug report is available at
> http://bugs.debian.org/282565.

Imho we don't need a new SESSION_PREFIX constant.
Normally you would change the session.name and session.save_path on the 
php side.
Since phpwiki just uses php sessions I wouldn't try to fix it at our 
side, when it's simplier done on the php level.
This problem is common for all shared hosts environments, with common 
SID and save_path.

We already support the user specific COOKIE_DOMAIN and SESSION_SAVE_PATH 
vars, which would seperate between different wiki's on the same host.
The shared WIKI_ID on mult. wiki's on the same host is on purpose.
This is just the username, not the authlevel.

But when it comes to our DbSession storage, it is true that better we 
should fix it. I'll investigate for this case.
How to seperate?
Both vhost and WIKI_NAME seems easiest and appropriate to me.

> While the report was against 1.3.7, and I've not had a chance to verify
> whether the problem still exists against 1.3.10, I've looked through
> the CVS logs for lib/Request.php, and can't find any commits which appear to
> fix the problem.

There's a new cookie policy in effect since 2004/04/02:
WIKI_ID is explictly shared, old-style cookies are converted.
Possibly shared cookies with empty "/" path are deleted also on logout.
prefs are not carried in cookies anymore, only the sid and username.

> I intend to work up some test cases for this problem to verify the problem,
> and try and get a solid fix for the problem, but it's a trickier problem
> than it appear at first.  The bug reporter suggested including the WikiName
> in the Cookie/SID variable name, but that won't work if you've got multiple
> wikis with the same name.  Similarly, restricting the cookie to a particular
> path won't necessarily help, as I've got several wikis running in the same
> directory with different filenames.

php folks added a better session hash method lately because of similar 
reports, but I doubt that a clash will ever happen, that a random md5 
will ever be same. I'd like to see the maths.
The evil scenario is more likely that someone steals the hash somehow, 
and then a better hash wouldn't help.

> The safest fix I've come up with is to store a hash of the main script file
> (or config file, perhaps) in the session, check it on startup, and
> invalidate the session if the hash doesn't match.  It's a wank, though,
> because it'll be slow as shit, and not cover various corner cases.  I
> welcome the suggestions of people with more knowledge of these things than
> me, though.
-- 
I believe that if it were left to artists to choose their own labels, 
most would choose none. (Ben Shahn)