Re: PHP 4.0 Bug #7606: Security Hole

exothermic@softhome.net wrote: > With a multi user system we cannot secure any database driven webapplications that use php. > Every file that apache "sees" must be at least readable by every other user. Since php > runs as the same user as Apache then that includes the files that contain d > atabase logins and passwords. I know there is a way around this using CGI but I would rather > not. When will there be a solution to this? There are quite a few options and techniques to handle this issue already. 1: Run multiple instances of apache, as different users. Users of different security levels connect to different server instances. 2. Don't store database passwords, instead, use them as part of the apache connection. Most modern databases support internal username/password access, and several php modules support individual user based logins. 3. Protect any and all files storing sensitive data using apache's accesss control to the files themselves. This prevents web browsers from seeing them, while still allowing apache access to them. 4. Only allow minimal database access to untrusted users of a database. Basically, this is an issue of how you think about security. You can *assume* that apache "must have a wide open door to everything", in which case anybody using that door has dangerous access. Or you can assume that apache (meaning, the internet) is inherently an untrusted user, and must be granted only minimal access to important or volatile data. On top of that, you can build access control based on encrypted connections (such as ssl), without password storage, and create your own security mechnism for authenticating users. I'll give you an example of a live site I'm running *right now*: There are two web server instances, listening different IP's. The admin server is firewalled from outside traffic at the machine and at the router. The public server runs with a less trusted user. When outside users connect to the server, they are connected through ssl, and auth'ed via passwords stored in LDAP for initial entry. Higher level entry is based on other LDAP settings which are also verified through apache *and* PHP.... but 'net users never have the ability to damage sensitive data, because such data is not available to that apache instance. If the firewall and router are compromised, they still need LDAP/system and database passwords to damage the internal data. The databases themselves are usually admin'ed over ssh (to a command line). Any files which can include damaging access information are protected by apache from being read over the web, and important internal databases are not available to that user. To put it another way: PHP does not provide a burglary detection system, deadbolt locks, and a guard dog. It does help provide you with the tools you need to build such a system, and even the occasional direction on training your dog. Who you let in is still up to you. -Ronabop -- Brought to you from iBop the iMac, a MacOS, Win95, Win98, LinuxPPC machine, which is currently in MacOS land. Your bopping may vary.