Hacker News new | ask | show | jobs
by 1023bytes 1009 days ago
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
6 comments

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).

> The mere concept of a "document root" is a problem though and a major footgun if you don't know what you're doing.

A non issue though after 2-3 days of working with this approach. All modern PHP frameworks have a so called front controller (an index.php file) that loads what it requires from ../ after, ideally, properly validating the request to avoid issues.

> A non issue though after 2-3 days of working with this approach.

Tell that to all the people with bleeding feet.

Your comment makes no sense. How is that framework or PHP specific? Its simply a misconfiguration the server.
Some frameworks in the old days of PHP relied on .htaccess files to restrict access to unwanted files. Properly implemented frameworks would load everything from a directory above the documentroot to avoid these issues.
.htaccess is a config file type used by the Apache web server.

The server software reads the config file and then decides if the folder can be accessed externally or not.

It has nothing to do with PHP what framework or any other language you are running.

> .htaccess is a config file type used by the Apache web server.

Yup. That's why I am saying that in the past .htaccess used to be used, but modern php frameworks no longer rely on it. Poor phrasing on my end.

So it wasn't the language, it was you? But it was the language?
Just like in C, where every buffer overflow bug is the programmer’s fault.
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.
This, or variations, can happen with every kind of backend.

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.

If you apply the same level of thoughtlessness to any other framework, I assure you bots will grab your config also.