I suppose then that it would make sense to bake his own at this point - create a formkey in the session variables, on submit check the formkey returned.
On Tuesday, July 17, 2012 10:15:14 PM UTC-7, Anthony wrote: > > I am presuming this is the mechanism you use for preventing CSRF attacks - >> >> 1) Generate a unique value for every form that is sent to clientside. >> 2) Assign this value to _formkey, and also store it in the session. >> > > Yes, but _formkey is stored along with the _formname, so it is associated > with a particular form (which answers your question below). > > >> 3) When the user submits the form back compare the value in the _formkey >> and the session. >> 4) If the value matches then its a valid request, otherwise its an attack. >> >> If you are using the above mechanism - >> >> 1) How do you know which formkey to compare to which key in the session. >> As you have generated multiple form keys and stored them in session, one >> for each form. >> > > As noted above, a _formkey goes with a particular _formname. That means if > multiple forms with the same name have been loaded in the browser (e.g., in > separate tabs, or even on the same page), only the last form generated will > work (because its _formkey will have overwritten the _formkey of any > previously generated form with the same name). We've discussed allowing > multiple formkeys for the same formname, so if a user opens a second tab > and then goes back to the first tab to submit a form, the submission will > work rather than failing. > > Note, the _formkey mechanism is intended to prevent double form submission > in addition to CSRF (though you can protect against double submission on > the client via JS as well). > > >> I was thinking of this scheme for CSRF protection - >> >> 1) Generate a CSRF protection token and set it on client side during the >> first request. >> 2) On every subsequent ajax call the client will grab the token and post >> it with the data. (client side double submit) >> 3) The server will compare the returned cookie value with the POST >> request, to verify if it is a valid request. >> > > Sounds reasonable. > > Anthony > > --
