I have had the opportunity to do what you are attempting in several different ways. 1. Hack Perl, 2. Provide a password access module
1. is not so pretty. Basically, we allocated a global database handle in the perl main. Using SWIG, we then create the database handle in C and using the C module retrieve the password from a password server. (another database). When the handle is passed back to Perl, we store it in our global variable. This is the worst hack in the world but it works. Currently we are attempting to get away from this method as it locked us down to particular hacked version of perl.
2. This is the current method that we are migrating toward. Subclassed DBI and overrode the connect method. Now if my DBI is called without a password, the password retrieval mechanism is invoked and supplies the password. More of an obscuring mechanism, but we do not have web servers calling directly to dbs, so the issue of clear text password in the subclassed DBI module is not so much of a concern for us. Like most places there are 9 layers of security to get through before you can try to run perl code on a production host.
HTH,
Chuck Fox Principal DBA America Online, INC.
[EMAIL PROTECTED] wrote:
Hello!
This is probably something trivial, in which case I apologize, however I'm quite new in Perl and even more so in databases. Actually, I'm quite new in programing at all, so please don't laugh at me.
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?
Every example I have found so far about using DBI or Class:DBI or anything includes the password as a cleartext in the source code. I realise that it's just for the sake of code examples simplicity and anyone had to be insane to introduce such a serious vulnerability in a production system, but frankly I'm not quite sure how to do it right.
Should I make my CGI scripts not directly readable/executable to the httpd processes and write a suid wrapper which would then run the script itself including the password in the source code or reading it from a filesystem?
What about the database itself access privilages? Should I use different accounts for different scripts, depanding on what access do they need to have?
The most obvious solution seems to be something like this: For example, there's a news website. Everyone can read news, but only admin can add/modify them. So there need to be two system user accounts, e.g. newsadmin and newsguest, with the same accounts in the database having respectively read/write and read only (of course I'm simplifying, it whould be select privilage, insert, etc.) and two CGI scripts with an appropriate suid wrapper each.
The problem is that having many indepandant websites on the same server can cause a need to have quite a lot of OS and DB accounts, so I'm asking if this is indeed the way to go, or maybe I'm missing something?
So I'd like to ask all of you experienced Perl developers: How do you solve the problem of database security in production environments yourself, especially when the website is not the only one on the system and not the only one using a given database?
I'm sorry if I'm asking a stupid question maybe missing an obvious answer, but I'm just beginning my first Perl/database project and everything I have are some terrible examples left by someone working here before, who was obviously completely security-wise ignorant and now I have to clean all of this mess he left here.
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.
I'd be grateful if anyone could point me to some documentation which I failed to find or just say few simple tips. Thanks a lot!
(Should I post it to [EMAIL PROTECTED] It's indeed a problem with CGI scripts, but the problem itself is not stricte CGI-related, so I'm not quite sure.)
Thanks! -Zedgar Z.
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
