Logging Sensitive Information in Rails: What Not to Log (CWE-532)

Logging is a crucial part of any application development and maintenance. It provides insights into the application’s behavior, helps in debugging issues, and offers a trail of events. However, logging can also become a significant security vulnerability if not handled carefully. One such vulnerability is CWE-532, the logging of sensitive information. In this post, we’ll explore what CWE-532 is, why it’s a problem in Ruby on Rails applications, and how you can prevent it.

What is CWE-532?

CWE-532: Insertion of Sensitive Information into Log File is a common weakness where applications log sensitive data such as passwords, credit card numbers, personal identification numbers (PINs), or other personally identifiable information (PII). This can happen unintentionally, but it poses a severe security risk. If log files are compromised, attackers can gain access to this sensitive data, leading to privacy breaches, identity theft, and financial loss.

The Risks of Logging Sensitive Information

Log files are often less protected than the application’s primary database. They might be stored in plain text, aggregated in less secure logging services, or accessed by a broader range of personnel. If sensitive information is present in these logs, it increases the attack surface of your application.

Consider a scenario where a user’s password is logged during a failed login attempt. If an attacker gains access to these logs, they can use the captured password to compromise the user’s account and potentially other systems where the user might have reused the same password.

How to Prevent Logging Sensitive Information in Rails

Ruby on Rails provides several mechanisms to filter sensitive information from logs. Here are the most effective methods:

1. config.filter_parameters

Rails has a built-in mechanism to filter sensitive parameters from log files. You can configure this in your config/initializers/filter_parameter_logging.rb file. By default, Rails filters out passwords, but you should add any other sensitive parameters your application uses.

# config/initializers/filter_parameter_logging.rb

Rails.application.config.filter_parameters += [
  :password,
  :credit_card_number,
  :cvv,
  :ssn
]

When you add a parameter to filter_parameters, Rails will replace its value with [FILTERED] in the log files. This applies to parameters in request URLs as well.

2. Filtering Parts of Parameters

Sometimes, you might need to filter only a part of a parameter. For example, if you have a parameter that contains a mix of sensitive and non-sensitive data. You can use a proc to define custom filtering logic.

# config/initializers/filter_parameter_logging.rb

Rails.application.config.filter_parameters += [
  ->(key, value) {
    value.gsub!(/secret-key-\d+/, '[FILTERED]') if key == 'token'
  }
]

3. Active Record Attribute Filtering

In Rails 6 and later, you can also filter sensitive attributes directly in your models. This is particularly useful for attributes that you want to protect from being logged when the model is inspected or converted to a string.

You can use the filter_attributes class method in your model:

# app/models/user.rb

class User < ApplicationRecord
  filter_attributes :password, :ssn
end

Now, when a User object is inspected, the values of the password and ssn attributes will be replaced with [FILTERED].

What to Do If You’ve Already Logged Sensitive Information

If you discover that you have already logged sensitive information, you need to take immediate action:

1. Identify and Remediate: Identify the code that is logging the sensitive information and apply the filtering techniques described above to prevent it from happening again.
2. Clean Up Logs: Review your existing logs and remove the sensitive information. This might involve manually editing log files or using scripts to automate the process. If you are using a log management service, consult their documentation on how to delete or redact logged data.
3. Assess the Impact: Determine the extent of the data exposure. Identify what information was logged, for how long, and who might have had access to it.
4. Notify Affected Users: Depending on the nature of the sensitive information and your legal obligations, you may need to notify the affected users.

Conclusion

Logging is an essential tool for developers, but it must be handled with care to avoid security vulnerabilities. In Ruby on Rails, preventing the logging of sensitive information (CWE-532) is straightforward with the built-in filtering mechanisms. By regularly reviewing your logs and being mindful of what you are logging, you can protect your users’ data and enhance the security of your application.

Stay vigilant, filter your parameters, and keep your logs clean!