Skip to content
New issue

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

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

Already on GitHub? # to your account

Sensitive data exposed in logs and debugging toolbar #3619

Closed
acehead opened this issue Jan 11, 2019 · 7 comments
Closed

Sensitive data exposed in logs and debugging toolbar #3619

acehead opened this issue Jan 11, 2019 · 7 comments

Comments

@acehead
Copy link

acehead commented Jan 11, 2019

One of the main intentions of 3.1 is to move sensitive data from database into environmental variables referenced from project config.

The side effect here is that the values of environmental variables (including keys and passwords) are exposed at least in

  • Logs
  • Yii2 debug panel

They are masked in PHP info though.

Is it an expected beahviour and are there any plans to mask sensitive data all across the Craft?

@brandonkelly
Copy link
Member

Can you provide specific examples of where you’re seeing sensitive data in the logs / Debug toolbar?

@jwb009
Copy link

jwb009 commented Jan 16, 2019

I just noticed this too but I'm not on 3.1 yet. In phperrors.log my 'SECURITY_KEY', 'S3_API_KEY, 'S3_SECRET' and 'DB_PASSWORD' are exposed in plain text. In web.log these same values are replaced with ••••'s.

@acehead
Copy link
Author

acehead commented Jan 16, 2019

@jwb009 exactly. I was testing on 3.0 as well, not sure this behavior changed in 3.1.
Another place where you can see real environment variable values is Yii Debug Toolbar. You can find them by maximizing debug toolbar in CP -> select any of the recent requests -> Request on the left menu -> $_SERVER tab

@brandonkelly
Copy link
Member

Thanks. I was able to override the Request panel to redact any sensitive info within it.

We don’t have any control over what gets logged to storage/logs/phperrors.log, but I just added support for a new CRAFT_LOG_PHP_ERRORS PHP constant you can set from index.php to prevent Craft from forcing PHP errors to be logged there in the first place.

// Don't send PHP error logs to storage/logs/phperrors.log
define('CRAFT_LOG_PHP_ERRORS', false);

@andrelopez
Copy link
Contributor

Hey @brandonkelly checking some client logs, I noticed that for the following log:

[web.INFO] [application] Request context:

Under $_SERVER = [ craft displays all env variables, however, my client was storing sensitive data like the Stripe secret key with the following name:
STRIPE_SK_LIVE
and is displaying as plain text, I tried locally and I was able to recreate the issue also, if I change the name to something like:
STRIPE_SK_LIVE_KEY
Stops showing the plain text and now shows a secret like: ••••••••••••••••••••••••••••••••••••••••

I was trying to find docs related to naming env files as secrets but I haven't had luck.

Is this an expected behavior? What is the recommended naming to store secrets on the env file and prevent plain text on the logs?

brandonkelly added a commit that referenced this issue Sep 9, 2023
@brandonkelly
Copy link
Member

brandonkelly commented Sep 9, 2023

Craft will automatically redact environment variables that look sensitive based on the variable name, via this list of sensitive-sounding keywords:

cms/src/config/app.php

Lines 118 to 126 in 43ee7a7

'sensitiveKeywords' => [
'key',
'pass',
'password',
'pw',
'secret',
'tok',
'token',
],

I just added SK to that list for the next v3 and v4 releases.

Worth noting that it’s not a perfect solution: there are still ways that sensitive environment variables could be logged out that Craft doesn’t have any control over, as well as phpinfo(). Which is why we added secrets support in Craft 4.5, which provides a more secure way of defining sensitive environmental values.

@brandonkelly
Copy link
Member

Craft 3.9.2 and 4.5.4 are out with SK added to the sensitive keywords list.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants