We are running a web application in python using wsgi with apache2, and must submit to a penetration test. The testers will be exploring the potential for damage if the attackers gain shell access as the apache user.

Currently, the damage potential is enormous, as we have the credentials for the database, s3 service, etc. all stored in a text file readable by the apache user. This seems to be the default advice when setting up these sorts of applications, but is there a more secure way to do this?

I was thinking of using apache (as root) to pass environment variables with setenv to the wsgi app, but is this actually more secure? Any advice for this?

  • I have a similar situation, I am making an ruby rails app and I had to hardcode DB, API and other credentials in the app. I am experimenting with providing these credentials as STD input while initializing the application. That way it won't be hard coded in the app, it will stay only in the memory as long as the app is running.
    – Majoris
    Jun 13 '12 at 21:18

It really depends what your threat model is.

If we take away everything else and just think about the application, there is basically nothing more you can do to really improve the security of the app. Stay away from esoteric solutions and focus on what is more maintainable and clean. I want to stress clean, as usually security disaster arises from messy situations.

Anyway: if the attacker gets remote code execution under the application user, you cannot restrict access to the configuration in any way - the app has to access it, so can the attacker. If he gets file read capabilities, then storing in a database will protect you from disclosure - even if you have to store the credentials of the db in a file, the attacker won't hopefully be able to leverage those. If he gets SQL injection, access to the db (in the unlikely case this does not translate into remote code exec) then having them in a file is safer. Really, it depends on how your application is designed.

Running Apache as root is really a bad idea (well, disabling the privileges drop I mean). Instead of implementing one-time solutions focus on stuff that is going to stay in place without more hacks and get the benefits of the pentest. passing stuff via the stdin for instance will make it very hard for the testers to retrieve the credentials, but in the long run you'll likely end up with a bash script doing the job... which is by far worse than the other solutions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.