On Mar 27, 2009, at 1:10 AM, Malthe Borch wrote:

2009/3/26 Reed O'Brien <r...@reedobrien.com>:
But google's search is a GET request; which should be idempotent and
shouldn't need CSRF protection.

True that.

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

for non-idempotent POST requests, IMO.

In a CMS system for example, would you want the "Save" action to be
protected from resubmission? Ideally, users will only submit the
button once, but it's a bit awkward to prevent it by force, when
there's no damage ahead.

That particular rendering of the form, yes. I there is a validation error and the form needs to be re-rendered; then redraw it with a new unique token and update the token cookie/header to match. It isn't perfect, but would prevent session riding.

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
a malicious JS from submitting a form on that valid sessions behalf.


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?

Undesired resubmission of forms is one thing; it can be dealt with
using a ticket system.

As for what we're supposed to be talking about here :-) ––- you said
it best, I think: to ensure that the requestor is the requestor. To
that extend, forms must be *signed* with a personal signature.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Repoze-dev mailing list

Reply via email to