In the fourth and final part of our series, we examine the form emulator we built in the third part in the context of a practical example that puts the program to work. The form emulator can be used as a simple testing bed to help you build more robust and safer Web applications.
Having previously defined all of the functions that integrate the form emulator script, running the program is fairly easy. First, I’ll execute the script once its page is loaded, and then make a get http request to “post_form.htm” -- equivalent to clicking on a link that takes you to this page or manually entering the proper URL in the browser’s address bar. Considering this, below is the simple code to run the program when the script page is loaded:
After running the above code, this is the output that I get on my browser:
As you can see, the first get request returns the code of the form page, which is displayed in the browser. Until now, I’ve not done anything that could be considered a form emulation process. Actually, I’m not so far from that. What I need to do is simply obtain the form’s action URL, then point the script to that address and make a post http request, by using the “getRandomValue()” and “getRandomEmail()” functions to populate form variables.
As I said previously, here is the “displayStatus()” function, including the call to “getFormCode()”:
After executing the above snippet, I’m emulating genuine form submissions, since the script is making post requests to the form’s URL (remember it was “processform.php”) by sending random data. Below is the output returned by the program:
By taking a look at the screenshot depicted above, it is clear to see what’s happening when the script is run. Definitely, the program is emulating human-based form submissions by firing automated post requests. What’s more, notice that the “processform.php” file is inserting random data into the database and accordingly displaying the information, as the expected behavior in a “regular” form sending condition.
Although the example is fairly simple, it really demonstrates how unprotected Web forms can be easily emulated, by making programmatic post requests. Considering the specific situation described in the example, an attacker might be running a similar script to fill a database with multiple “bad” entries, inflicting noticeable damage to the targeted system. Side effects might be even more harmful if form data is processed in some additional ways, such as sending it by email, logging it to a file, and so forth. You get the idea.
Since I explained the malicious usage of automated post requests, I need to be fair and highlight the good points of using this method. Very often it’s desirable to test an application as thoroughly as possible, by emulating real conditions before the application is considered appropriate for use in production environments.
Having in mind this concept, small client programs, such as the one described above might be useful as “quick and dirty” testing beds within the development cycle of an application. As stated previously, generally a tool on its own cannot be analyzed from an ethical point of view, since the consequences of its usage are firmly tied to people’s ethics, rather than to the tool itself.
Now that the form emulator program has been explained in detail, I’ll provide you with the full source code, so you’re able to study it and introduce your own modifications.