Security implications of a pyramid/wsgi os.environ backdoor?
In order to instantiate the server application with that debug feature in environment, the attacker would have to have the hand over your webserver, most probably with administrative privileges.
From an outside process, an attacker cannot modify the environment of the running server, which is loaded into memory, without at least debug capabilities and a good payload for rewriting memory. It would be easier to just reload the server or try executing a script within it.
I think you are safe the way you go. If you are paranoid, ensure to isolate (delete) the backdoor from the builds to production.
In my pyramid app it's useful to be able to log in as any user (for test/debug, not in production). My normal login process is just a simple bcrypt check against the hashed password.
When replicating user-submitted bug reports I found it useful to just clone the sqlite database and run a simple script which would change everyone's password to a fixed string (just for local testing). Now that I'm switching over to postgresql that's less convenient to do, and I'm thinking of installing a backdoor to my login function.
Basically I wish to check os.environ (set from the debug.wsgi file which is loaded by apache through mod_wsgi) for a particular variable 'debug'. If it exists then I will allow login using any password (for any user), bypassing the password check.
What are the security implications of this? As I understand it, the wsgi file is sourced once when apache loads up, so if the production.wsgi file does not set that particular variable, what's the likelihood of an attacker (or incompetent user) spoofing it?