On 08/09/10 09:22, Patryk Zawadzki wrote:
>> 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.
... just mentioning the existence of django-parano
On Wed, 2010-09-08 at 10:22 +0200, Patryk Zawadzki wrote:
> 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
> On Tue, Sep 7, 2010 at 10:04 PM, Luke Plant wrote:
>> Your method is quite flawed:
Just to make sure we're on the same side -- I'm not trying to make
_CSRF_ more secure (as there's not much more we can do here).
I'm trying to:
* make it work without resorting to Referer checks
* make it not u
On Tue, Sep 7, 2010 at 10:04 PM, Luke Plant 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 = {
>>
On Tue, 2010-09-07 at 03:31 +0100, Luke Plant wrote:
> 1) The attacker can have the same (public) IP address as the victim if
> they are both behind the same firewall, and this will in fact be one of
> the most practical ways to launch a MitM + CSRF attack on HTTPS.
Here and in my other message I
Luke,
Your last couple replies to this thread have been very helpful. Thank
you for cogently clarifying this situation and patiently keeping at
it.
-Paul
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
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.
On Mon, 2010-09-06 at 21:11 +0200, Patryk Zawadzki wrote:
> See above, I'm concerned about the case when the attacker is able to
> perform a replay attack. If you validate CSRF against the client's IP
> (and possibly against a TTL field¹), you effectively prevent that type
> of attack. If the CSR
On Mon, Sep 6, 2010 at 10:39 PM, Patryk Zawadzki wrote:
> ...
First stab at a patch attached. Did not try to run it yet so it might
contain syntax errors.
--
Patryk Zawadzki
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to thi
On Mon, Sep 6, 2010 at 9:11 PM, Patryk Zawadzki wrote:
> Consider the following example. It was based on the code I wrote to
> handle the new Facebook API so it might be a bit of an overkill but it
> shows it's possible. A simpler solution would be to return (TTL + ':'
> + md5(token + user_ip + se
On Mon, Sep 6, 2010 at 8:25 PM, Luke Plant wrote:
> Almost everything in this discussion and all your misconceptions are
> covered here:
>
> http://code.djangoproject.com/wiki/CsrfProtection
I've read it before joining the discussion.
> For HTTP (not HTTPS), MitM attacks are out of scope for our
On Mon, 2010-09-06 at 18:46 +0200, Patryk Zawadzki wrote:
> On Mon, Sep 6, 2010 at 6:34 PM, Luke Plant wrote:
> > OK, that does it. I call 'troll'. If you're not trolling, my
> > apologies, but I have run out of energy trying to explain this to you.
>
> I'm still waiting for you to explain anyt
On Mon, Sep 6, 2010 at 6:34 PM, Luke Plant wrote:
> OK, that does it. I call 'troll'. If you're not trolling, my
> apologies, but I have run out of energy trying to explain this to you.
I'm still waiting for you to explain anything.
You said you were afraid of a third-party injecting cookies o
On Mon, 2010-09-06 at 18:14 +0200, Patryk Zawadzki wrote:
> On Mon, Sep 6, 2010 at 5:56 PM, Patryk Zawadzki wrote:
> > In fact current implementation is weaker than the old one. You are now
> > depending on the client delivering the challenge and the response,
> > both being sent over HTTP. An att
On Mon, Sep 6, 2010 at 5:56 PM, Patryk Zawadzki wrote:
> In fact current implementation is weaker than the old one. You are now
> depending on the client delivering the challenge and the response,
> both being sent over HTTP. An attacker no longer has to steal a valid
> session cookie, it's enough
On Mon, Sep 6, 2010 at 5:54 PM, Luke Plant wrote:
> On Mon, 2010-09-06 at 16:42 +0200, Patryk Zawadzki wrote:
>> If you use a separate *secure* cookie for CSRF over SSL then it's not
>> possible to submit data from an unsafe page to a safe processor.
>> Secure cookies are only sent to SSL targets
On Mon, Sep 6, 2010 at 4:42 PM, Patryk Zawadzki wrote:
> On Mon, Sep 6, 2010 at 3:55 PM, Luke Plant wrote:
>> On Sun, 2010-09-05 at 19:49 +0200, Patryk Zawadzki wrote:
>>> As for the vulnerability -- it's only there if you implement it
>>> yourself. If you send the initial login form over SSL (we
On Mon, 2010-09-06 at 16:42 +0200, Patryk Zawadzki wrote:
> If you use a separate *secure* cookie for CSRF over SSL then it's not
> possible to submit data from an unsafe page to a safe processor.
> Secure cookies are only sent to SSL targets so it's not possible to
> intercept the cookie by any m
On Mon, Sep 6, 2010 at 3:55 PM, Luke Plant wrote:
> On Sun, 2010-09-05 at 19:49 +0200, Patryk Zawadzki wrote:
>> As for the vulnerability -- it's only there if you implement it
>> yourself. If you send the initial login form over SSL (we do it this
>> way for various reasons), the cookies are neve
On Sun, 2010-09-05 at 19:49 +0200, Patryk Zawadzki wrote:
> As for the vulnerability -- it's only there if you implement it
> yourself. If you send the initial login form over SSL (we do it this
> way for various reasons), the cookies are never prone to be
> intercepted.
No, the vulnerability we
On Sun, Sep 5, 2010 at 7:49 PM, Patryk Zawadzki wrote:
> If you really want to use POST in HTTP → HTTPS transitions, introduce
> settings.CSRF_WHATEVER, document it thoroughly and make it default to
> False.
Just for clarity -- when the flag is False and current connection is
secure, the CSRF coo
On Sat, Sep 4, 2010 at 1:51 AM, Luke Plant wrote:
> Barth, Jackson and Mitchell [1] collected some data that said that for
> same-domain HTTPS POST requests, the header is missing in only 0.05% to
> 0.22% of cases. They've also got strong evidence that the header is
> suppressed in the network, n
On Fri, 2010-09-03 at 12:56 -0700, Paul McMillan wrote:
> I've only a small voice in this matter, but I'd like to chime in on
> the side of figuring out a way to solve this without requiring the
> Referer header.
>
> Regardless of what the RFC may say, I know from inspecting my logs
> that I (and
I've only a small voice in this matter, but I'd like to chime in on
the side of figuring out a way to solve this without requiring the
Referer header.
Regardless of what the RFC may say, I know from inspecting my logs
that I (and I assume many others) get a lot of traffic without the
header. The t
On Fri, 2010-09-03 at 17:26 +0100, Tom Evans wrote:
> On Fri, Sep 3, 2010 at 4:02 PM, Luke Plant wrote:
> > Hi Tom,
> >
> > On Thu, 2010-09-02 at 11:34 +0100, Tom Evans wrote:
> >
> >> Any sort of Referer checking is broken by design, since that header is
> >> clearly optional. RFC 2616 makes expl
On Fri, Sep 3, 2010 at 4:02 PM, Luke Plant wrote:
> Hi Tom,
>
> On Thu, 2010-09-02 at 11:34 +0100, Tom Evans wrote:
>
>> Any sort of Referer checking is broken by design, since that header is
>> clearly optional. RFC 2616 makes explicitly clear that applications
>> should not rely on Referer being
Hi Tom,
On Thu, 2010-09-02 at 11:34 +0100, Tom Evans wrote:
> Any sort of Referer checking is broken by design, since that header is
> clearly optional. RFC 2616 makes explicitly clear that applications
> should not rely on Referer being sent. Any argument that sending it
> "is virtually never a
On Fri, Aug 27, 2010 at 7:53 PM, Luke Plant wrote:
>
> Finally, the only time we need Referer headers sent is for same origin
> requests (POST requests to be exact). Sending the Referer header in
> this case is virtually never a privacy concern, since the site will
> already be able to track wha
On Fri, 2010-08-27 at 11:20 +0100, Mat Clayton wrote:
> I forgot to mention that as well, not to mention that they can be
> spooked pretty easily as well, although in this case thats not really
> a concern. Any chance of getting some of the core dev's to think about
> removing additional SSL check
We dug into it a little further here, and it looks like it might be the
office firewall stripping it out, also seen some personal firewall products
do it as well.
Mat
On 27 August 2010 17:28, Waylan Limberg wrote:
> On Fri, Aug 27, 2010 at 8:19 AM, Florian Apolloner
> wrote:
> > On Aug 27, 12:
On Fri, Aug 27, 2010 at 8:19 AM, Florian Apolloner
wrote:
> On Aug 27, 12:20 pm, Mat Clayton wrote:
>> Any
>> chance of getting some of the core dev's to think about removing additional
>> SSL checks, as FF 3.6.8 is a pretty major browser to support and this is
>> likely to only get worse as adop
On Aug 27, 12:20 pm, Mat Clayton wrote:
> Any
> chance of getting some of the core dev's to think about removing additional
> SSL checks, as FF 3.6.8 is a pretty major browser to support and this is
> likely to only get worse as adoption increases. Is the additional security
> worth the trade off?
Note this strict checking has been discussed before:
http://groups.google.com/group/django-developers/browse_thread/thread/22058adaf11e3ed6
Karen
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-d
I forgot to mention that as well, not to mention that they can be spooked
pretty easily as well, although in this case thats not really a concern. Any
chance of getting some of the core dev's to think about removing additional
SSL checks, as FF 3.6.8 is a pretty major browser to support and this is
On 08/26/10 13:25, Jeff Balogh wrote:
In our case the pref was accidentally disabled when testing add-ons,
but people do intentionally turn off Referer for privacy reasons. I
don't know if requiring Referer under https is a good idea.
RFC-2616 makes it pretty clear that one should never requir
On Thu, Aug 26, 2010 at 10:23 AM, Mat Clayton wrote:
> About to file this as a Bug in Trac but after some opinions first.
> We are running django 1.2, and can't personally reproduce this bug, but some
> of our users can do. We are using SSL and CSRF to protect our login pages, (
> https://www.mixc
About to file this as a Bug in Trac but after some opinions first.
We are running django 1.2, and can't personally reproduce this bug, but some
of our users can do. We are using SSL and CSRF to protect our login pages, (
https://www.mixcloud.com/accounts/login/ ) in 99% of cases it works fine.
How
37 matches
Mail list logo
