[prog] PHP script security

[Almut Behrens]

On Wed, Aug 13, 2003 at 01:14:47PM -0400, Beth Johnson wrote:
> 
> I've set up a restricted MySQL user for the script to invoke which has
> SELECT priviledges only for the database.  One question is, I've put the
> username and password for that restricted account in the script.  Is
> this how it's commonly done?  Is this an okay way to do this?

That's perfectly okay, security-wise. From an administrative point of
view - as has already been pointed out - it would be a better idea to
put the connection parameters in a seperate, central file, that you
read/source by the PHP script. As soon as you start having a second
script needing DB access, you'll see the advantage, when you need to
change host/user/password for some reason.

Just think of it that way: what's the worst thing that could happen,
if some user got to know the DB password?  Well, she could read the DB
contents, but that's what you allow her anyway -- otherwise you
wouldn't be running that web-service ;)
Knowing a password is not _per se_ a security risk, what matters more
is what you can do with it...  This, of course, assumes that you've
setup the grants for that DB user appropriately (SELECT); but as you
mentioned, you've already taken care of that.


> Eventually I'll have a
> form for visitors to select the division to display, instead of pages
> with a static query, but I'm having problems with forms on my test
> server.

Be sure to always check user input that you receive via the form.
Many security risks arise from improperly handling user input -- in
particular from text-fields.
(Even the classical, famous buffer overflow can be considered a variant
of not handling user input correctly -- if everyone always checked for
the maximum allowed length of any user-supplied string, there would be
no more security-related buffer overflows...)

What could potentially happen here?  A malicous user might manage to
excute some arbitrary SQL code supplied by her -- if she knows how to
embed it appropriately into some variable parameter that you pass
_unfiltered_ to the query. As long as you allow the DB user SELECTs
only, that's not much of a risk, but once you grant her UPDATE/INSERT
priviledges, this could become dangerous.

So, even if this isn't a big problem yet in your particular case, try
to make it a habit to filter user input, or at least develop some
awareness of where problems might arise... (btw, similar, and usually
more severe, risks are caused by passing unfiltered input to shell
commands...)

A last word on how to filter: in general it's better to explicitly test
for what you expect/need to allow (and deny access if the user input
doesn't conform), rather than trying to remove something (e.g. certain
characters) that _you_ consider dangerous. With the latter technique,
chances are much higher that you're overlooking something -- so only do
that when you're absolutely sure you understood all potential risks...

Cheers,
Almut