ID: 28242 User updated by: php at ter dot dk Reported By: php at ter dot dk Status: Bogus Bug Type: Session related Operating System: Linux PHP Version: 4.3.6 New Comment:
Err, make that session.save_path (and not sessions.save_handler). Besides, where is that recommendation? Previous Comments: ------------------------------------------------------------------------ [2004-05-01 15:42:01] 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:17:02] [EMAIL PROTECTED] 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 14:48:10] 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". ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=28242&edit=1
