On Tue, Sep 7, 2010 at 10:04 PM, Luke Plant <l.plant...@cantab.net> wrote:
> On Mon, 2010-09-06 at 22:39 +0200, Patryk Zawadzki wrote:
>> Another approach would be not to use a cookie at all. For each {%
>> csrf_token %} use a slightly modified variant of the above
>> encode_cookie function with:
>>
>> values = {
>> 'host: request.META['HTTP_HOST'],
>> 'scheme': request.is_secure(),
>> 'user_ip': request.META['REMOTE_ADDR'],
>> 'user_agent': request.META['HTTP_USER_AGENT'],
>> 'ttl': time.time() + 30*60,
>> }
> Your method is quite flawed:
>
> 1) Use of IP address - a bad idea for the reasons I mentioned in my
> other message.
A lot of web frameworks I've worked with use the IP to lock the
session cookie to prevent easy cookie theft. None of the users
(including mobile ones on GPRS) complained about being constantly
logged out. I didn't use it here as a strong counter-measure, a mild
one at best.
> 2) The use of user agent does nothing to stop an attacker, even for an
> attacker who isn't a MitM:
It's not there as a counter-measure at all. Just to make the resulting
token vary a bit more.
> Consider an attacker who lures you to his site e.g.:
> http://evil.com/somepage.php
>
> somepage.php can read your user agent, and make a request to
> http://target.com/some-page-with-form/ with the same user agent to get a
> valid CSRF token. (If he is behind the same firewall as you, he will
> automatically have the same public IP, so adding the IP address is not a
> perfect cure for this, even if we could do it, which we can't).
Again, it's not there to counter attacks. Think of it as the
equivalent of the "csrftoken" cookie which could be read in the exact
same way. I just wanted a couple of strings that are not likely to
change between form generation and submission.
> I don't think that adding a timeout will really ever help with CSRF.
> The nature of CSRF attacks means that the attacker is massively more
> likely to be able to attack 'now' (which is within a few seconds, the
> time for a few HTTP requests to complete) rather than 'later', so
> timeouts just don't help. In addition, they add nuisance for the user -
> it's quite possible for someone to leave their machine for 30 minutes
> and come back to it and want to carry on what they were doing.
The timeout serves it purpose beyond CSRF. I'd like the "sign_request"
method (and "check_request_signature" -- see the patch) to be able to
take custom TTL and eventually a custom dict to both encode at signing
time and check against at validation time. This would allow one to
easily implement other mechanics, such as secure API tokens (you don't
want to rely on Cookies there) or easy HTTP→HTTPS transitions (detect
that the token was signed and issued over unsecure connection and ask
the user to resubmit).
--
Patryk Zawadzki
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
