Well it's not exactly secure by default. I was deploying an app to a new server and some bot grabbed my .env file before I finished the Apache config.
Ultimately it's my own stupidity, but you don't have to worry about that with most other languages
You shouldn't deploy .env files to production. You should set the actual environment variables on production. .env files are intended for convenience on non-prod systems.
Agreed, but server frameworks shouldn't easily enable a foot gun that allows bots to have disk access to your host. Instead, only explicitly defined routes or resource files should be available.
If I had to guess, this person committed their .env file in some repo and pushed that up, and that become available because the server was misconfigured.
For other servers (such as, say, Jetty), config files like that won't get exposed like that unless you're very obviously placing your config files in a public resource folder.
Yes but that’s a framework specific issue. And usually your documentroot would point to a directory below that which holds .env. Oh the memories of apache and php.
The mere concept of a "document root" is a problem though and a major footgun if you don't know what you're doing.
Every other language acts as its own web server which wouldn't even be capable of serving files even if you tried; the only thing it does is respond to web routes defined by the application.
This eliminates a whole chunk of security issues, from the one described above to malicious file uploads (PHP is probably the only language where a malicious file upload leads to RCE by default - other languages could happily accept and serve the malicious file back but wouldn't execute it).
That has nothing to do with PHP. If you have .env files in your document root PHP didn't put them there or require them. Every web site back-end can expose .git directories or .env files if not configured correctly -- that has nothing to do with PHP except that way more people use PHP out of the box and don't know about these issues or how to fix them. That's analogous to way more teenagers crashing cars than more experienced drivers, but that has nothing to do with the particular cars.
shakesbeard|2 years ago
101011|2 years ago
If I had to guess, this person committed their .env file in some repo and pushed that up, and that become available because the server was misconfigured.
For other servers (such as, say, Jetty), config files like that won't get exposed like that unless you're very obviously placing your config files in a public resource folder.
gumballindie|2 years ago
Nextgrid|2 years ago
Every other language acts as its own web server which wouldn't even be capable of serving files even if you tried; the only thing it does is respond to web routes defined by the application.
This eliminates a whole chunk of security issues, from the one described above to malicious file uploads (PHP is probably the only language where a malicious file upload leads to RCE by default - other languages could happily accept and serve the malicious file back but wouldn't execute it).
tacker2000|2 years ago
zmxz|2 years ago
pwdisswordfishc|2 years ago
gregjor|2 years ago
eastern|2 years ago
The only way to avoid to have the server open only to you till everything is tied down right and the backend is ready to face the world.
To rely upon being quicker on the draw than the bots is quite courageous.
phendrenad2|2 years ago
unknown|2 years ago
[deleted]