In what world does this work? $ curl http://your-website.com/public/../../../../proc/12345/environ If your server is serving up your whole filesystem, you likely have a lot of big problems.
You'd be surprised...
Do not use secrets in environment variables
11–20 of 96 posts
Re: Do not use secrets in environment variables
#12In what world does this work? $ curl http://your-website.com/public/../../../../proc/12345/environ If your server is serving up your whole filesystem, you likely have a lot of big problems.
Typically seen more often as something like:
http://example.com/viewPost.php?post=../../../whatever
Re: Do not use secrets in environment variables
#13In what world does this work? $ curl http://your-website.com/public/../../../../proc/12345/environ If your server is serving up your whole filesystem, you likely have a lot of big problems.
and even if your server can reach it, here (Debian 11), all of /proc/PID/environ is marked 0400, root:root owned.
Re: Do not use secrets in environment variables
#14External "Secrets management services" are among the most attractive hacking targets. It is beyond me why you would have full trust in those.
Re: Do not use secrets in environment variables
#15this is mostly about not using .env files
I'm not sure if I understood something wrong, but .env files are for development, not production. It never crossed my mind to use .env files for production deployments, but skimming the blog post, it seems like people do ship a .env file to their production environment?
SRE here, most of time when that happens, it's people leaving .env in git where it's not ignored and build process just does COPY * * to runtime environment.
EDIT: Or it's just small time developers who don't care about security and ship whatever works.
Re: Do not use secrets in environment variables
#16this is mostly about not using .env files
I'm not sure if I understood something wrong, but .env files are for development, not production. It never crossed my mind to use .env files for production deployments, but skimming the blog post, it seems like people do ship a .env file to their production environment?
I bet many .envs have been mistakenly shipped to production.
I will continue to use .envs. The alternatives invoke much more friction.
Re: Do not use secrets in environment variables
#17Here, let me boil it all down for you. Basically, you can determine if it's safe to store secrets in a given place by feeding it to this Python function, which will return True if it's safe and False if it is not:
def canIStoreMySecretsHere(location):
return False
You might think I'm being sarcastic, but... perhaps less than you'd think. It has often seemed to me that secret management is a game of temporal arbitrage, where you stick them in some new sort of place and just pretend that that new place must be secure, until you realize some time later it is not, and then you stick it in a new place, a new "secrets manager" that is safe, until that gets popped, then you stick it somewhere else....
(Note this is about symmetric secrets, and things like passwords. Asymmetric things admit more interesting possibilities of bundling some computation with the storage with things like secure enclaves. One can debate the physical security of a secure enclave, but assuming its software is correctly implemented, a secret store where there simply is no API in theory or in practice to extract the secret back out is an actual improvement in secret storage that I am not sarcastic about.)
Re: Do not use secrets in environment variables
#18This article has about as much insight as I would expect from a "nodejs-security.com" article.
This article spends a good deal of time conflating two things: putting stuff in .env and using environment variables.
The application-parsed .env file is one of the most poorly thought-through ideas that has taken hold in modern application development. It takes something you can do in literally a couple lines of shell (as a container entrypoint) and adds a bunch of complexity for something that is actually just worse.
In local dev scenarios, app-parsed .env files suck because you often end up with some kind of dev-specific secret that you don't want committed to the app repo. In my experience this means developers figure out how to pass a .env file around.
If you use an actual shell instead, the local-dev .env can shell out to something like the AWS CLI to get secrets from parameter store. Or you could grab them from Hashicorp Vault if you run that.
And because a shell fetches it at run time, secret updates are seamless and properly access-controlled in one spot.
In proper deployment scenarios, .env sucks because your deployment system (container orchestrator, Lambda, etc) will need to set those values appropriately for their current environment anyway. And by having a .env file the app loads, now you have two places for configuration.
Applications simply should not have any involvement in setting values for their own environment variables. They are typically used for core infrastructure-level configuration. The source of truth for this is probably going to be available via something like Terraform. So the application should ultimately inherit they configuration through Terraform.
Additionally, this article is simply wrong on environment variables being readable by any user on a Linux system. On Linux, a process's environment can be read by the superuser and the user who owns the process. That's it.
Re: Do not use secrets in environment variables
#19systemd 247+ now discourages using env vars for secrets, because there are the LoadCredential and related options that are much more secure, with better isolation and encryption features.
https://www.freedesktop.org/software/systemd/man/latest/syst...
Re: Do not use secrets in environment variables
#20In what world does this work? $ curl http://your-website.com/public/../../../../proc/12345/environ If your server is serving up your whole filesystem, you likely have a lot of big problems.
Usually they work in PHP world