> (3) it's provided in an environment variable (no better than before)
Even if you take no measures beyond simply using a token that can be exchanged for secrets (and you can – invalidate it, authenticate it, etc.), you’re already doing better than before, because the token isn’t useful to an attacker without access to the secret store, whereas something like a JWT secret key is very useful.
Thanks, I can see how invalidating the token after first use, or after a short time period, reduces the exploit possibilities. (If all upstream service providers that you depend on were perfect, this could be arranged separately for each JWT that you need, but they aren't perfect.)
> authenticate it
> the token isn’t useful to an attacker without access to the secret store
If it's not a bearer token (that is, if you need to provide some additional credentials to authenticate it to the secret store) then any such additional authentication would need to be passed in somehow. Are you maybe assuming that in the environment where the app runs, some subsystem will have already installed a credential for some suitable IAM security principal? Because in that case, I certainly agree that it's better to anchor everything off that. That covers many cases (including every cloud) but not, e.g., rented plain VPSes or a couple of servers in your own basement.
Combined with “do not mix declarations and code”, this could be a strict C89 compatibility thing (not that I think that these standards are a good idea either, even with that less arbitrary justification).
Slop article. Good for scam awareness I guess, but the main value of the analysis and advice is comedy.
> read process.env directly, which in this app means MONGO_URI, JWT_SECRET, SENDGRID_API_KEY, CLOUDINARY_API_SECRET, PAYTM_MERCHANT_KEY
yeah it can run arbitrary malicious code, but let’s also highlight that it can read the fake app’s own dummy environment variables
> When the victim connects out to […], the server sees the source address on the accepted socket, exactly as any web server sees a visitor’s IP. No discovery, no scanning, no registration of an address. This is precisely why outbound-only design is so convenient for the attacker: it works behind NAT, CGNAT, a corporate proxy, or a home router with zero configuration, and it doesn’t matter if the victim’s IP changes.
huge
> If there is no UI/Desktop environment the module for leaking browser data or screenshots is self-limiting.
yeah this is why a VM is important, it’s because it doesn’t have a UI so screenshots don’t work
> … and reinstall your OS - better safe than sorry.
yeah just for thoroughness’s sake after having a RAT installed (hopefully you didn’t do this step last)
reply