On Sep 25, 2:54 am, Rudolph <[EMAIL PROTECTED]> wrote:
> I like Luke's arguments.
>
> A middleware seems like the right place because CSRF protection is
> about requests and responses. CSRF protection is more about POST
> requests in generic, with HTML forms being a very common type of POST
> requ
I like Luke's arguments.
A middleware seems like the right place because CSRF protection is
about requests and responses. CSRF protection is more about POST
requests in generic, with HTML forms being a very common type of POST
request.
IMHO the default settings.py file (generated with 'django-ad
On Sep 24, 11:17 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> It turns out it's not that straight-forward after all:
>
> http://icanhaz.com/csrfpdf(PDF link, "Robust Defenses for Cross-Site
> Request Forgery")
>
> The above paper introduces the "login CSRF" attack, where CSRF is used
> to force
Hi Simon,
> CSRF[1] is one of the most common web application vulnerabilities, but
> continues to have very poor awareness in the developer community.
> Django ships with CSRF protection in the form of middleware, but it's
> off by default. I'm willing to bet most people don't turn it on.
>
> I
On Wed, Sep 24, 2008 at 9:00 AM, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> On Sep 24, 2:18 pm, zellyn <[EMAIL PROTECTED]> wrote:
>> Would it make sense to have the middleware/view decorator set a
>> property on the request, and pass the request to all forms, and have
>> *all* forms CSRF-protec
On Sep 24, 10:00 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> That's an interesting idea. I'm a bit cautious of requiring ALL forms
> to take a request object though - Django's current form library is
> decoupled from Django's request object, which is actually a really
> useful property. I've
On Sep 24, 2:18 pm, zellyn <[EMAIL PROTECTED]> wrote:
> Would it make sense to have the middleware/view decorator set a
> property on the request, and pass the request to all forms, and have
> *all* forms CSRF-protect themselves when the property is set? That
> would make it easy to add protection
I like the middleware/view decorator for setting the cookie.
Would it make sense to have the middleware/view decorator set a
property on the request, and pass the request to all forms, and have
*all* forms CSRF-protect themselves when the property is set? That
would make it easy to add protection
On Sep 23, 11:23 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> CSRF attacks are a problem for systems where an action is only meant
> to be available to a specific logged in user. This user is inevitably
> identified by a unique cookie. This is normally a session cookie,
> hence many CSRF protec
I'd like to discuss if forms should try to be secure by default? It's
a bit like the autoescaping discussion.
The new Form class would need to accept dictionaries or request
objects as input. A dictionary is however only accepted if you
explicitly disable CSRF protection:
form = MyForm(request.PO
> in fact, it takes us back to the
> original proposal of a SafeForm that just takes the request object as
> an argument to its constructor.
Well this seems much simpler, although there is still the requirement
to add the csrf_fields whenever you write out the form in the template
(which isn't mu
So I guess it's not my brain farting.
On Sep 24, 12:23 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> Unsurprisingly, I've been totally over-engineering this. There's no
...
> I think we solve this with a setting, the default of which looks like
> this:
At least you haven't been writing over-en
On Sep 23, 11:02 pm, Jan Oberst <[EMAIL PROTECTED]> wrote:
> Adding a signed field with a timestamp would be a much easier way to
> secure forms. But it's not nearly as as secure as having the token
> signed with an additional cookie. By setting a signed cookie you can
> verify that this very form
On Sep 23, 11:51 pm, "Amit Upadhyay" <[EMAIL PROTECTED]> wrote:
> There is another option, a template tag. I would implement it as a
> middleware and a template tag. Template tag csrf_protect, will require
> CSRFMiddleware and django.core.context_processors.request, will add a
> input file contain
On Sep 24, 1:04 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> There's another option that avoids the need for any cookies at all:
> generating a persistent one-use-only token when a form is saved,
> storing that in the database and only allowing submissions that
> include a token that was previo
On Sep 23, 11:23 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> CSRF attacks are a problem for systems where an action is only meant
> to be available to a specific logged in user. This user is inevitably
> identified by a unique cookie. This is normally a session cookie,
> hence many CSRF protec
On Tue, Sep 23, 2008 at 8:43 PM, Brian Beck <[EMAIL PROTECTED]> wrote:
> The problem is that any token, no matter where we generate it, isn't
> going to be submitted back with the POST request unless it's a field
> in the form that was submitted. So the only options I see are
> mangling the HTML
On Sep 23, 1:06 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> Since all form.protect(response) actually does is ensure that there's
> a csrf cookie, you should only actually have to do it once for one of
> the forms.
Unsurprisingly, I've been totally over-engineering this. There's no
need for f
On Sep 23, 10:17 pm, "Robert Coup" <[EMAIL PROTECTED]>
wrote:
> then when you get a form submission, base64-decode it, split at "/", check
> the hash matches by recalculating it, then use the proximity-to-timestamp
> and the remote_addr to check the form validity.
Anything that relies on remote_a
On Wed, Sep 24, 2008 at 5:29 AM, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> On Sep 23, 12:13 pm, oggy <[EMAIL PROTECTED]> wrote:
> > Could we just include something like a signed salt+timestamp
> > +REMOTE_ADDR in a hidden field? It's not exactly bulletproof because
> > of the possibility of a same
On Sep 23, 6:13 pm, oggy <[EMAIL PROTECTED]> wrote:
> Could we just include something like a signed salt+timestamp
> +REMOTE_ADDR in a hidden field? It's not exactly bulletproof because
> of the possibility of a same-IP-CSRF (affecting people behind
> proxies), but it's dead simple and doesn't req
On 23 sep, 01:27, Simon Willison <[EMAIL PROTECTED]> wrote:
> On Sep 22, 9:41 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> > - If there's some other way to spell form.protect(response).
>
> Here's a crazy idea that might just work:
>
> class AddArticleForm(forms.SafeForm):
> headline = forms.
On Sep 23, 12:13 pm, oggy <[EMAIL PROTECTED]> wrote:
> Could we just include something like a signed salt+timestamp
> +REMOTE_ADDR in a hidden field? It's not exactly bulletproof because
> of the possibility of a same-IP-CSRF (affecting people behind
> proxies), but it's dead simple and doesn't re
Could we just include something like a signed salt+timestamp
+REMOTE_ADDR in a hidden field? It's not exactly bulletproof because
of the possibility of a same-IP-CSRF (affecting people behind
proxies), but it's dead simple and doesn't require a lot of code
change: Form -> SafeForm + request as the
On Sep 23, 10:56 am, oggie rob <[EMAIL PROTECTED]> wrote:
> I'm sorry, I used the wrong term here. I didn't mean that CSRF
> protection isn't worthwhile, just that going the route of an extended
> form might not be the best way to do it.
> As for suggestions, I'm not sure I have one exactly, but I
On Sep 23, 3:26 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> On Sep 23, 9:00 am, oggie rob <[EMAIL PROTECTED]> wrote:
>> Is it worth a gut check to make sure this is worthwhile?
>
> Here's a useful case in point: the admin. Django's admin should ship
> with CSRF protection turned on and baked i
On Sep 23, 9:00 am, oggie rob <[EMAIL PROTECTED]> wrote:
> I just read this thread now, and by the end of it, things are looking
> pretty complicated. Is it worth a gut check to make sure this is
> worthwhile? Although the middleware might be a hack now, it seems
> sensible that it fits in request
On Sep 22, 1:25 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> CSRF[1] is one of the most common web application vulnerabilities, but
> continues to have very poor awareness in the developer community.
> Django ships with CSRF protection in the form of middleware, but it's
> off by default. I'm w
> I propose django.forms should include a SafeForm class, which is a
> subclass of Form that includes built-in protection against CSRF. I
> imagine the interface looking something like this:
Why wouldn't the safe form class be the forms.Form class instead? We
do XSS-protection by default already,
On Sep 23, 12:53 am, Tai Lee <[EMAIL PROTECTED]> wrote:
> On Sep 23, 9:27 am, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> > The significant downside is that having a render() method on a form
> > that performs the same function as render_to_response feels really,
> > really strange. It's conveni
On Sep 23, 1:53 am, Tai Lee <[EMAIL PROTECTED]> wrote:
> On Sep 23, 9:27 am, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> > The significant downside is that having a render() method on a form
> > that performs the same function as render_to_response feels really,
> > really strange. It's convenie
On Sep 23, 9:27 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> The significant downside is that having a render() method on a form
> that performs the same function as render_to_response feels really,
> really strange. It's convenient, but it just doesn't feel right and
> I'm not sure I can justi
On Sep 23, 12:27 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> return form.render('add_article.html', {
> 'extra_context_args': 'Go here',
> })
Using render_response as the method name might make this a little more
palatable:
return form.render_response('add_article.html',
On Sep 22, 9:41 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> - If there's some other way to spell form.protect(response).
Here's a crazy idea that might just work:
class AddArticleForm(forms.SafeForm):
headline = forms.CharField()
# ...
def add_article(request):
form = AddArticleForm
On Sep 22, 10:25 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> CSRF[1] is one of the most common web application vulnerabilities, but
> continues to have very poor awareness in the developer community.
> Django ships with CSRF protection in the form of middleware, but it's
> off by default. I'm
On Sep 22, 11:09 pm, Jan Oberst <[EMAIL PROTECTED]> wrote:
> I'd protect all my forms if there's a neat way to do it. Why would it
> only apply to logged-in users? I'm not using contrib.auth.
It doesn't need to only apply to contrib.auth logged in users, but it
should only be used for forms which
On Sep 22, 10:21 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> This makes me think -- is it possible that CSRF protection at the form
> level is too low? Perhaps it's something that needs to be happening
> at, say, the view level? Some sort of decorator, and/or a tag to spit
> out the CSRF
On Mon, Sep 22, 2008 at 3:25 PM, Simon Willison <[EMAIL PROTECTED]> wrote:
> I propose django.forms should include a SafeForm class, which is a
> subclass of Form that includes built-in protection against CSRF. I
> imagine the interface looking something like this:
Yes, indeed -- we should do thi
On Sep 22, 5:16 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> One thing that might help out in this case would be the ability to
> create a SafeForm from a regular Form (which might be an argument for
> csrf protection as a feature of django.forms.Form rather than a
> subclass). If the third par
On Sep 22, 10:01 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> > > -- What about third-party app forms that aren't SafeForms, but need to
> > > be? The situation dictates this, not the form author.
> > I think we keep CSRF middleware around to deal with that. We also very
> > actively encourage thi
On Sep 22, 5:01 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> But still, the situation dictates the need for SafeForm, not the form
> author. If this becomes best practice, essentially *every* form will
> need to be initialized with a request.
What about something like:
def protect_form(form_clas
On Sep 22, 4:55 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> > -- What about third-party app forms that aren't SafeForms, but need to
> > be? The situation dictates this, not the form author.
> I think we keep CSRF middleware around to deal with that. We also very
> actively encourage third pa
On Sep 22, 9:41 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> -- What about third-party app forms that aren't SafeForms, but need to
> be? The situation dictates this, not the form author.
I think we keep CSRF middleware around to deal with that. We also very
actively encourage third party apps to
On Sep 22, 4:25 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> CSRF[1] is one of the most common web application vulnerabilities, but
> continues to have very poor awareness in the developer community.
> Django ships with CSRF protection in the form of middleware, but it's
> off by default. I'm w
CSRF[1] is one of the most common web application vulnerabilities, but
continues to have very poor awareness in the developer community.
Django ships with CSRF protection in the form of middleware, but it's
off by default. I'm willing to bet most people don't turn it on.
I don't believe middlewar
45 matches
Mail list logo
