-
Notifications
You must be signed in to change notification settings - Fork 42
Add CSRF middleware to enable CSRF protection #3396
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
base: master
Are you sure you want to change the base?
Conversation
|
1a2b897
to
a7105b7
Compare
98d6429
to
ecc8500
Compare
ecc8500
to
eaefa8f
Compare
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #3396 +/- ##
==========================================
- Coverage 60.87% 60.85% -0.02%
==========================================
Files 607 607
Lines 43953 43955 +2
Branches 48 48
==========================================
- Hits 26758 26751 -7
- Misses 17183 17192 +9
Partials 12 12 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While this PR in itself is just fine, there's a requirement that all of NAV's forms have been updated to work properly with CSRF before this can be merged.
I tested random parts of NAV's web UI with this branch checked out, and I did find at least one showstopper and one minor issue within 10 minutes of testing:
Showstopper
Netmap allows its view configurations to be saved in named views. It appears the forms to save new or update existing views do not include a CSRF token, causing all of them to fail. We should make an issue for this.
Minor issues
CSRF tokens are added to some GET-based forms, which should be unncessary. First, they do not modify anything, so they should be safe. Second, it looks pretty confusing to the user that the URL now includes a long hexadecimal string (which also makes the URL potentially less bookmarkable).
Specifically, I found the l2trace search form to do this (there might be more, since my tests haven't been exhaustive)
Yes, this was added in #3157, were it was mentioned that "there is no (reliable) way to check whether a Django form is a POST form thats why this redundancy is needed". |
Still not a good idea. Can it be turned off? Putting CSRF tokens in GET requests will leak those tokens in the server access logs, since they are part of the requested URL. |
At this point, I've identified and created issues for CSRF problems in at least 4 tools. These have all been linked to this PR. I suspect there may also be something with PortAdmin, but it will take me longer to test, since it requires me to set up working IPv6 in Docker to do the testing from my dev machine against our internal network. |
Closes Uninett/campus-tasks/issues/45.
Reference: https://docs.djangoproject.com/en/4.2/howto/csrf/
Reference for exempting views from needing a CSRF token: https://docs.djangoproject.com/en/4.2/howto/csrf/#disabling-csrf-protection-for-just-a-few-views
Dependent on #3366, #3367, #3384, #3387, #3388, #3389, #3390, #3391, #3394, #3395.