Skip to content
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

Leaking secrets in production logs #35421

Closed
Medvezo opened this issue Feb 26, 2019 · 2 comments
Closed

Leaking secrets in production logs #35421

Medvezo opened this issue Feb 26, 2019 · 2 comments

Comments

@Medvezo
Copy link

Medvezo commented Feb 26, 2019

Steps to reproduce

Rails has the following line in the config/environments/production.rb:

# Use the lowest log level to ensure availability of diagnostic information
# when problems arise.
config.log_level = :debug

Here is what's inside config/initializers/filter_parameter_logging.rb file:
Rails.application.config.filter_parameters += [:password, :_token]

Expected behavior

The problem is that Rails leaks tokens, hashed passwords, and other sensitive details that shouldn't really be in production logs. Using Rails.application.config.filter_parameters only partially solves the problem since it doesn't filter secrets from SQL queries (Only shown when config.log_level = :debug).

I could understand the rationale behind this decision, but some companies use third-party log aggregation tools or simply store logs in S3/Glacier storage, which in turn might expose them to liability under the GDPR.

I think Rails should provide sane defaults out of the box and having :debug log in production is not one of it.

P.S. I can provide logs if you want to see it for yourselves. Heck, I have noticed that even :info leaks some secrets.

System configuration

Rails version: 6.0.0+ (I think 5.2.2 also defaults to :debug in production logs)

@jlduran
Copy link
Contributor

jlduran commented Feb 26, 2019

I think this is by design 😅

Now, seriously, if you do not want sensitive information in your logs, just set the log_level to :info.

Otherwise, you can use something like this hack in an initializer. Here, the attribute password_digest is filtered:

module ActiveRecord
  class LogSubscriber < ActiveSupport::LogSubscriber
    def render_bind(attr, value)
      if attr.is_a?(Array)
        attr = attr.first
      elsif attr.type.binary? && attr.value
        value = "<#{attr.value_for_database.to_s.bytesize} bytes of binary data>"
      end

      # XXX: Use require "active_support/parameter_filter"
      if attr.name == 'password_digest'
        value = '[FILTERED]'
      end

      [attr && attr.name, value]
    end
  end
end

Related to: https://www.bleepingcomputer.com/news/security/github-accidentally-recorded-some-plaintext-passwords-in-its-internal-logs/

@rafaelfranca
Copy link
Member

Yes, this is by design. If debug doesn't fit your requirements you are free to change the level of the logs.

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

No branches or pull requests

3 participants