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 wiseto 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 isre-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 preventa 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?
Description: S/MIME cryptographic signature
_______________________________________________ Repoze-dev mailing list Repozeemail@example.com http://lists.repoze.org/listinfo/repoze-dev