41–50 of 96 posts
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.
Things like vault which was suggested still requires you to pass the vault token in to your app somehow. And even then if your application does not have direct vault support you will still be using vault to supply secrets via environment variables, its even the recommended way with Nomad and their template system.
I really dislike these sort of articles. Because it has a catchy phrase "Do not use secrets in environment variables", and that is all that will be remembered. And next thing you know you will be at a company submitting a PR and some guy will say "Do not use secrets in environment variables", and then advise you to pass them as arguments on the command line (this happened to me).
Environment variables are today, the most safe way to pass secrets to a program.
.env files ARE NOT Environment variables, they are files. A better title and write up would be "Do not store secrets in file". Once you do that all the weird problems described, with exception of printing them as logs, go away. Then you need a new article "Do not print secrets in your program".
But that is all moot, because you should already be filtering out secrets by configuring your local log system to do so. I my self write wrappers and log systems that handle filtering out secrets from logs within the same context of the application I run. Its super simple, it s fast (if you know what a trie is) and you can worry free print secrets.
Edit: This article in fact has more damaging impact to security as a whole, mostly because of the conflation and 99/1 on problem/solution. This entire domain will now be blocked on all networks I have control over.
Earlier quoted context omitted.
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.
this 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?
If you allow these mistakes to be possible, they are inevitable. If you take basic precautions, you'll probably be fine.
I'd rather take a well-curated and trimmed down .env over a poorly-configured secrets manager that gives away the entire farm when the single secret leaks. Security isn't a single thing nor bolstered by switching a single method of how you store your secrets.
The problem is not taking precautions to prevent leaks from happening, not how you are managing your secrets. If your threat model begins or is imminently "when the attacker is logged in as root", just post your stuff on a public bucket to get it over with.
It has nothing to do with environment variables… It is just a ephermal way how to inject variables into the process, if you do it right…
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.
Typically seen more often as something like: http://example.com/viewPost.php?post=../../../whatever (where the server side code has the bug, not the web server configuration itself)
Famously IIS had some bugs like this. Not surprised that PHP has problems. What a clown car.