Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

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


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

git-svn-id: bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit 97ee7a3baf89690ded3a13843d8f9c86fbb1e857 1 parent d2b6f6c
@spookylukey spookylukey authored
Showing with 8 additions and 2 deletions.
  1. +8 −2 docs/ref/contrib/csrf.txt
10 docs/ref/contrib/csrf.txt
@@ -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
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,
Please sign in to comment.
Something went wrong with that request. Please try again.