|
|
Posted by Skijor on 12/14/06 04:09
very helpful. Didn't think to restrict write privilages to the cart
only. Such an obvious fact to overlook. As far as checking webser
IP's my database and webserver are hosted commercially and I don't
think database users will be arriving from the same webser all the
time.
mmckeon@gmail.com wrote:
> 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.
Navigation:
[Reply to this message]
|