Re: [Repoze-dev] repoze.who-based form protection middleware

[Reed O'Brien]

On Mar 26, 2009, at 10:55 AM, Malthe Borch wrote:

2009/3/26 Reed O'Brien <r...@reedobrien.com>:

I still think you need to use a second form specific header/cookie. So you can be sure that the form being submitted isn't stale. I don't think it wise

to use an already existing session; as an instance of a form can be
submitted repeatedly.

That's policy though; google search for instance, does not have such a policy.

But google's search is a GET request; which should be idempotent and shouldn't need CSRF protection.

If it is tied to a specific header/cookie at form generation time then only the id==token is valid for that particular submission. If there is a field validation error in the form (empty required field e.g.) then the form is

re-rendered to the agent with a new header/cookie == form token.

Right you could have a ticket system, but is it really necessary for
the general site? Perhaps for online banking or airline ticket
booking.

for non-idempotent POST requests, IMO.

Perhaps we are saying the same thing and I am being obtuse. But *only* validating that an agent is participating in a valid session doesn't prevent

a malicious JS from submitting a form on that valid sessions behalf.

No, but you *never* want mailicious JS served up from your own domain.
That's a serious vulnerability that can easily expose all your users
credentials. So that scenario should not be considered.

I wasn't referring to a malicious JS on my own server as that wouldn't be cross site request forgery (CSRF), which is what we are talking about preventing, no?

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev