On 29/05/11 05:22, Julien Phalip wrote:
> Recently I've been a bit embarrassed to receive a 500-error email
> report containing a client of mine's password displayed in clear
> because the admin login view had encountered an unhandled exception.
> This is probably OK in a debug environment but in production this can
> potentially have damaging consequences when handling passwords, credit
> card numbers, etc. It may also go against certain policies and
> standards such as the PCI-DSS (http://en.wikipedia.org/wiki/
> Payment_Card_Industry_Data_Security_Standard).
>
> There is already an open ticket to address this issue:
> https://code.djangoproject.com/ticket/14614
>
> I first wrote a patch allowing a lot of granularity to control which
> POST/GET parameters should get obfuscated when producing the error
> logs:
> https://code.djangoproject.com/attachment/ticket/14614/14614.obfuscate-request-parameters.diff
>
> Russell pointed out that this implementation approach was overly
> complicated. It also doesn't address the stack frame variables being
> logged in some situations. So I've posted another patch with a more
> radical approach, where all stack frame variables and the request's
> information are systematically and entirely omitted from the logs for
> exceptions occurring in views marked with the @sensitive decorator:
> https://code.djangoproject.com/attachment/ticket/14614/14614.sensitive-request.diff
I think we probably do need to provide something here. I'm concerned
that a 'sensitive' decorator puts the decision in the hands of the app
writer, which may well not be appropriate. For example, in one case I'm
involved in, half of the data entered in the admin in sensitive to some
degree, but my ability to debug errors could be seriously hindered if
the whole thing had 'sensitive' slapped on it. (Thankfully, the data
isn't too critical, and it is enough that I just delete the error
e-mails once I've dealt with them).
So, the 'sensitive' decorator might be appropriate for login, and
possible some other views, but I'm concerned it is still going to leave
other important situations with no practical solution.
Would it possible to make the sensitive decorator add some kind of
strategy object to the request, which itself is responsible for the
filtering, rather than a simple boolean flag? The strategy object
interface might be:
class ExceptionReporterFilter(object):
def show_request(self, request):
# return True or False
def filter_request_POST(self, request, post_dict):
# if show_request is True, this is passed request.POST
# and returns a sanitised version
def show_traceback(self, request):
# True or false
def show_traceback_vars(self, request):
# called only if show_traceback() returns True
def filter_traceback_vars(self, request, tb_frame, vars):
# filters vars to be shown at each level.
OK, could get carried away there - maybe we should start simple, e.g.
just 'show_request' and 'show_traceback_vars'. But something like that
would allow us to provide a working 'sensitive' decorator, but with a
mechanism that allows for something more fine-grained, and allows us to
add more features to it easily in the future. For the admin and CBVs it
would work as well, since there are always places you can override a
method and attach something to the request object.
If I'm thinking correctly, with an additional method like
'filter_settings', it might be possible to have a default
ExceptionReporterFilter that does the filtering of settings that is
currently hardcoded into django/views/debug.py.
Regards,
Luke
--
"The truth will set your teeth free." (Calvin and Hobbes)
Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
