search

laravel / framework

The Laravel Framework.
https://laravel.com
MIT License
32.41k stars 10.99k forks source link

Dot-env variables easily exposed #18492

Closed hakuno closed 7 years ago

hakuno commented 7 years ago

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 commented 7 years ago

What's the issue?

hakuno commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

sisve commented 7 years ago

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: https://github.com/vlucas/phpdotenv/issues/124

You need to config cache first. Not a bug. We don't expect it to work if you forget to do that. Source: https://github.com/laravel/framework/issues/13906#issuecomment-224293233

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: https://github.com/vlucas/phpdotenv/issues/76#issuecomment-167806230

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: https://github.com/vlucas/phpdotenv/issues/76#issuecomment-224899197

bappy004 commented 6 years ago

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

sisve commented 6 years ago

@bappy004 Switch to Laravel.

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

bappy004 commented 6 years ago

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 commented 6 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

PieterjanDeClippel commented 5 years ago

@tufanbarisyildirim You're retarded

ludo237 commented 5 years ago

@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 commented 5 years ago

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