Page MenuHomePhabricator

Session cookies (and data) being shared between web services cause issues
Closed, DuplicatePublic

Description

As the session id cookie is identical between tools, the first one to save a session prevents others from doing so because of permissions. If the permissions allowed it, it would - at best - cause sessions overwriting each other and at worst leak information and possibly authentication tokens between tools.

Fixing this requires either

(a) per-tool session.cookie_path so that every tool maintains distinct sessions or
(b) per-tool session.save_path so that every tool maintains separate session /data/


Version: unspecified
Severity: major

Details

Reference
bz65891

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 3:14 AM
bzimport added a project: Toolforge.
bzimport set Reference to bz65891.

Note: one possibility is to simply *document* that caveat and let tools that care about/intend to use session data to set their save_path or cookie_path accordingly.

(In reply to Marc A. Pelletier from comment #0)

As the session id cookie is identical between tools, the first one to save a
session (..)

Note that the reason they share the same session id to the outside is because of session.name (defaults to PHPSESSID). When PHP wants to start/continue a session, it sees that cookie is set already on the client and thus doesn't set a new one.

We should not modify session.name per tool though, as that would just create loads of cookies. And while modifying cookie.path also creates a session cookie per tool, at least only one is sent back and forth between each request (the one for the current path), whereas with session.name the browser would be forced to send *all* cookies with every HTTP request.

We already have individual webservices running per tool with their own configuration and user process, probably easiest to ensure the php backend for that sets cookie path to something like ~/.phpsessions (instead of the global /var/lib/php5 directory)

On the other hand, any change to the PHP config should be changing the /defaults/ only, allowing tools designed to do so to share session data as needed.

The advantage of ~/.phpsessions is also that cookies are shared between hosts, which means people are not suddenly logged out when the webservice is restarted.

From PHP 5.3 on, PHP supports '.user.ini' files, which can be used to override php.ini directives. I suggest the following setup:

For each tool, create the following:

  • directory ~/web (775 permissions)
  • directory ~/web/sessions (700 permissions, or 770?)
  • file ~/web/php.user.ini with contents:
session.save_path='/data/project/$USER/web/sessions'
session.cookie_path='/$USER/'
session.name='$USER-PHPSESSID'

with $USER replaced by the tool name,

  • symlink ~/public_html/.user.ini to ~/web/php.user.ini

We should probably do that on the first webservice start invocation?

The reason for setting the session name is to prevent name clashes with the global PHPSESSID, to prevent session hijacking.

coren removed coren as the assignee of this task.Nov 16 2015, 6:34 PM