5 ms·

To be fair, I think a lot of developers begin with that. There is a logistical problem in providing secrets to a process without getting the secret exposed. Env

To be fair, I think a lot of developers begin with that. There is a logistical problem in providing secrets to a process without getting the secret exposed. Environment variables are an often chosen approach. Of course when the software is tested and ready to be deployed, the step to use a secure container containing credentials is often neglected like it was probably done here. This isn't necessarily sloppy programming, it is just skipping an essential step. How do you provide your secrets to your apps? Using an external service? That would still require another set of credentials. Using environment variables? A file only the user running the app has access too? Another way?

3np 5y ago
Environment variables on the server side, sure, but having those end up in the client...? If you find that this is a relatable mistake, I hope you have someone with more experience reviewing your code and processes before they touch anything remotely sensitive in production... (Unless you're just trolling)
alias_neo 5y ago
The step they seem to be missing is _the entire development process_. If you're using API keys to access stuff, you do it on your backend, there's no excuse for that stuff to make it to the frontend. If your "client" needs access to sensitive API keys, you need to rethink your architecture. As a (senior) backend software engineer, this reeks of a person/team who doesn't know how to architect and/or implement web applications/software.
- ratww 5y ago
  Is is a bit more nuanced than that. This web client needs access to non-secret keys that are passed via environment variables. This is absolutely commonplace. However there are two real issues here: first, some bug in the code is causing all environment variables to be dumped into the JS bundle. You can see that in inane keys like PATH, HOME, PORT. This issue wouldn't be such a huge problem by itself. The second problem is that during the build process for the frontend, there are environment variables that shouldn't be there, such as the secret ones. The CI or build machine should have been well isolated enough to prevent this problem from happening. This is a problem in the CI coupled with a bad build process.
  - greggsy 5y ago
    Great explanation - client side apps often seem to be a bit of a catch-22 in some cases.
    - danenania 5y ago
      It’s crucial to always use an allow-list approach to passing config through to a client.
      - ratww 5y ago
        Yep. Maybe just forbidding enumerating environment variables in the runtime would be enough for this case. However the CI shouldn’t have backend-only private variables available to frontend builds… some separation here would be safer regardless of developer mistakes.
- _fat_santa 5y ago
  According to the article, they were keeping their environment variables in React's local state. To anyone that works with React professionally, or even on the side, this is so baffling that a team would do this. I'm honestly wondering who they hired for the job. Because this is one of the most fundamental failings in security I've ever seen.
  - ushakov 5y ago
    > I'm honestly wondering who they hired for the job let me guess: bootcamp graduates? whoever was the cheapest?
    - SomeCallMeTim 5y ago
      Or outsourced to the lowest bidder.
- raxxorraxor 5y ago
  Yeah, it shouldn't reach the client in any case. But providing secrets to applications isn't really a well solved problem in my opinion. Even if it is just an environment variable for the server process it could get exposed. If a clients needs an API key I would think to route the requests through the server and add the key information at that point, but I am not a web developer and not sure if that always scales for any use case.
  - SomeCallMeTim 5y ago
    It's simply software engineering malpractice to have ever sent any of those keys to the client. There is no excuse. It is a well-solved problem to handle secrets; there are better and worse solutions. An environment variable for a server can get exposed if the server is hacked; a secret sent to a client is exposed the second the server goes live. One of these is much worse than the other. There are also better solutions than environment variables. A competent team would be aware of many options. Whoever coded this is not competent, full stop. It's not that they didn't finish; these services should never have accessed from the client at all.
- akdor1154 5y ago
  Being generous, it might also be a fuckup in implementing SSR... maybe. Still a fuckup though.
maccard 5y ago
> How do you provide your secrets to your apps? Using an external service? That would still require another set of credentials. Using environment variables? A file only the user running the app has access too? Another way? It sucks for a small team or for anyone who is trying to run a free tier, but terraform plus aws secrets manager or vault works really well. Using a db password as an example, for our app we generate a random password, store it in secrets manager, and our containers on fargate run with an iam role that allows access to that secret. Our state is stored in S3, and the infra is applied on commit to main with a terraform plan run on the merge request to main. Our biggest security vector is always going to be someone using elevated credentials to access something, but this way there is no state on a developers machine at any point for any of our production infra.
omegalulw 5y ago
> How do you provide your secrets to your apps? Using an external service? That would still require another set of credentials. Using environment variables? A file only the user running the app has access too? Another way? A credential/key storage service, either on device/server or as a separate device, with IAM to control whether the user executing that process can use that secret or not. The user in this case for prod services should be a prod (non-human) user. When all your services are like this, no person should have direct access. You generate key/secrets depending which services you want to allow to communicate with each other and the keys live in the key store. For secrets for external services, e.g. API keys, someone would have to enter them once, yes. You also should try not to rely on secrets, rather invest in proper authentication/authorization logic.
- Macha 5y ago
  There's a chicken and egg problem here. If you move your secrets to a secret management service, how do you provide the credentials to unlock to that? Whether it's on disk, in the environment or on an internal endpoint like IAM host roles there's ways for this to be exposed in the event of bugs or security vulnerabilities in your application
  - SomeCallMeTim 5y ago
    > in the event of bugs or security vulnerabilities in your application The article talks about keys being published as part of the web page configuration. That's far worse than "they could hack a server and gain its credentials!"
danenania 5y ago
Shameless plug, but we built EnvKey[1] for exactly this purpose. Instead of providing secrets directly to a server, you generate an ENVKEY token which is used to fetch and decrypt the app’s secrets/config and supply them as environment variables to the process. The ENVKEY still needs to be protected, but you can limit which IPs can access it and if access is cut off, the process will be killed and secrets cleared immediately, so you do get some additional protection. All access attempts are also logged. 1 - https://envkey.com https://envkey.com

3np 5y ago

Environment variables on the server side, sure, but having those end up in the client...? If you find that this is a relatable mistake, I hope you have someone with more experience reviewing your code and processes before they touch anything remotely sensitive in production... (Unless you're just trolling)

alias_neo 5y ago

The step they seem to be missing is _the entire development process_. If you're using API keys to access stuff, you do it on your backend, there's no excuse for that stuff to make it to the frontend. If your "client" needs access to sensitive API keys, you need to rethink your architecture. As a (senior) backend software engineer, this reeks of a person/team who doesn't know how to architect and/or implement web applications/software.

ratww 5y ago
Is is a bit more nuanced than that. This web client needs access to non-secret keys that are passed via environment variables. This is absolutely commonplace. However there are two real issues here: first, some bug in the code is causing all environment variables to be dumped into the JS bundle. You can see that in inane keys like PATH, HOME, PORT. This issue wouldn't be such a huge problem by itself. The second problem is that during the build process for the frontend, there are environment variables that shouldn't be there, such as the secret ones. The CI or build machine should have been well isolated enough to prevent this problem from happening. This is a problem in the CI coupled with a bad build process.
- greggsy 5y ago
  Great explanation - client side apps often seem to be a bit of a catch-22 in some cases.
  - danenania 5y ago
    It’s crucial to always use an allow-list approach to passing config through to a client.
    - ratww 5y ago
      Yep. Maybe just forbidding enumerating environment variables in the runtime would be enough for this case. However the CI shouldn’t have backend-only private variables available to frontend builds… some separation here would be safer regardless of developer mistakes.
_fat_santa 5y ago
According to the article, they were keeping their environment variables in React's local state. To anyone that works with React professionally, or even on the side, this is so baffling that a team would do this. I'm honestly wondering who they hired for the job. Because this is one of the most fundamental failings in security I've ever seen.
- ushakov 5y ago
  > I'm honestly wondering who they hired for the job let me guess: bootcamp graduates? whoever was the cheapest?
  - SomeCallMeTim 5y ago
    Or outsourced to the lowest bidder.
raxxorraxor 5y ago
Yeah, it shouldn't reach the client in any case. But providing secrets to applications isn't really a well solved problem in my opinion. Even if it is just an environment variable for the server process it could get exposed. If a clients needs an API key I would think to route the requests through the server and add the key information at that point, but I am not a web developer and not sure if that always scales for any use case.
- SomeCallMeTim 5y ago
  It's simply software engineering malpractice to have ever sent any of those keys to the client. There is no excuse. It is a well-solved problem to handle secrets; there are better and worse solutions. An environment variable for a server can get exposed if the server is hacked; a secret sent to a client is exposed the second the server goes live. One of these is much worse than the other. There are also better solutions than environment variables. A competent team would be aware of many options. Whoever coded this is not competent, full stop. It's not that they didn't finish; these services should never have accessed from the client at all.
akdor1154 5y ago
Being generous, it might also be a fuckup in implementing SSR... maybe. Still a fuckup though.

maccard 5y ago

> How do you provide your secrets to your apps? Using an external service? That would still require another set of credentials. Using environment variables? A file only the user running the app has access too? Another way? It sucks for a small team or for anyone who is trying to run a free tier, but terraform plus aws secrets manager or vault works really well. Using a db password as an example, for our app we generate a random password, store it in secrets manager, and our containers on fargate run with an iam role that allows access to that secret. Our state is stored in S3, and the infra is applied on commit to main with a terraform plan run on the merge request to main. Our biggest security vector is always going to be someone using elevated credentials to access something, but this way there is no state on a developers machine at any point for any of our production infra.

omegalulw 5y ago

> How do you provide your secrets to your apps? Using an external service? That would still require another set of credentials. Using environment variables? A file only the user running the app has access too? Another way? A credential/key storage service, either on device/server or as a separate device, with IAM to control whether the user executing that process can use that secret or not. The user in this case for prod services should be a prod (non-human) user. When all your services are like this, no person should have direct access. You generate key/secrets depending which services you want to allow to communicate with each other and the keys live in the key store. For secrets for external services, e.g. API keys, someone would have to enter them once, yes. You also should try not to rely on secrets, rather invest in proper authentication/authorization logic.

Macha 5y ago
There's a chicken and egg problem here. If you move your secrets to a secret management service, how do you provide the credentials to unlock to that? Whether it's on disk, in the environment or on an internal endpoint like IAM host roles there's ways for this to be exposed in the event of bugs or security vulnerabilities in your application
- SomeCallMeTim 5y ago
  > in the event of bugs or security vulnerabilities in your application The article talks about keys being published as part of the web page configuration. That's far worse than "they could hack a server and gain its credentials!"

danenania 5y ago

Shameless plug, but we built EnvKey[1] for exactly this purpose. Instead of providing secrets directly to a server, you generate an ENVKEY token which is used to fetch and decrypt the app’s secrets/config and supply them as environment variables to the process. The ENVKEY still needs to be protected, but you can limit which IPs can access it and if access is cut off, the process will be killed and secrets cleared immediately, so you do get some additional protection. All access attempts are also logged. 1 - https://envkey.com https://envkey.com