#12738 closed Cleanup/optimization (wontfix)
CSRF token name should be a configurable setting
| Reported by: | German M. Bravo | Owned by: | nobody |
|---|---|---|---|
| Component: | CSRF | Version: | |
| Severity: | Normal | Keywords: | |
| Cc: | German M. Bravo | Triage Stage: | Unreviewed |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
The CSRF token name ('csrfmiddlewaretoken') should perhaps be configurable, for security reasons if not anything else...
Attachments (1)
Change History (6)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
No response, so I presume there is no use case, so closing.
comment:4 by , 13 years ago
| Cc: | added |
|---|---|
| Easy pickings: | unset |
| Severity: | → Normal |
| Type: | → Uncategorized |
| UI/UX: | unset |
by , 12 years ago
| Attachment: | #12738-csrf_token_url_name_configurable.diff added |
|---|
comment:5 by , 6 years ago
| Component: | Uncategorized → CSRF |
|---|---|
| Type: | Uncategorized → Cleanup/optimization |
A PR implemented this with rationale "Wappalyzer identifies Django application with "csrfmiddlewaretoken" input name."
I wrote to django-developers to see if there's consensus to reopen this ticket.
Note:
See TracTickets
for help on using tickets.
I don't understand why that would improve security. The security lies in the value of the token, not the name. Most CSRF attacks are going to be per-site, and a setting would be per-site. Also, if an attacker was using a more generic attack against all Django-powered sites, it would be easy to find out what the name of the token is for a specific site - one request to a page that contains a POST form, and you are done, since a simple regex will in most cases find which field 'looks like' a Django CSRF token.
Do you have an actual use case where you need this?