When your environment variables are showing

There are embarrassing moments in life. There is the teacher calling you out as a child in class as you stare out the window wistfully imagining you’re playing on the beach. There is the dream where you’re at work and you forgot to wear pants. Yes, I forgot ONE TIME, let’s just let that dark day pass into history shall we? But, one of the more amazing things is when your web application is horribly broken.

Behold, I give you the .env file. Typically this is a file that is used so you can load environment variables. The idea here is to store this information away from eh code base. OK, that part I get. As an example we could see this in a .env file.

DB_HOST=localhost DB_USER=root DB_PASS=password

I would hope to all that is good and holy that people do no literally use that example but, one can never be to sure so there, I said it. You never want to commit a .env to your repository but, unfortunately I was able to find examples where people did exactly that. Some examples of what people I discovered were using are, “db_password=db_password”, “DB_PASSWORD=admin123”, “DB_PASSWORD=admin” and the one that was set to “DB_USER=root DB_PASSWORD= ”. A blank password. No cookie for you.

Where I really slammed my head into my keyboard was when I did a search for sites that were serving up their .env files to the world. There were some funny examples but, none that was better than “DB_password=secret”. I couldn’t help but to giggle. I did find numerous examples of stored database passwords that were actually very good from a strength perspective. The wrinkle being that they don’t serve much purpose of I can pluck them from your site with a simple search engine query.

When you deploy something that is Internet facing you cannot simply assume that your systems are safe. You need to test that your applications are not coughing up unnecessary information. There is no shortage of companies that can provide you with that type of support. You need to have proper controls in place like a web application firewall (Full disclosure, I do work for Akamai in my day job) and ensure that you’re reviewing your code before pushing it to production. These are all preventable problems with the right amount of forethought. 

This reminds me of the CIO who once said to me, “Well we have a firewall so, we’re fine.” There is a need to conduct proper due diligence on your web properties. Sure, you can put security controls in place but, they can only help you to a certain point. They’re not able to protect you from yourself if you’re hell bent on cutting corners to save time and money in the short term.