New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[5.5] Add config option for whoops blacklist #21336

Merged
merged 1 commit into from Sep 23, 2017

Conversation

Projects
None yet
6 participants
@jpuck
Contributor

jpuck commented Sep 22, 2017

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 config/whoops.php file exists, the behavior is the same. If you would like this option, then one would just have to create the config file. If the PR is accepted, then perhaps a base config file could be added to the laravel installer too with some sensible defaults.

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:

whoops exception page

@jpuck jpuck changed the title from add config option for whoops blacklist to [5.5] add config option for whoops blacklist Sep 22, 2017

@GrahamCampbell GrahamCampbell changed the title from [5.5] add config option for whoops blacklist to [5.5] Add config option for whoops blacklist Sep 23, 2017

@taylorotwell taylorotwell merged commit c39faf7 into laravel:5.5 Sep 23, 2017

2 checks passed

continuous-integration/styleci/pr The StyleCI analysis has passed
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@jpuck jpuck deleted the MyTeamName:whoopsBlacklist branch Sep 23, 2017

@yajra

This comment has been minimized.

Show comment
Hide comment
@yajra

yajra Sep 27, 2017

Contributor

FYI to those implementing this. The config key is now app.debug_blacklist instead of proposed whoops.blacklist.

Contributor

yajra commented Sep 27, 2017

FYI to those implementing this. The config key is now app.debug_blacklist instead of proposed whoops.blacklist.

@jpuck

This comment has been minimized.

Show comment
Hide comment
@jpuck

jpuck Sep 27, 2017

Contributor

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

Contributor

jpuck commented Sep 27, 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..?

@TrieBr

This comment has been minimized.

Show comment
Hide comment
@TrieBr

TrieBr Mar 7, 2018

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

TrieBr commented Mar 7, 2018

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

@brajnacs

This comment has been minimized.

Show comment
Hide comment
@brajnacs

brajnacs Apr 24, 2018

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.

brajnacs commented Apr 24, 2018

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.

@KlodLula

This comment has been minimized.

Show comment
Hide comment
@KlodLula

KlodLula Jun 23, 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.
I tried myself the framework and think to apply it in my projects now on but please consider this as an issue of great importance because nobody cares sometimes of the exceptions or if there is no 404 page... until they realize the db password is shown there, which is a catastrophe!

Also other comments in Laracast: https://laracasts.com/discuss/channels/laravel/security-issue-no1-suggestion-masking-by-default-the-information-that-resides-in-env-file?page=1

By the way really great framework @taylorotwell

Thank You!

KlodLula commented Jun 23, 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.
I tried myself the framework and think to apply it in my projects now on but please consider this as an issue of great importance because nobody cares sometimes of the exceptions or if there is no 404 page... until they realize the db password is shown there, which is a catastrophe!

Also other comments in Laracast: https://laracasts.com/discuss/channels/laravel/security-issue-no1-suggestion-masking-by-default-the-information-that-resides-in-env-file?page=1

By the way really great framework @taylorotwell

Thank You!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment