Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[5.5] Add config option for whoops blacklist #21336
Sometimes I'm not the only one looking at my development work. As I'm working on a project, I will often show little previews of what I'm working on. Even within my local network, I will have someone checkout my dev site from their machine. It's not always convenient to spin up a test site for these previews. I don't want to expose some secrets to these folks if an exception is thrown, or others who might be looking over my shoulder.
This PR leverages Whoops's built-in blacklisting ability to mask certain variables. It is backward compatible in that if no
For example, given this config:
return [ 'blacklist' => [ '_ENV' => [ 'APP_KEY', 'DB_PASSWORD', 'REDIS_PASSWORD', 'MAIL_PASSWORD', 'PUSHER_APP_KEY', 'PUSHER_APP_SECRET', ], '_SERVER' => [ 'APP_KEY', 'DB_PASSWORD', 'REDIS_PASSWORD', 'MAIL_PASSWORD', 'PUSHER_APP_KEY', 'PUSHER_APP_SECRET', ], '_POST' => [ 'password', ], ], ];
Results in this output:
Sep 23, 2017
@yajra indeed I noticed that a83ebc1 too. should put something in the docs, I guess, but maybe too trivial? in the meantime if anyone goes specifically searching, then hopefully they'll find the answer on stack overflow: https://stackoverflow.com/a/46407010/4233593
also, I'm not sure what thoughts there are on including some defaults in the laravel/laravel installer..?
Personally, I would like to see the default installation hide all environment variables by default. I really don't see any point in exposing environment variables and creating a security risk when the developer can easily just open up their .env file and view the variables. It should be an opt-in feature rather than opt-out in my opinion.
I completely agree with @TrieBr. Exposing environment variables is such a big issue that it may put your whole security checklists and practices in the trash within a second.
Moreover, rather than blacklisting we should have a whitelist config as blacklisting in security doesn't sound good and it does not align with the spirit of "Principle of least privilege". One may forget to put sensitive variables in blacklist as the project grows.
referenced this pull request
Jun 22, 2018
Hi I'm a professor of programming languages and I'm sure a lot of people have requested this to be default and I would only suggest to take into consideration the fact that one of my students risked maybe the jail by forgetting to disable the dev mode configuration in the .env file.
By the way really great framework @taylorotwell
Yeah, this is a nightmare.
Steps to reproduce:
How is that acceptable as the default behaviour?
It's unfourtunate that whoops package doesn't yet support whitelisting or even just hiding the variable section.
For now I've made a package to destroy the variables before they get to Whoops handler. The approach is rather blunt but at least I can now configure the displayable fields in either whitelist or blacklist manner. And it doesn't reveal the string length with asterisks. And can completely remove fields.
I've taken a different approach to masking sensitive data with this package, Fuko\Masked: you "declare" all the passwords and tokens and sensitive data you have and then all of that will be redacted out of any variables you pass. In this way you do not have to worry where your passwords might pop up in any of the dumps you create. I'll appreciate the feedback