Hi Stephan,
I'm also interested to understand why I should have some form of CSRF
protection for my wsgi app...
perhaps recoding the Django 1.11 CSRF middleware into a proper WSGI
application (CSRFController) would help.
but seriously, i don't use/recommend the Django CSRF middleware because
it does not improve security of forms processing.
cheers,
Etienne
Le 2018-01-15 à 17:03, Stephan Doliov a écrit :
Just curious, I recently went on a source code studying binge and took
a look at the CSRF middleware that comes with Django. I appreciate the
work and effort of the authors, but I am not sure I gain anything by
deploying it to my site. Here is why:
The middleware token assigned to a form and to a csrftoken cookie are
ciphertexts of the same underlying key (by default, the underlying key
is chosen as 32 randomly chosen (with replacement) chars from a set of
62 chars. So the easy workaround can be done in one of two ways
1) Write a script that just harvests the middleware token from a form
"protected" with such token and use the value of that as the csrftoken
cookie.
As the middlewaretoken is a cipher of the underlying token, obviously
using the the same string as the value to the csrftoken cookie will
satisfy the middleware's demand for authorization of the resource
(e.g. POSTing to the form)
2) Learn the easy cipher algorithm the csrf middleware uses and
present a csrf token cookie that will decode to the right value.
In either case, I am not convinced that meaningful protection against
CSRF types of requests are provided by the middleware. Am I missing
something?
Wouldn't it be more secure to just have middleware that whitelists as
a series of origins (aka CORS) and then, unlike CORS, actually perform
reverse lookups on the dns of the whitelisted domains? (Of course,
this assumes that the hosts that might want to make cross-site
requests ahve access to managing their reverse DNS).
Am I missing something; or, if serving performance is a top goal of
mine, should I just ditch the csrf middleware? (and maybe rate limit
client requests to prevent DoS attacks)?
Thanks,
Steve
--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-users+unsubscr...@googlegroups.com
<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to django-users@googlegroups.com
<mailto:django-users@googlegroups.com>.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/9c4a794f-aa9e-4c00-ba20-779ad7a87d2a%40googlegroups.com
<https://groups.google.com/d/msgid/django-users/9c4a794f-aa9e-4c00-ba20-779ad7a87d2a%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
Etienne Robillard
tkad...@yandex.com
https://www.isotopesoftware.ca/
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/95bba86c-ed2e-fd8d-e7da-2ec1b80c273c%40yandex.com.
For more options, visit https://groups.google.com/d/optout.
