> > 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 --
