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...
1 parent d2b6f6c commit 97ee7a3baf89690ded3a13843d8f9c86fbb1e857 @spookylukey spookylukey committed Oct 27, 2009
Showing with 8 additions and 2 deletions.
  1. +8 −2 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,

0 comments on commit 97ee7a3

Please sign in to comment.