mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-07-05 10:19:20 +00:00
Code Issues 32 Releases Wiki Activity

[1.1.X] Fixed #10996 - documented login CSRF vulnerabilities in the CsrfMiddleware

Browse Source 
1.1.X branch only fix - trunk is completely different now.



git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.1.X@11662 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Luke Plant 2009-10-27 00:38:28 +00:00
parent d2b6f6c948
commit 97ee7a3baf
1 changed files with 8 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
docs/ref/contrib/csrf.txt
View File

@ -91,8 +91,8 @@ effects (see `9.1.1 Safe Methods, HTTP 1.1, RFC 2616`_), and so a
CSRF attack with a GET request ought to be harmless.
POST requests that are not accompanied by a session cookie are not protected,
but they do not need to be protected, since the 'attacking' Web site
could make these kind of requests anyway.
but since these requests are not authenticated, they will usually be of limited
risk.
The Content-Type is checked before modifying the response, and only
pages that are served as 'text/html' or 'application/xml+xhtml'
@ -116,6 +116,12 @@ CsrfMiddleware requires Django's session framework to work. If you have
a custom authentication system that manually sets cookies and the like,
it won't help you.
The middleware only partially protects against 'Login CSRF'. If you have used
standard Django views for logging in, then you will be protected, due to the way
they work (the session must be established in the step before actually logging
in, so the login step itself is protected). If you have used a different way to
log in, you may be vulnerable to Login CSRF.
If your app creates HTML pages and forms in some unusual way, (e.g.
it sends fragments of HTML in JavaScript document.write statements)
you might bypass the filter that adds the hidden field to the form,