Programmatic POST Requests with JavaScript: A Functional Form Emulator
(Page 1 of 5 )
Welcome to the third part of this series, aimed at explaining specifically how http requests can be used by malicious users to launch attacks against unwarned websites. Since in the previous article I provided you with the core functions for building a JavaScript-based form emulator, this third part will be used to complete the definition for the remaining functions, and set up the basis for making the program fully functional.
Introduction
To refresh for a moment what the form emulator should be capable of doing, before jumping directly into the complete program’s source code, I’ll briefly explain its basic logic. In this way, the existence of each defined function will be clearer and easier to understand.
The first thing that the program has to do is logically send a synchronous get request (using the XmlHtppRequest object) pointed to the file that contains the targeted form to be potentially attacked. While this method certainly is not the only one used by attackers, definitely it’s one of the most usual and easiest to setup, so this rather generic form of attack should be kept in mind when designing “secure” forms.
Once the first request has been made successfully, and hopefully the server response has been sent back to the client, the program will extract from it the code corresponding to the Web form, as a simple way to obtain its action attribute, as well as its variables (in other words, the form field names).
Having this data available, the script will make a new asynchronous post request to the URL specified by the form’s action, by populating the obtained form variables with pseudo randomly-generated data. This completes the form emulation process. Eventually, additional post requests might be made to the same URL, sending dynamically generated form values, either by using random strings or previously stored data, such as database table values, flat file data, or even array values.
Of course, as you can see at first glance, this method is not bullet-proof due to many reasons. The targeted server could be temporarily down, the requested form page could not be available, or the form page could contain more than one form (or a single form divided across several pages). Surely, you’ll find other possible reasons for this attacking method to fail.
However, the flip side is that there will be numerous times when the process will be able to be successfully performed, and the selected Web server will be considered by the attacker as an easy-to-hack target. Thus, keeping in mind this situation, Web developers along with system administrators should work in a collaborative way, to make public Web-based systems considerably safer and robust.
Now that you have a fairly detailed idea of how the script fires up harmful requests, we can go forward and see the source code for each involved function within the program. So, join me in the next explanation; it’s going to be instructive to those who want to be warned against some common hacking techniques.
Next: Building a functional script: listing the “getXMLHTTPObject()” and “sendRequest()” functions >>
More JavaScript Articles
More By Alejandro Gervasio
/ 14 
