SafeExceptionReporterFilter should obfuscate all variables in every stack frame below a function decorated with sensitive_variables

[nc...@cadre.com]

SafeExceptionReporterFilter obfuscates variables in the function decorated with sensitive_variables, but it does not obfuscate variables lower in the call stack, which could result in sensitive data being leaked in exception reports.

For instance:

@sensitive_variables('sensitive')

def decorated_function():

    sensitive = 'something sensitive'

    undecorated_function(sensitive)

def undecorated_function(var):

    raise Exception()

In this code, the "sensitive" variable will be obfuscated in the decorated_function stack frame, but "var" in the undecorated_function stack frame will not, resulting in the sensitive data being leaked in the report. If we wrote undecorated_function, then we can just decorate the function ourselves, but if it's from a third-party package, we are unable to decorate it.

The solution here is to obfuscate _all_ variables in all stack frames below a function decorated with sensitive_variables, since these functions can do arbitrary things with the sensitive data. I've written a custom SafeExceptionReporterFilter that does this for the company I work for, and I think it would be a good behavior to adopt in core Django.

Any thoughts or concerns with this approach?

This message, including any attachments, is a PRIVATE communication, which may contain confidential, legally privileged, and/or proprietary information.  If you are not the intended recipient, you are hereby notified that any dissemination, disclosure, copying, distribution or use of the information contained in or attached to this message is strictly prohibited.  Please notify the sender of the delivery error by replying to this message, and then permanently delete it from your system.  Unless explicitly stated to the contrary, nothing contained in this message shall constitute an offer to buy or sell, or a solicitation of an offer to buy or sell, any security, property interest or other asset, nor shall it constitute a binding obligation of any kind, an official confirmation of any transaction or an official statement of Cadre.  

Cadre may monitor, review and retain email communications traveling through its networks or systems, AND CADRE IS NOT OBLIGATED TO RESTRICT THE USE OR DISCLOSURE OF ANY INFORMATION SENT TO IT BY YOU VIA E-MAIL COMMUNICATION. 

[Tom Forbes]

My only concern is that it would greatly reduce the usefulness of the exception reporter, and might lead to people removing the sensitive_variables decorator in order to see exception tracebacks.

Perhaps rather than obscure all local variables below the decorated function, we could obscure any variable with the same *value* as a sensitively marked variable in the call stack? This would work better with strings than say dictionaries, but it could be a good middle ground.

Tom

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7376ab0c-530c-42d8-9cfb-6c829af21098%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nathan Villagaray-Carski]

The issue with obscuring any values that equal the sensitive variable is that functions can do arbitrary things to the data, e.g. splitting a name into first and last, combining first and last name strings into a full name, stripping whitespace, generating a SQL query with the sensitive data, etc. that would cause the value to be not equal but would still leak the sensitive data. For us (and I suspect most companies using sensitive_variables to obscure PII), the tradeoff of less useful stack traces is worth not sending PII to developers via email.

We could add a kwarg to the sensitive_variables decorator to opt in to this behavior, though I think the default behavior should be to obscure all variables below the decorated function, as the current implementation can easily leak sensitive data even when using the decorator.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJNPoU0S2_44S3frL4%2BdkjYqOXYEw%2BRP4-tT1z_Lx%2BuRqg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.