Programmatic POST Requests with JavaScript: Form Emulator in Action

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:

window.onload=function(){

            if(document.getElementsByTagName&&document.createElement){

            // send first get request to form page

            sendRequest('post_form.htm','','get',false);

}

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.

So, two minor changes must be introduced into the script. First, I’ll include a call to the “getFormCode()” function within “displayStatus()”. Doing so, I make sure that once the server’s response has been sent back to the client, form parameters are available within the program. Finally, I’ll wrap the post requests into a JavaScript timer. In this way the whole form submission process will be programmed within an automated execution.

As I said previously, here is the “displayStatus()” function, including the call to “getFormCode()”:

// function displayStatus

function displayStatus(){

    // check XMLHttpRequest object status

    if(objhttp.readyState==4){

        // create paragraph elements

        var parStat=document.createElement('p');

        var parText=document.createElement('p');

        var parResp=document.createElement('p');

        // assign ID attributes

        parStat.id='status';

        parText.id='text';

        parResp.id='response';

        // append text nodes

        parStat.appendChild(document.createTextNode
('Status : '+objhttp.status));

        parText.appendChild(document.createTextNode('Status
text : '+objhttp.statusText));

        parResp.appendChild(document.createTextNode
('Document code : '+objhttp.responseText));

        // insert <p> elements into document tree

        document.body.appendChild(parStat);

        document.body.appendChild(parText);

        document.body.appendChild(parResp);

        // get form code

        getFormCode();

    }

}

And next, programmatic post http requests are wrapped up in the JavaScript timer:

window.onload=function(){

     if(document.getElementsByTagName&&document.createElement){

     // send first get request to form page

     sendRequest('post_form.htm','','get',false);

     // send post request every 10 seconds

     setInterval("sendRequest(getFormAction
(),getFormVariables(),'post',true);",10*1000);

    }

}

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.