Commit 97ee7a3b authored by Luke Plant's avatar Luke Plant
Browse files

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

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
parent d2b6f6c9

docs/ref/contrib/csrf.txt

+8 −2
Original line number Diff line number Diff line
@@ -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,