Posted by mmckeon@gmail.com on 12/11/06 16:03

In addition to keeping your password secure, it's important only to
give the database user that you are using access the database from the
web the minimal amount of privileges it needs to work. This for the
most part your web database user should only have SELECT, UPDATE,
INSERT and DELETE. For things like a shopping cart you should even go
as far as locking things down on a per table basis.

For example, let's say you have a table with all your products in it,
the web user shouldn't have the ability to delete, update or insert
into this table. The web user is only going to list and view you
products so he only needs access to SELECT from this table. (This also
can HELP protect against SQL injection attacks)

On more thing to do is make sure that the web user you are giving
access to has a host name that it should be connecting to. For example,
webuser@localhost (and not webuser@%). This again would restrict people
from access your database from a server other than the one your
database is on. If your webserver and database are different machines,
do the same thing. For example: your web server's IP is
192.191.190.189, your database accounts that are coming from the web
server should be "webuser@192.191.190.189".

This can help minimize any damage that could be done should your
database user/password be compromised. This however is very unlikely if
you take the measure described above. (But if you are offsite and
uploading files via standard FTP, it is being sent in plain text). It
never hurts to be have redundant security measures.

Gordon Burditt wrote:
> >> you could place it outside the Document Root or within a protected
> >> directory.
> >
> >I did just that and I created an .htaccess file in the directory to
> >allow apache to protect it. I'm still a little insecure tho'. I can't
> >seem to get to the directory using browser so why the need to protect
> >it with .htaccess?
>
> PHP will occasionally break (when you're in the middle of upgrading it)
> and the web server may at that time serve up .php files without running
> them. By putting the file outside the document root, you're protected
> two ways:
>
> - If PHP isn't working, you can't serve the file containing the
> file because it's outside the document tree.
> - If PHP *IS* working, you won't serve the file, it will just
> be run as PHP.
>
> Also, the file should be readable by the user running PHP but not by
> all users.
>
> >My guess is that there will always be the potential
> >to get into this directory via url hacks.
>
> That would be a pretty serious bug in Apache.
>
> >Also I was able to dowload
> >the file via ftp from the command line. How to stop that?
>
> Were you able to download the file via *Anonymous* ftp?
> If so, you've got a big problem. If it's via non-anonymous FTP,
> keep your password secure.

[Back to original message]