Dot-env variables easily exposed

[hakuno]

• Laravel & Lumen Version: 5.4
• PHP Version: 7
• Database Driver & Version: pgsql 9

Description:

1. Time ago, a Laravel's error exposed my database credential. (Yes, I refer about those erros with "thrown exceptions" while APP_DEBUG is true).

2. Now, my Lumen has DB_PASSWORD at $_SERVER in.

So... how do I avoid these security issues? Should dot-env variables be there?

Thanks in advance.

Steps To Reproduce:

dd($_SERVER)

[deleugpn]

What's the issue?

[hakuno]

The former. Database password must not be shown in debug error or whatever.

The latter sounds developer driven as usual.

Ps.: about the nº 1, is it all related to APP_DEBUG variable and just? Is that my blame?

Sorry.

[deleugpn]

Your description of 1 seems like a leak in the debug backtrace. So, yeah, you shouldn't be running production with APP_DEBUG on.

Still don't understand why you care about 2, though.

[hakuno]

Nice.

IMO, all the world has warned us about the "globals". So I couldn't call the variable globally ($_SERVER["DB_DATABASE"]), but through its own object (env function) and just.

It's the purpose, isn't?

Thanks.

[hakuno]

In fact, I see no code bug. Maybe some security tips are needed for understanding.

[sisve]

You must php artisan config:cache to disable the loading of .env and the setting process-wide environment variables. Thus they won't show up in $_SERVER, $_ENV or other superglobals.

Exception handling tools such as filp/whoops are dumping $_SERVER, possibly disclosing critical information put there by phpdotenv.
Related: vlucas/phpdotenv#124

You need to config cache first. Not a bug.
We don't expect it to work if you forget to do that.
Source: #13906 (comment)

Starting in laravel 5.2, we only use dotenv to populate the config cache, then we don't load the environment on any requests. I recommend everyone does something like this.
Source: vlucas/phpdotenv#76 (comment)

ONLY use env inside your config files, and then you MUST use the cache command to setup the config files. Then there are ZERO env issues in production.
Source: Source: vlucas/phpdotenv#76 (comment)

[bappy004]

since
php artisan config:cache
doesnt work for Lumen, what is the recommended procedure for this for lumen ?

[sisve]

@bappy004 Switch to Laravel.

https://twitter.com/taylorotwell/status/897213319723048960

[bappy004]

Hi @sisve thanks for the suggestion. However, switching to Laravel seems a bit extreme just to mitigate this dotEnv potential issue. Any other suggestions?

[sisve]

@bappy004 Avoid using the .env file. Instead, modify the configuration files directly.

The root cause is that dotenv will set entries in $_SERVER, and the only way to avoid it is to avoid using dotenv, and thus the .env file.

https://github.com/vlucas/phpdotenv/blob/54d599d414f8cf3f6129e287acaf44b610486aa1/src/Loader.php#L386

[PieterjanDeClippel]

This can't be true...
I noticed this HUGE security breach yesterday.

When you accidently forget to set APP_DEBUG to false
all of your application passwords, keys and usernames are plainly exposed to the entire world
and the answer to this breach is "Well, you shouldn't set 1 simple configuration variable to true huh?".

That's just enough convincing for website owners to ditch Laravel and go for one of the like 200 other MVC frameworks (think of codeigniter, symphony itself, yii, CakePHP, and so on, and so on)

Why don't you just remove the .env variables from the Whoops page by default (and yeah, entirely)?
You'd be making 95% of your users happy.
For the other 5% who are too lazy to just locate and open the .env file, you can still add a, I don't know, I_AM_LAZY environment variable.

Problem solved?

[tufanbarisyildirim]

This can't be true...
I noticed this HUGE security breach yesterday.

When you accidently forget to set APP_DEBUG to false
all of your application passwords, keys and usernames are plainly exposed to the entire world
and the answer to this breach is "Well, you shouldn't set 1 simple configuration variable to true huh?".

That's just enough convincing for website owners to ditch Laravel and go for one of the like 200 other MVC frameworks (think of codeigniter, symphony itself, yii, CakePHP, and so on, and so on)

Why don't you just remove the .env variables from the Whoops page by default (and yeah, entirely)?
You'd be making 95% of your users happy.
For the other 5% who are too lazy to just locate and open the .env file, you can still add a, I don't know, I_AM_LAZY environment variable.

Problem solved?

This is like forgetting your FTP on public/anonymous access mode and then yelling at a developer like WHY DON'T YOU JUST REMOVE ALL PHP FILES FROM FTP TO KEEP US SECURE?

@PieterjanDeClippel just delete your files, that will keep you far from security risks in being a website/webapp owner.

[devcircus]

The security concern here, is using debug mode in production.

[ludo237]

@tufanbarisyildirim You're retarded

Well shame on you by leaving APP_DEBUG true in production also Laravel now provides a handy config file to explicitly exclude certain variables from debug so you can leave APP_DEBUG on true and test in production without problems 😉

[driesvints]

@PieterjanDeClippel please refrain from name calling and be polite to other developers.
@tufanbarisyildirim Please keep it civil and only reply if you have something positive to contribute to the conversation.

Going to lock this thread down as this has gone off topic too much.