Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

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

Re: #13870: Correctly handling database isolation (in PostgreSQL)

I ran into this issue with daemons/scheduled jobs and "idle in transaction" in Django quite a while ago. I have a nice writeup of the problem and solution on this StackOverflow question if anybody's interested:

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

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

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

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 + ':' > +

CSRF and Forms

Hi, Since CSRF is already being reafactored up-side down in the trunk, I thought it might be a good idea to propose a slight modification. Currently CSRF either falls through to the resolved view function or calls settings.CSRF_FAILURE_VIEW. More than once I've found myself wanting something in

Re: python 3.x

Thanks everybody! while indeed it's clear django will not official run on 3.0 any soon, it's clearer to me why & how. yes I'm aware of __future__ import, though it's not really magic (eg. support for bytes / unicode types is more of a compatibility thing, for argparse python 2.7 minimum is

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

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

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

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

Re: #13870: Correctly handling database isolation (in PostgreSQL)

On Mon, Sep 6, 2010 at 4:47 PM, Robert Gravsjö wrote: > Patryk Zawadzki skrev 2010-09-06 15.29: >> The isolating transaction keeps going on until you either (1) commit, >> (2) rollback or (3) disconnect. Django only commits/rollbacks the >> transactions it explicitly starts, it

Re: #13870: Correctly handling database isolation (in PostgreSQL)

On Mon, 2010-09-06 at 16:47 +0200, Robert Gravsjö wrote: > Can you please show me the code you're running to reproduce this? > > Regards, > roppert I've experienced what Patryk is describing here. It seems that the Django ORM, when not explicitly in a transaction, doesn't commit or rollback

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

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

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

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

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

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 >

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

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

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

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.

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

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

Re: #13870: Correctly handling database isolation (in PostgreSQL)

Patryk Zawadzki skrev 2010-09-06 15.29: On Mon, Sep 6, 2010 at 2:00 PM, Robert Gravsjö wrote: I'm not sure what you think you are doing but if you end up with " in transaction" that means you have not commited your transactions. See below. For instance, open two

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

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

Re: CSRF Middleware/SSL/Firefox 3.6.8 bug

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

Re: #13870: Correctly handling database isolation (in PostgreSQL)

On Mon, Sep 6, 2010 at 2:00 PM, Robert Gravsjö wrote: > I'm not sure what you think you are doing but if you end up with " >  in transaction" that means you have not commited your transactions. See below. > For instance, open two connections with psql and run BEGIN in one and >

Re: #13870: Correctly handling database isolation (in PostgreSQL)

Patryk Zawadzki skrev 2010-09-06 12.20: On Mon, Sep 6, 2010 at 11:20 AM, Kirit Sælensminde (kayess) wrote: --- snip --- You can check this by creating a fresh project using psycopg2 and creating a model. Then write a view that queries the database and

Re: #13870: Correctly handling database isolation (in PostgreSQL)

On Mon, Sep 6, 2010 at 1:35 PM, burc...@gmail.com wrote: > Hi Patryk, > > This was done to make Django faster, so it doesn't create connection > to database every time new SQL is executed. What was done? Commiting the isolating transaction of a connection does not terminate

Re: #13870: Correctly handling database isolation (in PostgreSQL)

Hi Patryk, This was done to make Django faster, so it doesn't create connection to database every time new SQL is executed. Do you mean you wanted to set up timeouts for idle database connections? I guess, nobody asked this before. On Mon, Sep 6, 2010 at 5:20 PM, Patryk Zawadzki

Re: #13870: Correctly handling database isolation (in PostgreSQL)

On Mon, Sep 6, 2010 at 11:20 AM, Kirit Sælensminde (kayess) wrote: > Strange. We use Postgres and don't see any problem with this. We do > encounter complications occasionally with the lack of composition of > Django transaction handling, but other than that find the

Re: #13870: Correctly handling database isolation (in PostgreSQL)

Strange. We use Postgres and don't see any problem with this. We do encounter complications occasionally with the lack of composition of Django transaction handling, but other than that find the transaction handling adequate. Are you actually using transactions in your code? You need to be. The