How to not show the Environment Variables section?

[garygreen]

I would like to get rid of the environment variables section, as I find it a huge security risk if you accidentally leave debug turned on in production then the user may be able to see all passwords for your environment.

Is there an easy way to tell whoops to not render the environment vars?

[GrahamCampbell]

@garygreen A solution to this is to not install whoops on the production server. Make it a dev-dependency.

[GrahamCampbell]

Then, even if we leave the server in debug more by mistake, we still don't try to use whoops: https://github.com/GrahamCampbell/Laravel-Exceptions/blob/master/src/Displayers/DebugDisplayer.php#L79.

[garygreen]

@GrahamCampbell that's a pretty good solution. To be fair though it would be cool if you could disable certain sections in whoops. I pretty much never use the environment vars section anyway

[garygreen]

Not sure if whoops plays a role in monolog, would it report less information to e.g. bugsnag if whoops not included?

[GrahamCampbell]

I use bugsnag through my exceptions package, so it's separate from this. :)

[denis-sokolov]

I have a strong position that we do not support running PrettyPageHandler in production.

If we were to implement any such filtering out features, like hiding environment variables, there would still be plenty of exposed information through the code display, stack, and whatever more.
Do not run PrettyPageHandler in production.

Wherever in your code a debug flag is set, add a safeguard instead:

if ($debug && !serverNameMatchesDev()) {
  die('Unexpected debug on production');
}

[tontonsb]

I have the same problem but it's not production. It's just developing on virtual servers that are accessible on the internet.

Currently if I just set up an empty Laravel application with default settings (debug enabled) and it crashes, the database credentials are dumped publicly. How is that acceptable as the default behaviour?

[PieterjanDeClippel]

Don't bother. I asked them the same question and they immediately go to defense mode.

The only thing you can do is like this: https://github.com/PieterjanDeClippel/LaravelProjects/commit/b27549998385a351085594c79e0a3c5f32ca7103#diff-c136564e81b15005cc82fac61a00ce9f

You may try to convince them that some virus can become active inside your network, creating a connection to a remote server. Once this succeeds, it can just search for a webpage on a private server which throws a 500 error and the hacker immediately knows your password. What would be the expected response? They'll just blame you instead of tightening the security breach in the framework...

The only suggestion I can make at this point:

1. Don't count on the goodwill of the developers and organize 2 environments (either 2 real servers where 1 is totally private and 1 is public, or 1 public server and a homestead environment)
2. Set the configuration I embedded in my GitHub commit. It's already SOME kind of extra security...
3. Use totally different credentials for public vs private development. Like SMTP-email address also different (how annoying would that be)

In the case of your public virtual environment, basically the only thing you can do is set the config as of in the GitHub-link mentioned above, If you're fine with hackers knowing only the length of your SQL-password.

[PieterjanDeClippel]

I told my collegues at work that Laravel prints passwords on a webpage and they immediately started laughing 😆

[tontonsb]

I ended up creating a package that hides variables from output - https://github.com/GlaivePro/Hidevara

[staabm]

hiding the env-information for security reasons gives you a false-sense of safety/security.

the whoops error page contains very sensitive information. in case you show it to anyone which is not a developer of the app you should consider this a security risk.

[PieterjanDeClippel]

Printing the environment variables on a HTML webpage in any fashion is a security risk...

[tontonsb]

What do you mean by "very sensitive information"? We use it because it shows the scripts where the error occured. If you refer to that information as "very sensitive", I just disagree as I don't want to hide my source.

[staabm]

most people which try to hide some information of the PrettyPageHandler pages do so, because they use it in public facing websites. Even if you hide the ENV information, the system is at risk in this case.

[PieterjanDeClippel]

I know but at least they can't hack my network from inside with a virus and immediately know my SQL-password. At least that one is obscured, wheter or not it's a different password from the one on the public server...

[bendubuisson]

Printing the environment variables on a HTML webpage in any fashion is a security risk...

It's a debugging tool...

[JohnnyWalkerDigital]

@bendubuisson Yes, but it's so useless for debugging that Ignition (the successor to the original Whoops output) doesn't do it.