Secure way to pass database connection info from mod

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

I'm working on an application for which security is of great importance. I'm using an Apache::AuthCookie subclass to do the authentication, and the username and password used to connect are actual database logins. I'm prototyping some stuff on a mySQL server, but probably the final app will use PostgreSQL.

I'm trying to pass the information required to connect to the database from the authentication handler to the a standard (not mod_perl) CGI script that is the primary application. As a form of security-in-depth, I'd like to do this in such a way that even if a bug in the CGI script allows executing arbitrary commands, an attacker still can't get access to other users' passwords.

What I'd really like to do is open the database connection in the auth handler, then just pass a pre-authenticated open file descriptor connected to the database to the CGI script. Unfortunately, the MySQL and PostgreSQL APIs don't seem to support anything like this. Does anybody know a way to do the equivalent of this?

The easiest way to pass the information is through environment variables, but of course those can be viewed through ps. If my application is running on grsecurity-patched Linux in a chroot area mounted with nodev and without /proc mounted, is it reasonable to expect that environment variables are protected, or is that still a dangerous assumption?

Normally I would pass this information on a file descriptor, but coordinating that from within an Apache handler seems like a difficult task. Using a tempfile won't work because other instances of the CGI script would be able to read all of the tempfiles.

Anybody have any suggestions for me, or any pointers to solutions to similar problems?

Thanks!

Comment on Secure way to pass database connection info from mod_perl handler to CGI script

Replies are listed 'Best First'.
Re: Secure way to pass database connection info from mod_perl handler to CGI script by perrin (Chancellor) on Aug 28, 2004 at 03:31 UTC
I don't think you can do better than environment variables if you are unwilling to run your program under mod_perl. You could write things to a file, but that doesn't seem more secure.	[reply]
Re^2: Secure way to pass database connection info from mod_perl handler to CGI script by sgifford (Prior) on Aug 28, 2004 at 03:53 UTC
My perception is that it would be more secure to use a CGI script than a mod_perl script, since the mod_perl code would have access to internal Apache data structures, and a bug could allow an attacker to affect future requests. Is there any reason to believe that's incorrect?	[reply]
Re^3: Secure way to pass database connection info from mod_perl handler to CGI script by perrin (Chancellor) on Aug 28, 2004 at 04:06 UTC
If an attacker compromises your CGI script badly enough to execute arbitrary code, he can delete or copy your entire database, among other things. I wouldn't consider this illusion of safety worth giving anything up for.	[reply]
Re^4: Secure way to pass database connection info from mod_perl handler to CGI script by sgifford (Prior) on Aug 28, 2004 at 04:37 UTC
Re^5: Secure way to pass database connection info from mod_perl handler to CGI script by adrianh (Chancellor) on Aug 28, 2004 at 15:09 UTC
Some notes below your chosen depth have not been shown here
Re^5: Secure way to pass database connection info from mod_perl handler to CGI script by perrin (Chancellor) on Aug 28, 2004 at 18:31 UTC
Re: Secure way to pass database connection info from mod_perl handler to CGI script by dba (Monk) on Aug 27, 2004 at 23:52 UTC
One possible option would be to generate hash value of the password and validate against the hash for a given username stored in the database through a persistent, pre-authenticated connection. ( similar to unix passwords...)	[reply]
Re: Secure way to pass database connection info from mod_perl handler to CGI script by doowah2004 (Monk) on Aug 28, 2004 at 06:10 UTC
Set up a dummy mysql user that does not have any rights outside of thier table, and store real users encrypted passwords in the table. Have the real password be some random variation of what the users set, and then use the pasword that the users set as the encryption key for the password in the database. You can use something like blowfish to encrypt it. By randomizing their password, you can adjust/verify the password length. That along with strong encrypton, even if some one could get the encrypted password from the database, they would have a very difficult time decrypting them. If that is not secure enough you could use 3DES + blowfish to doulble encrypt the password..... This is what I would do anyway, because it is simple but effective.	[reply]