thunders has asked for the wisdom of the Perl Monks concerning the following question:

Fellow monks,

I'm embarking on a project incorperating a mysql database, accessed via two CGI scripts. the pupose of this project is to create an "upcoming events" page thats simple for my client to update and tidy up.

So far all has went well and i've tested two scripts to manipulate this database. One script reads events, the other can edit, delete, and add new stories.

In an attempt at security I've created two new mysql users, a "newsreader" and a "newswriter", each with the appropriate rights over the appropriate tables. The more powerful script, with the read/write access is in a protected folder(via Apache htaccess) that only my clients know the password to. the reader script is sitting in the cgi-bin unprotected, and publically viewable.

the potential problem is that the username/password for each user and db is sitting right in the source of those scripts. This seems like it could be a problem.

Are there other precautions I should be taking? Especially in the case of more important information than i've described.

Replies are listed 'Best First'.
Re: Thinking bout security- Mysql-perl
by Dog and Pony (Priest) on Apr 13, 2002 at 17:58 UTC
    You could put the username and password (possibly with a login-function too, that returns the db-handle) in a module that you put somewhere where it can not be accessed via the web server. Just like you should do with the passwords for .htaccess. In that case it will not be viewable even if the server decides to show the source instead of executing the scripts.

    I also assume that you have made sure that only localhost can read/write the tables, so noone can connect from the outside either way. That is the mysql default, so it should be fine if you didn't do any changes. Given that, people can not access your data even with the username and password without doing it from your server.

    I'm sure there is more, but something like that should be a reasonable start at least. :)


    You have moved into a dark place.
    It is pitch black. You are likely to be eaten by a grue.
Re: Thinking bout security- Mysql-perl
by dws (Chancellor) on Apr 13, 2002 at 23:04 UTC
    Are there other precautions I should be taking?

    If you're concerned about securing MySQL, get a copy of Paul Dubois's MySQL. He devotes a section to securing MySQL servers. It's worth the money, IMHO. He also gives good coverage to administrative tasks, including how to recover if/when something eventually goes KaBOOM! And his coverage on using MySQL from Perl isn't bad, either.

Re: Thinking bout security- Mysql-perl
by belg4mit (Prior) on Apr 13, 2002 at 18:58 UTC
    Things along the lines of DBIx::Connect (by PrincePawn, there are other things that do or will offer the same functionality), are very good for this. It also prevents the need for duplicate information in multiple locations.

    --
    perl -pe "s/\b;([mnst])/'\1/mg"

Re: Thinking bout security- Mysql-perl
by abaxaba (Hermit) on Apr 13, 2002 at 19:12 UTC
    I'm guessing you recieve the user/pass combo from form inputs.
    my $dbConnect = DBI->connect ("dbi:mysql:dbName", $name, $pass} || err +Msg(); sub errMsg { print "Not allowed\n"; }
    No valid passwords in the code this way.
    Of course, an SSL handshake makes this even more secure, keeping lurkers/hackers etc from snifting out the correct name/pass combo.
Re: Thinking bout security- Mysql-perl
by Anonymous Monk on Apr 14, 2002 at 03:47 UTC
    Putting database userIDs and passwords in a separate module is an excellent idea. I recently did an on-line survey for a client in a sub-directory under my main domain. After about 5000 people had been through the survey, it finally occurred to me to check that no one could get the file listing of the directory (and therefore all of the CGIs) by chopping off 'survey.cgi' from the URL.

    Yep, they sure could -- there was no index.html. But (!) because the userID and passwords were in a module in a different directory, there was no major security breach. I quickly added an index.html that does an immediate re-direct: another solution would have been to change the permissions on the directory (execute only) but the re-direct was the solution that I was able to implement the fastest.

    Embarrassed? Oh yeah. Very. That's why I'm posting anonymously.