Opened 9 years ago
Closed 9 years ago
#26628 closed Cleanup/optimization (fixed)
Log CSRF failures to django.security instead of django.request
Reported by: | Jacob Kaplan-Moss | Owned by: | Holly Becker |
---|---|---|---|
Component: | CSRF | Version: | 1.9 |
Severity: | Normal | Keywords: | csrf security |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
It's currently possible to log CSRF exceptions with the 403 handler. But a more sensible default would be to log them by default. This would be an easy simple step that would make Django play more nicely with a SIEM
[One of a series of bugs from a discussion I had with @mallyvai about improving the security of Django's admin - see https://gist.github.com/mallyvai/bcb0bb827d6d53212879dff23cf15d03 for the full list.]
Change History (14)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:3 by , 9 years ago
Hi Tim,
Definitely think it's a good idea to add to the docs.
My original thinking was that it would be a more sensible default to log this as a security exception and use the django.security loggers (i'm not 100% sure about how that's wired up), since CSRF protections are meant to be explicit security measure. It seems to be logged as a generic logger.warning right now.
comment:4 by , 9 years ago
Component: | CSRF → Documentation |
---|---|
Resolution: | worksforme |
Status: | closed → new |
Summary: | CSRF violations should be logged → Document that CSRF violations are logged to the django.request logger |
Triage Stage: | Unreviewed → Accepted |
Type: | New feature → Cleanup/optimization |
comment:5 by , 9 years ago
Easy pickings: | set |
---|---|
Needs documentation: | set |
Owner: | changed from | to
Status: | new → assigned |
comment:6 by , 9 years ago
Summary: | Document that CSRF violations are logged to the django.request logger → Log CSRF failures to django.security by default. |
---|
Sergio Campos (seocam) and I were just discussing this same issue at the PyCon sprint (in the context of looking at the broader context in #26688). I'm inclined to agree with mallyvai that this isn't just a doc bug -- we should be logging CSRF failures to django.security by default. Updating the ticket title accordingly -- please let me know if you don't agree, or think this should be discussed on the mailing list.
comment:7 by , 9 years ago
Are you concerned at all about backwards-compatibility in the case of some custom logging configuration?
comment:8 by , 9 years ago
I guess I'm not too concerned about back-compat, because it seems it would only be an issue in a case where someone has configured logging to watch django.request
but ignore django.security
, which seems like a pretty strange choice. But I also don't feel strongly. I'd be inclined to merge the doc fix that Hwesta has already submitted (https://github.com/django/django/pull/6694/files) but as a Refs
, and leave this open for further discussion of the actual logger change.
comment:12 by , 9 years ago
Component: | Documentation → CSRF |
---|---|
Has patch: | set |
Needs documentation: | unset |
Patch needs improvement: | set |
Summary: | Log CSRF failures to django.security by default. → Log CSRF failures to django.security instead of django.request |
PR with comments for improvement.
comment:13 by , 9 years ago
Patch needs improvement: | unset |
---|
The
CsrfViewMiddleware
does have logging for rejected requests. Is this insufficient? I couldn't find this mentioned in the documentation so that could be added, at least.