php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #28242 A site's session data is available for all virtual hosts on same server
Submitted: 2004-05-01 14:48 UTC Modified: 2004-07-01 11:00 UTC
From: php at ter dot dk Assigned:
Status: Not a bug Package: Session related
PHP Version: 4.3.6 OS: Linux
Private report: No CVE-ID: None
 [2004-05-01 14:48 UTC] php at ter dot dk
Description:
------------
This is a security-related issue. I couldn't find any mention of it by searching older bugs or reading the session-page.

If several sites are hosted on the same web server - which is the case at most web hosting providers - a site would have access to read and write to a particular session created by another site.

Example: Two sites is present at the same server. Site A is beyond our control. Site B is our own website, where we can use PHP.

Site A sets a session and puts some data into this.
By using the same sessionid in our code at site B, we are able to view and manupulate the session-data only present on the web server.

The requirements are that site A provides us with a sessionid and we have access to another virtual host on the same webserver as the site, we would like to attack.

This is not directly related to session fixation (the session already exists for the PHP-server). Also, the usage of session.use_only_cookies wouldn't change anything, since we could just craft our own cookie. I don't think that safe_mode could prevent anything, since we are just using the php-based functions and not snooping around the session-temp-dir manually.


Reproduce code:
---------------
I have put up an example at:

http://stock.ter.dk/session.php (as site A)
http://peter.plys.net/sessiontest.php (as site B)

stock.ter.dk is the victim website where we ordinary would have no access.

peter.plys.net is another website running at the same webserver. This would emulate our own website, where we can upload our PHP-code to access and manupulate the sessiondata. Since the sessiondata can contain code about whether we are logged in or not, which user we are logged in as and stuff alike, it might be a pretty serious security issue - although it does require that our site is located the same place as the victim website. Users with dedicated servers would not be at risk

Expected result:
----------------
The session data of stock.ter.dk and peter.plys.net would not be shared.

Actual result:
--------------
The session data of the websites are shared.

A solution might be for PHP to add the SERVERNAME to the session-file (eg. "sess_stock.ter.dk_8a392cf...") and maybe an option to session_start() to allow sharing of session (as it is today) if anybody really depends on this "feature".


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-05-01 15:17 UTC] derick@php.net
This is not a bug as it's perfectly possible and recommended to set up a special session "tmp" directory for each client/vhost/whatever. 
 [2004-05-01 15:42 UTC] php at ter dot dk
Is there a reason for this not being default?

It might be a political desicion to create such a change in the PHP-setup. But isn't it better to add this security in the first place instead of requiring all scripts ever made to alter sessions.save_handler ?

Think about it - all scripts ever distributed would have to be altered, and no scripts downloaded would be ready to run as-is.

- Peter Brodersen
 [2004-05-01 15:53 UTC] php at ter dot dk
Err, make that session.save_path (and not sessions.save_handler). Besides, where is that recommendation?
 [2004-05-01 15:56 UTC] 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?
 [2004-05-01 16:54 UTC] 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 17:43 UTC] 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 18:24 UTC] 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-07-01 11:00 UTC] zamolxe@php.net
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-07-02 05:23 UTC] xuefer at 21cn dot com
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
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 10:01:30 2024 UTC