ID: 28242
Comment by: xuefer at 21cn dot com
Reported By: php at ter dot dk
Status: Bogus
Bug Type: Session related
Operating System: Linux
PHP Version: 4.3.6
New Comment:
thinking this bug as bogus is M$ behavior.
just like win2k/xp Pro: make all users use administrator by default(low
secure), and say "hey you're using admin, it's dangerious!". but what's
the result? many and many users use admin, and lead to security
problem.
cross site caching/sessioning is already discussed in turck-mmcache,
and fixed.
and "cross site exception" is in the author's todo list.
adding a SERVER_NAME to the key/sessionid(only when read/write) should
easily solve the problem
session.allow_cross_site = 0 ; by default
session file-handler should be something like:
put_file_content($path . '/'
. (session.allow_cross_site ? urlencode($_SERVER['SERVER_NAME']) . ':'
: ''
. $sessionid, session_encode())
i don't see any BC problem unless some site is doing:
redirect example.com <-> www.example.com frequently
Previous Comments:
------------------------------------------------------------------------
[2004-07-01 11:00:29] [EMAIL PROTECTED]
i agree with Peter, because i had servers with virtual shared users,
but i think the problem resides in the security documentation.
The problems are a lot different when you have a virtual server,
because a lot of users run their different scripts, so its not as easy
as activating safe_mode if you want to secure it.
Should be created a different category in the Security chapter, to look
into all sensitive attributes in php.ini (like session.save_path,
disable_functions, etc.) that could cause problems to a virtual
server.
On the other side, the developers should be thought to add to their
session, variables like:
-users ip
-domain name
----
So, my proposal would still be, just as a solution to gain access to
other users' passwords at the same server using the same realm, to add
the UID of the script to the session-filename when in safe mode.
----
I dont see why only in safe mode.
>From my tests, i noticed that configuring php will not help you secure
your web server, there are things like permissions that i had some
problems. Like in a shared environment i could compromise sensitive
files with file manipulation functions (ex. fopen, read, etc), just
getting out of my /home/user/ dir. But i guess this is some kind of
another story.
Serban Gh. Ghita
PHP.net manual
------------------------------------------------------------------------
[2004-05-01 18:24:48] php at ter dot dk
schlueter:
1. PHP would have easy access to the servername, where available.
1.1. Another approach, that might be more alike existing solutions
would be, when in safe mode, to add the UID of the script to the
session id. This solution is already used when using HTTP-based
authentication in Safe Mode (UID added to the Realm).
2. My experience would say that the fewest service providers configures
a unique save_path for each user. Yes, I know how to configure PHP
myself, but that has no effect on rest of the world.
3. The argument is flawed. It's very easy just to play "King of my
castle"-sysadmin, but let's look at the case in a broader perspective:
The superglobals were introduced to prevent some user errors. One might
have used the same argument, "It's the users' fault", which might be
correct, BUT when a problem is as widespread, it is a global problem
and should be handled as such, with centralized solutions, instead of
just blaming everybody else.
3.1. You might change the category to a documentation-issue, but all
the documentation states under sessions is "You need to take additional
measures to actively protect the integrity of the session, depending on
the value associated with it.". The security-chapter doesn't mention
anything about this at all!
Using the same debate technique, one might state: PHP isn't interested
in security (or ther users' security). The documentation doesn't
provide enough explanation about this issue.
So, my proposal would still be, just as a solution to gain access to
other users' passwords at the same server using the same realm, to add
the UID of the script to the session-filename when in safe mode.
That would be pretty much in the spirit of safe mode (user separation),
as file access, HTTP-authentication, etc. are based on information about
UID.
Any cons against this proposal?
------------------------------------------------------------------------
[2004-05-01 17:43:25] schlueter at phpbar dot de
PHP does neither know something about different sites nor
where to write sessions except from /tmp so the provider
has to tell it.
Most providers I know set the session.save_path per user
in the Apache configuration and I don't see any reason to
change this. If one provider doesn't do this it's not the
fault of PHP but with the provider who isn't interested in
security.
------------------------------------------------------------------------
[2004-05-01 16:54:51] php at ter dot dk
Please notice that not any single PHP-user in the world has access to
the Apache-configuration as well. That's the whole point:
This issue is relevant for customers at web providers. These customers
should be pretty restricted. safe_mode is also advertised as a method
of isolating users from each other, but that isn't enough here.
Furthermore, suggesting that every virtual host in the world where the
user has access to php should have a custom php-configuration - that's
just simply not going to happen.
It isn't a problem for those who host a website on their own server.
But it is a problem for everybody else.
I haven't heard a single good argument for why increased security
shouldn't be enabled per default, instead of allowing sites to access
other sites' session data.
Allowing sites to access each other's data should be the exception, not
the rule.
- Peter Brodersen
------------------------------------------------------------------------
[2004-05-01 15:56:35] schlueter at phpbar dot de
There's no need to change the scripts. Just set the
save_path in your Apache configuration for every vhost -
where should PHP know a "good" location from?
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/28242
--
Edit this bug report at http://bugs.php.net/?id=28242&edit=1
