token validation helper
Permalink 1 user found helpful
http://www.concrete5.org/documentation/developers/forms/basic-validation/ mentions a "token validation helper":
[code]$val->addRequiredToken($value, $errorMsg = null){/code]
Validates the form against a unique token as generated by the concrete5 token validation helper.
Anyone have any examples of how to use this?
Cheers
Russell
[code]$val->addRequiredToken($value, $errorMsg = null){/code]
Validates the form against a unique token as generated by the concrete5 token validation helper.
Anyone have any examples of how to use this?
Cheers
Russell
Nice example, Jordan.
For a working example of this, see concrete/single_pages/profile/messages.php and concrete/controllers/profile/messages.php.
For a working example of this, see concrete/single_pages/profile/messages.php and concrete/controllers/profile/messages.php.
Is this something that's necessary to do if we want a secure contact form? I've created 3 C5 sites with forms so far without ever hearing about this. They were all C5 5.3.3.
Depends.
If it was just forms you added using the built-in "Form" block, then you don't need to worry about this because it's already included in that block's functionality.
But if you created your own forms (including the html for the fields, and the validation/processing code in the controller) -- either in a single_page or in an external_form block or in your own block that you created -- then yes you would need to add this yourself if you want this functionality.
Notice I didn't say "it's necessary" -- it's only necessary if you want to protect against CSRF attacks. If the form is publicly available and can be filled out by anyone visiting your site, then I definitely would recommend adding this to your forms. But if the form is only for people administering the site (like it's in a dashboard page or in a block edit dialog), then you don't need to worry about this because your users are "trusted". If the form is on a protected page that only registered users can get to, then you will have to decide how much you "trust" these registered users.
-Jordan
If it was just forms you added using the built-in "Form" block, then you don't need to worry about this because it's already included in that block's functionality.
But if you created your own forms (including the html for the fields, and the validation/processing code in the controller) -- either in a single_page or in an external_form block or in your own block that you created -- then yes you would need to add this yourself if you want this functionality.
Notice I didn't say "it's necessary" -- it's only necessary if you want to protect against CSRF attacks. If the form is publicly available and can be filled out by anyone visiting your site, then I definitely would recommend adding this to your forms. But if the form is only for people administering the site (like it's in a dashboard page or in a block edit dialog), then you don't need to worry about this because your users are "trusted". If the form is on a protected page that only registered users can get to, then you will have to decide how much you "trust" these registered users.
-Jordan
jordanlev, it's right and false because CRSF attack use the session of a user.
Example, if a user is logged as admin and the CRSF target an known URL that delete an article, you need to include token in dashboard forms too.
Best,
Moosh
Example, if a user is logged as admin and the CRSF target an known URL that delete an article, you need to include token in dashboard forms too.
Best,
Moosh
Moosh,
I believe you are correct -- I was perhaps confusing CSRF attacks with XSS. Thanks for the correction.
-Jordan
I believe you are correct -- I was perhaps confusing CSRF attacks with XSS. Thanks for the correction.
-Jordan
In your form, you would output a CSRF token in a hidden field like this:
Then, when you validate the form, add this to your validation helper object setup code:
The documentation is a bit misleading, as unlike other validation rules, you do NOT need to pass in a $value (it pulls the token value automatically from $_REQUEST), and you do NOT need to pass in $errorMsg (it will automatically use "Invalid form token. Please reload this form and submit again." if you don't override it).
If you want an extra layer of security, you can denote the specific action that this token is for by adding it as the first parameter to both $token->output() and $val->addRequiredToken():
(Note that the action name is an arbitrary string you come up with -- it does not necessarily have to match the actual form "action" -- but it does need to be the same in both the form output and the validation check as above.)
HTH
-Jordan