Bot-free web forms
Kent Elchuk discusses how to create and boost the security of web forms, before explaining the intricacies of bots and spam.
Kent Elchuk explains how to make and secure your web forms, and the intricacies of avoiding bots and spam.
Forms are ubiquitous on the web. We use them to log in to Facebook, access our Wordpress Admin panel and ask a company about a specific product or service. This covers what we see in a browser. But that doesn’t explain how they work. So let’s get under the hood and take a closer look.
By the time we get through this article, we’ll cover many of the intricacies of forms, such as writing code, so users can provide input and write more code to deal with that input after it’s submitted. On top of forms, we’ll cover details about security and web bots, thus revealing that there’s much more to web forms than meets the eye. Without enough knowledge of building, securing and deterring spam from forms, we could end up with mass submissions that can clutter an email inbox with dubious adverts for pharmaceutical firms and unwanted SEO services.
Making forms
In general, web forms are created in two different ways. One is using server-side code to interpret the data and ‘do something with it’ while the other uses Javascript (or a Javascript library such as Jquery) to handle the data. With the later, a common method called Ajax is used to use handle web form data. Although it uses Javascript (or Jquery), Ajax, will interact with a serverside language such as PHP to handle the form submissions and interact with the page. This means that data can also be updated on the page without having to do a page refresh.
A form posted without Ajax will reload the entire page that housed the form. Although this works, it’s certainly not a polished method by any means. To illustrate this, we’ll start with the most basic Contact Us’ form. The form tags start with <form> and end with </form> .
As we can see below on the first line, the first form tag also contains two attributes. One attribute is action which sends the form data to the specified url; which in this case is a file called contact_submitted-LF.php. The other attribute method tells how to send the form data, which in this case is by POST. Another common option is GET, which isn’t secure unlike POST. Now, let’s take a gander over the HTML code below and we can see what it all means afterwards. Okay, we’ve already covered that the form sits inside the
<form> tags. What we also need to know is that there are several input fields, a text area and a submit button that is used to acquire the data and send it.
Let’s start with the input fields and text areas. They all have the name attribute and a special value attached to them. For example, name=”names” will be how the interpreter tracks the information from the box where people fill out their name. The same process holds true for the other inputs and the textarea box. We must note that the submit input type isn’t text like the other input elements. Instead, the type is called
submit . Like the other fields it has a name attribute, called submit here. However, it also has a value that’s simply the text you see in the button when it’s viewed in a browser.
Now that we see the details of the form, our next step is to deal with the post data so that it does something useful, such as insert the data into a database and/or send an email with the details. In our case, we’ll send our form by email. With that in mind, let’s take a look over the code below then explain what’s going on. The server-side language that will be used to process forms is PHP: try to write data in the text fields that can cause, for example, an SQL injection and write to a database. These precautions taken above are required in the modern era. Next, the filter_input_array() function creates an array of the inputs from the form. Thus, the email address the user entered is $filtered[‘email’] while their name would be $filtered[‘names’].
As we move on to the next line, we have conditions to check and make sure the posted data isn’t empty. If there are empty name, email or message fields, the user is prompted a message to go back and fix things up. In addition to data checks, we have checks to ensure the user has no links in the email. Often, links are a sign of spam. Thus, in our case, we are intolerant and send them back to remove them.
It’s the substr_count() function that performs these link checks for both the actual beginning link code <a and its HTML entity <a to cover both possibilities.
If all goes well, we have a visitor that entered a valid email address, good names and a decent message. At this point, we create and gather variables for the email recipient, subject, message and headers. In our case, our email will be sent to test@example.com. The subject will be Enquiry from Website. This way, we know it came from our form. The body variable will be the email body and it contains the sender and message.
Finally, we gather the sender’s email address so we can easily reply to it. The function that ties it all together and sends the email is PHP mail() . If we wanted to go an extra step, we could have obtained the user’s IP address and added that to the email body. In a worstcase scenario, it gives us the option to blacklist the IP from visiting our website.
Although all of the above seems somewhat secure and safe, the truth of the matter is that it’s not spam proof. A half-witted spammer could easily use the small snippet of code shown below and run automated tasks to send their email. In addition, although not shown in the example, the visitor could spoof things like browser agents and make arrays of names, messages and email addresses that could look like a different user is filling out our forms, even though it’s the same basic script that’s wreaking havoc.
Here we have some code that can be run from the command line, a cron job or from a browser. So, let’s look it over and see what it does. After that, we’ll cover methods to ensure these tactics can be dealt with adding features like Google Recaptcha. We start by creating an array of items that are the $postfields array. These include the action required for the form which is submit , the names variable, our email address and message. After that, we define the $url where we’ll submit this data; which is https:// example.com/contact_submitted-LF.php .
The rest is essentially working with curl functions. We initialize it to the $url we defined, make options, add our $postfields , execute it and close it. That’s it. Once we run the file, the form owner receives an email with the data from this script and we never even had to type anything into the online form. Amazing! Like penetration testing on your own website, attacking our forms is our best way to ensure they don’t get out of control. Luckily, aside from data checking, integrating Google Recaptcha works great with forms because there’s another layer of checks to ensure an actual user is filling out the form and not an automated script.
To make the last remarks more clear, the reason Google Recaptcha works is because the form sends an extra post variable that will be checked to ensure it wasn’t a bot or script filling out the form. To use Recaptcha, we need to sign up and list our website to receive a client side key and a server side secret string. The site is www.google.com/recaptcha. Once we sign up, we can add it to our website. Almost immediately, we’ll receive our ‘key’ and ‘secret’. It’s very easy to implement after that. So let’s examine how we add it to our website.
To start with, we open our page which has the form. Once we do that, we add the code below before the closing tag:
</head> <script src=’https://www.google.com/recaptcha/api js’></script> After that, we add an empty <div> tag into the form. An example is shown below:
Now, let’s go back to our code that did the checking for names, email address and empty messages. We can add the code below, which will send a response from the form and our key, as follows: Because the preceding code can check and filter spam, that’s a great help. Of course, we’ll use it as extra defence around our mail() function to add that extra layer we had previously not accounted for, which is the bot script that passed our other filters.
By this point, we know how to create, test and secure our web forms so that our inbox doesn’t fill up faster than a McDonalds at lunch time.
Now let’s move on and take look at some means why we may want to add a third layer of protection:
defending against automated form fillers in the browser. Because browsers such as Chrome have extensions that can be added, like Form Filler, they do enable web users to fill in forms with text without having to type. Yes, you guessed right. A visitor could click an icon to fill in the form, then tap the Google Recaptcha and click Send.
Before we know it, nonsense spam shows up in our inbox from someone whose idea of a good time was annoying us. To makes things worse, the user sends us three or four spams until Google Recaptcha actually asks the user to ‘click all images with storefronts’ or ‘click all images with street signs’ before they actually stop and realise that they’d better wait until the next free Wi-Fi zone they stumble across to spam again.
We really should do something to avoid this. Luckily, using session control, we can.
Wordpress forms
Because so many sites are built with Wordpress, we’ll scratch the surface of its most popular form plugin called Contact Forms 7. Of course, we need a Wordpress installation to use it. The plugin can be installed with a single click when we’re logged into the Wordpress admin. Once it’s installed, we need to make a couple of small tweaks and then we’re off to the races.
To access our Contact Forms 7 plugin, we can select Contact from the left menu, or select one of the child options like Contact Forms, Add New, and Integration. The Integration option enables us to define our Google Recaptcha site key and secret string so we can add it to any form we want. The code below shows what it looks like when we create a new form and add Recaptcha with it.
Once we have our new form, we can click the mail tab and set our email address for which we want the mail sent to, then click Save. That is all there is to simple Wordpress forms. We should note that we did add Recaptcha to the default form. Without Google Recaptcha, the curl script we have discussed earlier could be used to auto-submit Wordpress forms.
When you think about it, there are likely to be countless websites running insecurely with this wellknown plugin. The differences to the code we’ve already written about is just the different post fields. With contact forms, we can still read the HTML with a browser Inspector and acquire the post URL, and all post variables, too.
An example is shown below, as we could just modify the few lines we wrote earlier, adapting them for Wordpress Contact Forms. For example:
Not so Spam-a-lot
Now we have a grasp on building web forms and securing them to ensure we can minimise unwanted traffic and automatic bots that are trying to send generic messages to as many sources as possible. The next stage might be to create more advanced web forms that can be used to create our custom web applications. Happy web forming!