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 aform.Right, but authentication is one way of identifying a requestor.[snip] assert request.form.secret_form_id == request.cookie.FORM_IDRight, 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 solidway 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....
~ro
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
