I'm not completely sure I understand your goals, question and setup, but, if you are concerned about security, using a relational database is almost if not certainly your best bet. I am working on just such a system right now for myself, so I can appreciate your question. I'll give you some input as best I can.
1.) The usual argument against flat file db's goes something like as follows. Flat file db's are usually more hackable and difficult to handle if they get large. If you are running Apache, but your server isnt running suEXEC, then you would have to chmod your files to some world writeable file. You could "hide" this world writeable file to promote security through obscurity, but I would only trust that to a certain extent. If you server does have suEXEC, however, then you can chmod the access permissions of your writeable flat files to a user group under which your cgi scripts would only have permission.
But I still wouldnt use flat files because they are difficult to manage if they get large and need to be changed structurally.
2.) Relational DB's will require a login routine to connect, and this will have to be embedded in your scripts. The downside here is that it opens another port of your server, but the port can be limited much like user groups on Apache. For example, I cant use an FTP-like interface to connect to my DB remotely, as my hosting service requires I go through localhost first. As you can see, the SERVER's configuration often helps secure the DB too. Additionally, relational DB's themselves have varying levels of security.
3.) If you wanted to be really secure about things, then you could https the connection. Setting up a secured server would help to counteract sniffers, though it might slow things down a bit.
4.) The skill of the programmer and the scripts themselves can play a big role. A lot of people feel using CGI is like laying out a welcome mat to trouble. But you can use different modules and drivers that have been proven to help security, as well as build in validation features to the script. For instance, I'm not a great programmer, but I know enough to use CGI.pm to parse my input params rather than doing them myself. If you want to run sessions, like you say, then look into CGI::Session for secured login routines. There are many DB drivers you could use to connect to the database, and they each have different features. I use DBI, for instance, and it has the ability to do multiple logins to different databases. If you use your imagination, then the ability to login to multiple DB's could be a big asset to security.
5.) Change your database username and password frequently. This may sound difficult if you have a lot of scripts, but it's not so hard if you build a module to handle the connection string. Then all you have to do is change the username and password in the module, and, when the other scripts call it, they will work just fine. The worst hackers are those you dont know about. This way if someone got in undetected, then they would have to relearn how to get in again.
6.) Backup all your files. Write a perl/SQL script under a cron job to do a data dump of the entire db every so often.
7.) Work with your hosting service on solutions, as well as your client on their budget. Maybe you could set up a second server that would run a cron job to execute a perl script that would pull data from the first database and set it into a second database. In this way the first data server would only act as a proxy to the second data server, and, if someone hacked the first dataserver, then it would hold an incomplete list of information. It would also backup your files into a "larger pool." The problem then becomes how to get the data back to the front end when the end user needs it. Since there are many different ways to that, I'll leave it to you to choose what is the best way to go for your setup... Like I said, a lot of security is server dependent, and there are ways you could setup your system from a network standpoint.
Anyway, I'll leave go now... just thinking out loud... providing some food for thought... etc...
Good luck!
quint
From: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Perl/DBI newbie: password storage / security question Date: Sat, 13 Sep 2003 21:25:55 -0500 (EST)
R. Joseph Newton wrote:
> [EMAIL PROTECTED] wrote:
>
>>I'm basically concerned about the security of writing a simple web frontend to SQL database, the most important question being: how should I store the database password?
>>[...]
>>There are tens of websites on the server and every database access is done with an account having full (sic) access to all of the tables and - if that wasn't enough - the password is in the clear in the sourcecode which is all world readable! No wonder why the previous admin was fired.
>
> Although only a slight improvement, it can help to shift the database out of the cgi directory. On the server I use, the web server runs as part of the group. There fore if a side directory has chmod 660, the server can access it, but the world can not. Unfortunately others considered to be part of the same group can also read it.
Thank you Joseph and Motherofperls for your tips, however I need something more than security through obscurity, as this database is going to store our customers personal information (real name and contact information) which is absolutely unacceptable to be stored in such an insecure manner (we cannot risk being sued or loosing our customers and of course I most definitely cannot knowingly introduce such a serious vulnerability being responsible for that website).
I cannot depand on attackers not finding the database password which is stored as cleartext in a world-readable file while its path is included in the script source (or even if it wasn't included anywhere, for that matter).
Even if it is group-readable for a group which the httpd process belongs to, it is actually not any more secure and only adds one simple step for attacker to access the file with a CGI script by exploiting any script from any website on the server or using any user account which can modify any one of those webites, so I'd say it is basically world-readable on a server where I am not the only one who has a website.
What I need is a secure way of doing it and I'd like to know how the experienced Perl developers solve this common problem. It'd be somehow hard to believe that people actually store sensitive data in production environments in such a way which allows full access using the most trivial web attacks and even without any need of attack at all for everyone with a website on this server, even without the shell access.
I hope someone who has developed any real production system could answer my question or even just tell me to RTFM while kindly pointing me to the right FM, because to my great surprise I couldn't find anything in perlfaq and any other Perl documentation or books I've read.
Thanks a lot. -Zedgar Z.
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Fast, faster, fastest: Upgrade to Cable or DSL today! https://broadband.msn.com
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
