I have a client site in which the Formulate contact page was smashed by a bot - over 200,000 form submissions in a day.
What is the best way to "secure" a formulate form? Ie, is there an inbuilt honey pot, or an easy was to integrate it with a captcha etc?
Also, is there protection against cross site scripting via Anti Forgery Tokens? Ie, can you submit a form from a different site directly to the formulate controller of a site?
I've not had any problems with bots yet, likely because I tend to use Cloudflare (it will block bots for you).
However, a honey pot would be a good idea. I'll look into adding that (might have some time this weekend). Or maybe I'll finally implement a CAPTCHA field (several people have expressed interest in that).
I'll also look into adding XSS protection via the anti-forgery token. IIRC, that's as simple as decorating the action method and rendering an extra field (perhaps slightly more complicated due to the way Angular is used to manage the form data).
If you feel like implementing any of this, would love a pull request.
If I was a half decent programmer I'd love to do a pull request! ;-)
For one client I did fork and hack formulate to allow for templated html emails (a real hack that just looked for an html file with the same name as the form alias and then search and replaced each formulate field in the file)...but its so hacky I wouldn't dear submit that!
This is the first client that's had issues (perhaps because they are a local government they are targeted a bit more by bots(?)) - but no other formulate forms for other clients have had any issues.
Be a great to add some of these security features though.
Will try to get to some of the other stuff this weekend, if time permits. Will also create a release containing these changes soon.
For one client I did fork and hack formulate to allow for templated html emails (a real hack that just looked for an html file with the same name as the form alias and then search and replaced each formulate field in the file)
Neat. When I can find some time, I'm hoping to do something similar. However, rather than match the CSHTML based on the form alias, the plan is to provide a drop down that has CSHTML files listed, and they'd be configurable (similar to the templates.config file already included with Formulate).
no other formulate forms for other clients have had any issues.
Glad to hear it's getting some good use. Would love to know more about how Formulate is being used in the wild. Would also like to add some case studies to the Formulate website (with your permission, of course). Feel free to send me a message here: http://www.nicholaswestby.com/contact/
If I was a half decent programmer I'd love to do a pull request!
We've inherited a site and replaced their old static contact form with Formulate. Recent heavy traffic on a new form instance has raised many errors: "The required anti-forgery cookie "__RequestVerificationToken" is not present."
Does Formulate (for Umbraco v7) use anti-forgery tokens? We're trying to figure out what is causing these errors. It is not happening for all visitors as many submissions are still being received. Perhaps the previous form system had set Anti-Forgery on?
We did download a bunch of Formulate configurations (forms, data values and validations) from a test site and released these on the live instance. We went in and re-saved most/all of those in the Live back-office Formulate. If we missed re-saving one, could this have caused the above errors?
That might happen if a bot is hitting the site (e.g., if it is trying to submit the form and it's not passing along cookies), which would not be something to worry much about.
Have you seen this behavior personally, or is it just something you noticed in the logs?
Another thing that may or may not cause this would be if you are doing output caching or are using a WAF/proxy CDN (e.g., Cloudflare) and are caching pages (in which case the request verification token from the HTML wouldn't always match the token from the cookie).
Formulate and Security
Hey Nick,
I have a client site in which the Formulate contact page was smashed by a bot - over 200,000 form submissions in a day.
What is the best way to "secure" a formulate form? Ie, is there an inbuilt honey pot, or an easy was to integrate it with a captcha etc?
Also, is there protection against cross site scripting via Anti Forgery Tokens? Ie, can you submit a form from a different site directly to the formulate controller of a site?
Cheers Trevor
I've not had any problems with bots yet, likely because I tend to use Cloudflare (it will block bots for you).
However, a honey pot would be a good idea. I'll look into adding that (might have some time this weekend). Or maybe I'll finally implement a CAPTCHA field (several people have expressed interest in that).
I'll also look into adding XSS protection via the anti-forgery token. IIRC, that's as simple as decorating the action method and rendering an extra field (perhaps slightly more complicated due to the way Angular is used to manage the form data).
If you feel like implementing any of this, would love a pull request.
If I was a half decent programmer I'd love to do a pull request! ;-)
For one client I did fork and hack formulate to allow for templated html emails (a real hack that just looked for an html file with the same name as the form alias and then search and replaced each formulate field in the file)...but its so hacky I wouldn't dear submit that!
This is the first client that's had issues (perhaps because they are a local government they are targeted a bit more by bots(?)) - but no other formulate forms for other clients have had any issues.
Be a great to add some of these security features though.
T
So far, I've added the CSRF protection: https://github.com/rhythmagency/formulate/commit/862984ac01b769f9e52b6012e0591954a76a907a
Will try to get to some of the other stuff this weekend, if time permits. Will also create a release containing these changes soon.
Neat. When I can find some time, I'm hoping to do something similar. However, rather than match the CSHTML based on the form alias, the plan is to provide a drop down that has CSHTML files listed, and they'd be configurable (similar to the
templates.configfile already included with Formulate).Glad to hear it's getting some good use. Would love to know more about how Formulate is being used in the wild. Would also like to add some case studies to the Formulate website (with your permission, of course). Feel free to send me a message here: http://www.nicholaswestby.com/contact/
Your false modesty doesn't fool me :-)
Nice!
Recaptcha has been implemented: https://github.com/rhythmagency/formulate/commit/2c6b8328e1aae1ebdbe690ee5469ef1003a0ba8e
I still want to add an enhancement or two before creating a new release though. Should be out in the next few days.
Nice, you're on fire :-)
CSRF protection and a Recaptcha field are in the latest release: https://github.com/rhythmagency/formulate/releases/tag/v1.3.0
Hey Mr Westby,
We've inherited a site and replaced their old static contact form with Formulate. Recent heavy traffic on a new form instance has raised many errors: "The required anti-forgery cookie "__RequestVerificationToken" is not present."
Does Formulate (for Umbraco v7) use anti-forgery tokens? We're trying to figure out what is causing these errors. It is not happening for all visitors as many submissions are still being received. Perhaps the previous form system had set Anti-Forgery on?
We did download a bunch of Formulate configurations (forms, data values and validations) from a test site and released these on the live instance. We went in and re-saved most/all of those in the Live back-office Formulate. If we missed re-saving one, could this have caused the above errors?
That might happen if a bot is hitting the site (e.g., if it is trying to submit the form and it's not passing along cookies), which would not be something to worry much about.
Have you seen this behavior personally, or is it just something you noticed in the logs?
Another thing that may or may not cause this would be if you are doing output caching or are using a WAF/proxy CDN (e.g., Cloudflare) and are caching pages (in which case the request verification token from the HTML wouldn't always match the token from the cookie).
is working on a reply...