[Dovecot] OT: PHP session data storage

Noel Butler noel.butler at ausics.net
Tue Oct 29 03:11:54 EET 2013


On 29/10/2013 10:10, Michael Orlitzky wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 10/28/2013 04:10 PM, Reindl Harald wrote:
>>> 
>>> php_admin_value open_basedir /var/www/$domain/$host/
>>> php_admin_value upload_tmp_dir /var/www/$domain/$host/tmp
>>> php_admin_value session.save_path /var/www/$domain/$host/tmp
>>> php_admin_value sys_temp_dir /var/www/$domain/$host/tmp
>> 
>> oh no - do *not* place the sesiondata anywhere inside open_basdir
>> this is one of the badest things you can do because any otherwise
>> harmless script bypassed whatever security restriction will be able
>> to read *any* session data
>> 
> 
> You have a point, but I wouldn't go as far as to say it's one of the
> worst things you can do. If a vulnerable PHP script allows an attacker
> to (at least try to) read arbitrary files, then it's possible to read
> session data that lies within open_basedir. Note that they can already
>  read your database credentials out of config.php at that point.
> 
> But, if you put the session data under open_basedir, then it's easy to
> restrict access to the entire /var/www/example.com hierarchy to the
> one user that needs it: www.example.com. In the scenario I described,
> I'm able to tell our customers that their websites are "physically"
> separated from our other customers.
> 
> If there's a vulnerability in someone else's site, the kernel (via
> filesystem ACLs) will prevent it from affecting yours. The web user
> for example.NET truly cannot even traverse /var/www/example.COM, where
> everything important to you is stored. This is robust against Apache,
> Ruby, Python, etc. vulnerabilities as well -- not just PHP.
> 
> I already mentioned that I don't trust PHP. Our sites would be just as
> secure if open_basedir stopped working tomorrow, since the filesystem
> ACLs are what we trust to work. So, we trade the potential to read
> sessions for that peace of mind. Not trying to downplay your
> complaint, just pointing out another POV.

Some time ago, we too, evaluated the pros and cons given our design, and 
we too, decided on the lesser evil and keep it under open_basedir, have 
done for many many years without problem, of course I'm not so naive to 
think it may never one day be a problem for a single host, when running 
shared hosting there are always risks, in everything.



More information about the dovecot mailing list