Re^5: Secure way to pass database connection info from mod

Do you see flaws in this design that I'm missing?

You're assuming that any compromise of the CGI script only applies to a single user and a single invocation of the script.

If the Evil Hacker can run arbitrary code then this may not be true. For example the compromised script could spin off another process that sits their doing a dictionary attack on your database, badly set permissions could allow the script to rewrite itself, etc.

In some ways a mod_perl server would be more secure. Set it up to only service a single request per-process. You still save on startup time, forks are cheap (definately cheaper than starting up a separate CGI process and loading all the modules needed), and a compromised service would have to restart Apache to affect future requests.

That said, it seems odd to me to be worrying about the database access in this way.

If it were me, and my requirements had me worrying about the possibility of a buggy CGI/mod_perl being compromised, then there is no way in heck I would have direct access to the database on the same box as the W3 server.

You don't need all the database functionality, the Evil Hacker can use it to gain information that you don't need/want to reveal, and you open yourself up to possible security holes in the database layer.

I'd have my W3 server talking to a separate applications server on another box using a very thin application specific protocol that only supplied just enough functionality for the W3 application to do what it needs to do. You hide most database-specific exploits away on the other box, and have something that you can apply fine grained security controls too.

Comment on Re^5: Secure way to pass database connection info from mod_perl handler to CGI script

Replies are listed 'Best First'.
Re^6: Secure way to pass database connection info from mod_perl handler to CGI script by sgifford (Prior) on Aug 28, 2004 at 17:32 UTC
Thanks for your thoughts, adrianh! Some responses... For example the compromised script could spin off another process that sits their doing a dictionary attack on your database That's true, although they could just as well do a dictionary attack on the main site. badly set permissions could allow the script to rewrite itself, etc. Which is why I don't intend to set the permissions badly. :) In some ways a mod_perl server would be more secure. Set it up to only service a single request per-process. You still save on startup time, forks are cheap (definately cheaper than starting up a separate CGI process and loading all the modules needed), and a compromised service would have to restart Apache to affect future requests. I already have Apache configured to process only one request in each child. As far as speed, it's not an issue; the site will be getting at most dozens of hits a day and will run on modern hardware. Attacks are possible with a mod_perl script that aren't possible with CGI, since it has access to the listening socket, the scoreboard, and other internal Apache data structures. For example, this bit of mod_perl will intercept some future requests, but isn't possible under CGI: Read more... (559 Bytes) These are the sorts of attacks I think CGI will protect against. I'd have my W3 server talking to a separate applications server on another box using a very thin application specific protocol that only supplied just enough functionality for the W3 application to do what it needs to do. You hide most database-specific exploits away on the other box, and have something that you can apply fine grained security controls too. Ah, that's a great idea! Thanks!	[reply] [d/l]
Re^7: Secure way to pass database connection info from mod_perl handler to CGI script by adrianh (Chancellor) on Sep 01, 2004 at 12:42 UTC
That's true, although they could just as well do a dictionary attack on the main site. True, but a stand alone program running on the local machine could do it a lot more effectively, and hide its behaviour more easily. Which is why I don't intend to set the permissions badly. :) Of course :-) But it is one more place where you're open to attack. For example, this bit of mod_perl will intercept some future requests, but isn't possible under CGI: ++ sneaky	[reply]