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

2009/3/26 Reed O'Brien <r...@reedobrien.com>:
I thought it was less about authenticating the user; more about verifying that the requestor POSTing a form was the same requestor that requested a

Right, but authentication is one way of identifying a requestor.


assert request.form.secret_form_id == request.cookie.FORM_ID

Right, that's exactly it; but it might be nice to use an already
existing cookie.

I know this doesn't cover all cases (xmlhttprequest) but AFAIU it is a solid
way to protect POSTs from CSRF without requiring a shared secret.

You need this secret value to be special to each requestor; one way to
do that is to rely on a session id or credentials.

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.

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.

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.

Sorry only half thinking here. Trying to pay attention to the tosca widgets tutorial....


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

Repoze-dev mailing list

Reply via email to