The CSRF middleware inserts a hidden input element in every form. Since GET Requests are mostly readonly, the bad guy needs a POST request to do some evil.
If the bad guy can make a POST request with the user's browser, the bad guy might make a GET request with javascript first , read the hidden input element and use the value for the evil POST request. I just read this: http://en.wikipedia.org/wiki/Cross-site_request_forgery Maybe HTTP-Referer checking is a better solution. Thomas Luke Plant schrieb: > I have not been able to implement all of the CSRF proposals we made a > while back in time for the beta (in particular, replacing the current > CsrfResponseMiddleware with a template tag). > > However, significant improvements have been made, and it is much more > useful by default. I propose adding the two middleware (view and > response) to the MIDDLEWARE settings in following files: > > django/conf/global_settings.py > django/conf/project_template/settings.py > > Rationale: > > - the admin application is not safe from CSRF attacks without this, > so out-of-the-box it is quite insecure. This is a 4 year old bug > ( http://code.djangoproject.com/ticket/510 ) which isn't really > fixed if the fix is not enabled by default. > > - the main objections to using the CSRF middleware were: > - problems for AJAX apps -- now automatically fixed in most cases > - a pain to selectively disable -- now fixable with 'csrf_exempt' > > Please let me know by Thursday evening (GMT) if there are objections. > > Luke > -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
