On Friday 09 August 2013 18:08:26 Luke Plant wrote:
> On 03/08/13 23:57, Shai Berger wrote:
> > This would work exactly like it works today, except with signed cookies.
> > That is, the "user specific element" is the cookie. CSRF is about
> > tricking the user into submitting a request designed out
On 03/08/13 23:57, Shai Berger wrote:
> This would work exactly like it works today, except with signed cookies. That
> is, the "user specific element" is the cookie. CSRF is about tricking the
> user
> into submitting a request designed out of the site -- an attacker can't just
> set (or read
Hi,
You can find my work-in-progress at https://github.com/django/django/pull/1454.
It is nowhere near ready yet -- it is still missing some pieces and has
commented-out debug printing, but I'm done for tonight, and I think it is
advanced enough that people may want to take a look and comment.
O
Hi,
On Sunday 04 August 2013 01:26:58 Luke Plant wrote:
> On 28/07/13 00:12, Shai Berger wrote:
> >
> > a) Use a signed cookie for csrftoken -- using Django's existing signing
> > facility[4], this means signing the cookie with the SECRET_KEY from the
> > settings; so that an attacker cannot set
On 28/07/13 00:12, Shai Berger wrote:
> Hi everybody,
>
> TL;DR: A simple change can make Django's CSRF protection a little better; an
> additional, slightly less simple one, can also make it look better.
>
> Django's CSRF protection scheme is a bit unusual; unlike most such schemes,
> it
> do
In light of BREACH[1] it might be worth looking into having the option of
adding a one-time pad to the CSRF token as well. Has anyone started
development on any of the suggestions in this thread yet? If not, it's
something I'd be interested in exploring.
Cheers,
--
Michael Mior
michael.m...@gma
I agree with Jacob on both points.
+1 from me, especially since neither of these changes should require
changes in application code which is already using the interface
correctly.
-Paul
On Tue, Jul 30, 2013 at 1:22 PM, Jacob Kaplan-Moss wrote:
> Hey Shai -
>
> I have no objections to this chang
Hey Shai -
I have no objections to this change. I think it's got a slight whiff of
security theatre, in that it *looks* like it adds more protection than it
*actually* does. However, I, too, have spent a ton of time talking auditors
down from "OMG Django is vulnerable to CSRF!" and I'd like to do
Hi
(quotation below edited)
On Monday 29 July 2013 17:59:53 Matthew Lauber wrote:
> On Sat, Jul 27, 2013 at 7:12 PM, Shai Berger wrote:
> >
> > a) Use a signed cookie for csrftoken -- using Django's existing signing
> > facility[4], this means signing the cookie with the SECRET_KEY from the
> >
As I understand (a), it sounds like an excellent scheme, and something that
would be simple to update behind the scenes without unduly affecting
application code. I'm more ambivalent about (b). Have you or anyone else
started work on a patch/pull-request for this?
On Sat, Jul 27, 2013 at 7:12
Hi everybody,
TL;DR: A simple change can make Django's CSRF protection a little better; an
additional, slightly less simple one, can also make it look better.
Django's CSRF protection scheme is a bit unusual; unlike most such schemes, it
does not rely on a value stored in the server that needs
11 matches
Mail list logo
