Could you explain why? And why it matters if the user is registered or not?
Alternatively, if the token is present and wrong and it's not a POST, reset the token. Thanks On Thu, Aug 8, 2013 at 11:24 AM, Alex Ogier <[email protected]> wrote: > That's too hard to enforce. It would mean that you can't show user content > on any public page, or any page that you want to be accessible from outside > links. For example, you couldn't show blog comments to unregistered users. > It would be too disruptive. Modifying the format of the secret token is a > much better idea -- you only need to obfuscate it enough to defeat the > compression scheme, not an adversarial attacker. > > > On Wed, Aug 7, 2013 at 3:23 AM, Simon Blanchard <[email protected]> wrote: > >> I think they nibble at it. They look at the compressed length - the >> shorter the compressed length closer they are. But if an incorrect CSRF was >> never reflected there would be nothing for them to nibble at. It says this >> in the paper: "However, we remark that requiring a valid CSRF token for >> all requests that reflect user input would defeat the attack." >> >> >> >> On Wed, Aug 7, 2013 at 3:13 PM, Curtis Maloney < >> [email protected]> wrote: >> >>> They don't try to guess the CSRF directly, AIUI. >>> >>> They use a form field to affect their test. >>> >>> The easiest solution I can see is the one mentioned in the document -- >>> instead of outputting the raw value, output SALT || (SALT ^ TOKEN) so the >>> actual value is never in the response, but it can be retrieved by simply >>> xoring it with the salt. The salt is changed every request. >>> >>> -- >>> Curtis Maloney >>> >>> >>> >>> On 7 August 2013 16:56, simonb <[email protected]> wrote: >>> >>>> How about requiring that if csrfmiddlewaretoken is set, no matter what >>>> http method (GET, POST...), it is correct otherwise 403 response. >>>> >>>> Simon >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Django developers" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected] >>>> . >>>> Visit this group at http://groups.google.com/group/django-developers. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>>> >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/django-developers. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/django-developers. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
