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] |
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] |
Preventing an attacker who has compromised my CGI scripts badly enough to execute arbitrary code from copying the database is exactly the point of a security-in-depth strategy.
Here's the design I'm working with: Apache will run in a chroot jail, with a Unix socket to the SQL server inside the chroot. The SQL server stores its binaries and all of its data outside Apache's chroot. The username and password to log in to the SQL database are sent by the user, and only allow access to this user's own data (implemented using PostgreSQL views).
In this configuration, I don't think that compromising the CGI script will allow the user to copy or delete the entire database (unless it's in conjunction with a kernel bug or an SQL server bug); he will be able to send arbitrary SQL commands to the database, but only with the permissions of the SQL user he's logged in as, which will prevent access to or destruction of data other than his own.
Do you see flaws in this design that I'm missing?
| [reply] |