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

[Vivek unni]

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


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f8a9c32d-6b11-423d-9a30-6b8957a6e6d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Tim Graham]

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

On Wednesday, February 3, 2016 at 10:27:32 AM UTC-5, Vivek unni wrote:
>
> 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.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/11d75e9d-32a6-4c87-8977-6583fb338312%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[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.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/816bad89-48dd-45b1-a166-92bfd1ee86a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[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. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/abcc513c-096e-4415-846e-8c56a71b61c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[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!

On Tuesday, February 2, 2016 at 4:14:08 PM UTC-5, Vivek unni wrote:
>
> 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.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fa19bbdf-47b8-4fdd-904e-917b2ac465ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Vivek unni]

Hi,
I wanted to start with a documentation ticket.
 https://code.djangoproject.com/ticket/26165 
 I have read through the 
thread and have made some questions and answers. How should I proceed? 
Should I claim the ticket ? Where can I start writing?

Thanks in advance
Vivek

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/713d8815-1dee-45cf-abe8-0a2a168540ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

#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.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2f38936b-7c96-4d30-ae18-6fc064677d24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.