Hi, > 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.
You visit web site A (the attacker). Web site A wants to send a malicious POST request to site D (a Django app). The thing is that scripts of web site A don't have access to forms of site D, so they can't get the csrf token. > 2) Learn the easy cipher algorithm the csrf middleware uses and present a csrf > token cookie that will decode to the right value. This is not possible. You can't decode such ciphered messages. If S is the original message and C = F(S) the ciphered message, you can't reverse the function and find S given C. Regards, Antonis Antonis Christofides http://djangodeployment.com On 2018-01-16 00:03, Stephan Doliov wrote: > 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. -- 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/77523ef5-0f2f-fff3-5c96-4fcaa9b210b3%40djangodeployment.com. For more options, visit https://groups.google.com/d/optout.
