51–60 of 96 posts
External "Secrets management services" are among the most attractive hacking targets. It is beyond me why you would have full trust in those.
This 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…
export DB_PASSWORD="op://app-prod/db/password"
Calling the script with `op run scriptname` replaces the secret path with the actual secret after authentication during runtime.
This way you can commit the file but people still can use their own passwords locally without saving them in plaintext.
Earlier quoted context omitted.
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)
We got access logs like this all the time. SaaS app with separate domain per customer so we got a lot of probes like this. Famously IIS had some bugs like this. Not surprised that PHP has problems. What a clown car.
This is a file inclusion vulnerability. And that's something that is _very_ easily done in any language which people use to do stuff that loads files from the file system. Image resizers are a pretty common exploit path.
So don’t provide secrets to your service via environment variable, it can leak? Instead, expose all your secrets via a public API with IP filtering, then give the credentials to this service to your app - as an environment variable - and voila! This just seems like increasing complexity in a part of your system that should be as simple and non-dynamic as humanly possible, for the upside of.. much larger attack surfac…
But we never had a good system for sandboxes, which meant another way the local and deployment differed.
They moved to a secret store instead. I don’t know if that’s better.
This is simply bad advice, let's get this off the frontpage.
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.
Earlier quoted context omitted.
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)
We got access logs like this all the time. SaaS app with separate domain per customer so we got a lot of probes like this. Famously IIS had some bugs like this. Not surprised that PHP has problems. What a clown car.
This 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…
As middle ground for small scripts I like implementations like the one from 1Password: The environment variables contain the path to the secret: export DB_PASSWORD="op://app-prod/db/password" Calling the script with `op run scriptname` replaces the secret path with the actual secret after authentication during runtime. This way you can commit the file but people still can use their own passwords locally without savin…
this is mostly about not using .env files
The thing is, in a properly run engineering organization, zero developers should have any production secrets to put into .env files in the first place. Development secrets should always be either dummy values created for this purpose (e.g. one's local development database password should be nothing or 1234 or something because you need no 'security' on a local DB that listens on 127.0.0.1 only), or the keys to entirely separate testing environments, developer sandboxes, and free-tier accounts on your 3rd party dependencies (e.g. an identity provider, Salesforce, etc.)
I'd be uncomfortable with any .env files anywhere having creds in them that I would be upset about someone accidentaly posting even in our public repositories. Sure I'd rotate them just because I don't want someone poking around our local developer Auth0 account or local developer OpenAI account, but there should be zero or close to zero of value that's possible to exploit using those secrets.
At my company we've settled on dotenvx to manage these .env files, which has the neat feature of asymmetric encryption so that 99.9% of the time devs don't even need the private key for the production one because adding a new value for a new thing can be done with the public key. Values that are actually secret are encrypted in the env file, and the correct private key for the environment is passed to the app as an env var, which it uses to decrypt any encrypted values. As others have pointed out, many claims in the article about how anyone can access any application's environment are inaccurate.
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.
Ah, makes sense it could get exposed then.
The pattern I've always followed is having `.env.template`, `.env.dev` or similar in SCM, then require the development setup to manually/automatically copy it to `.env`, which is .gitignore'd.
Seems that pattern might not have been as widespread as I thought :)