FreeTDS Development Group

[Steve Langasek <vorlon AT dodds.net>]

On Thu, Jan 26, 2006 at 10:10:06AM -0500, Brian Morton wrote:
> In response to item #3 (I do quite a bit of php), how is this insecure?  Are
> you concerned that someone will access the source of your script and view
> the login information?  If so, the proper way to go about this is to find
> why you are concerned about that (escalation of privs through another
> script?) and close that vulnerability.  There is no reason to have an
> irrational fear of someone getting your credentials hardcoded in a script.

It's not irrational at all.  With CGI regarded as having too much overhead,
and a lack of good, mature Free (Software) implementations of FastCGI, the
"state of the art" in PHP hosting is still to run scripts in the security
context of the web server itself -- which means, best case, anybody who can
inject a script into your particular virtual host context can read your
credentials, and worst case, anyone who can inject a script *anywhere the
webserver will see it and run it* can read your credentials.  (The
difference between "best case" and "worst case" isn't necessarily under your
control, as it depends on factors such as: whether safe mode is enabled in
the PHP config; whether there are any known bugs in PHP's safe mode this
week; and whether there are other users who have access to install PHP
scripts on the server in the same web security context.)

> It's just like any other password file.  Another idea is to store the
> credentials in a separate password file outside of the webroot, and have php
> read the file for the information. 

This protects against at least one possible attack vector, that of creating
.phps symlinks and reading the password right out of the PHP file over the
web -- so this is a good thing to do.  Unfortunately, it's one of the few
precautions that will make any difference at all in a shared hosting
environment.

So the other good thing to do is secure the account on the *SQL* side, by
ensuring the credentials you're using for your PHP scripts don't have any
more permissions than those strictly necessary.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon AT debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature