#26165 new Cleanup/optimization wanted to start with a documentation ticket

[Vivek unni]

I wanted to start with a documentation ticket while I get myself acquainted with the code base. I have seen the thread referenced and I can make relevant questions and answers from it . These questions and answers will go to the FAQ page regarding why Django's CSRF protection isn't vulernable. Where do I start writing the documentation and how can I claim the ticket ? Some examples will help.

Thanks in advance.

[Tim Graham]

The FAQ is at: https://github.com/django/django/tree/master/docs/faq
Depending on how much content there is, it might make more sense to add the questions on the CSRF reference page instead: https://github.com/django/django/blob/master/docs/ref/csrf.txt
Please read the contributing documentation about claiming tickets: https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#claiming-tickets

p.s. I think it's better to use the django-core-mentorship mailing list to get help about the basics of contributing. Thanks!

[Vivek unni]

Thanks. I was going to add the questions at the end of the csrf.txt. Thanks for the help. I have claimed the ticket. I will send a pull request in a day or two.

[Vivek unni]

Hi. I have compiled a list of questions. I made a section in the faq folder. These are the questions and answers I wrote. These answers were written based on the thread referenced on the ticket

FAQ: CSRF Protection

=====================

Is Django's CSRF protection vulnerable?

---------------------------------------

No, it is not. Django CSRF security system provides an implementation that allows you to have CSRF protection without linking it to a session. The way the CSRF token works is simple. Every form will have a CSRF token which matches the CSRF cookies. While processing the submitted form, the server will make sure that the submitted CSRF token matches the cookie value. This is a server side check but it is not against any stored server-side value. Since the remote attacker would not be able to read or set arbitrary cookies on your domain, it protects the user.

Why can't we keep a new token for each request ?

------------------------------------------------

Generating a new token for each request is problematic from a UI perspective because it invalidates all previous forms. Most users would be very unhappy to find that opening a new tab on your site has invalidated the form they had just spent time filling out in the other tab or that a form they accessed via the back button could not be filled out.

How can I make Django's CSRF protection work to its full extent ?

------------------------------------------------------------------

Make sure of the following:

* Use HTTPS.Redirect to the encrypted version for all unencrypted requests. If you don't do this,

  CSRF protection won't be able to protect you from a man-in-the-middle attack.

* Use HSTS. Set it for several months. Use "includeSubDomains". This means that no matter what your

  users type, and no matter what the man-in-the-middle does, your users will always access your site securely if they've been there at least once before.

* Validate the HOST header in your httpd. Don't allow arbitrary requests to fall through to Django.

  Serve your site only for the appropriate domain. See the most recent security advisory for more information about this.

* Ensure there are no XSS vulnerabilities on your website.

If the above mentioned points are enforced then the developer will be able to take advantage of the other feature that makes the CSRF protection stronger: Strict referer checking (only enforced over HTTPS). This means that even if a subdomain can set or modify cookies on your domain, they can't force a visitor to post to your application, since that request won't come from your own exact domain.

Is this fine or should I add more ? If this is fine, I can send a pull request today itself.

[Tim Graham]

Please send the pull request -- we do review there, not on this mailing list. Thanks!

[Vivek unni]

Thanks for helping me out. Sorry for the mess up regarding the Triage stage. Thanks for walking me through the whole process.