When an e-commerce Web site has been compromised, there is a good chance the attacker used unvalidated input as an element of the attack. If information submitted via a Web site is not validated before it's processed, an attacker can obtain sensitive information or attack the site. Let's take a closer look at how unvalidated input works and how programmers can secure their Web applications.
First and foremost, be cautious when writing code that accepts user input. Programmers tend to assume that all users will enter in Web forms only the data they are prompted for (such as a six-digit invoice number) and wouldn't think to enter anything different. It is this trust that has led many a Web site to ruin.
One of the most common problems programmers create for themselves with unvalidated input is SQL injection. For example, consider an e-commerce site that allows customers to track an order using an invoice number. A programmer could execute this kind of function by allowing the user to enter the desired order number into a form and then pass the number to a script in a URL, such as:
www.justan.example/_order.php?invoice=?12343?
The lookup_order.php script takes the value for the invoice passed in the URL and constructs a query against the back-end database like so:
$query = "SELECT * FROM orders WHERE invoice = " . $invoice;
However, say a user tampers with the URL, like this:
www.justan.example/_order.php?invoice=?12343 OR 1=1?
Now, when the script creates the SQL query, it ends up looking like this:
SELECT * FROM orders WHERE invoice=12343 OR 1=1
This new query could potentially return all of the records in the database, thereby exposing confidential information. The attacker can do all sorts of nasty things in this situation by appending SQL commands to their "invoice number." Depending on how the database permissions are set, the attacker might be able to change or delete records or access other databases just by manipulating the contents of the field.
The problem in this example is that the code, which takes the user input and converts it to a database query, trusts that the invoice number is valid. Unfortunately, as this simple "hack" proves, this trust is easily abused. So, what can programmers do to make the code better? Rather than simply taking whatever the user submits and slapping it onto the end of a SQL query, they should take some time to make sure that what is being supplied is a valid invoice number and nothing more.
The above example is a simple one. Many other clever attacks take advantage of unvalidated input. The Open Web Application Security Project (OWASP) offers free resources for writing Web applications and tools to help coders. One useful validation tool, the OWASP PHP Filters, can sanitize input to remove any characters that don't belong. For example, assume that invoice numbers can contain digits from 0-9 and must have six or fewer digits. Adding just a little snippet of code can defang this kind of attack:
include('sanitize.inc.php');
$invoice=sanitize_int($invoice);
if ($invoice < 1 or $invoice > 999999) {
/* send the user off to an error screen */
}
$query = "SELECT * FROM orders WHERE invoice = " . $invoice;
Those few extra lines of code removed all the non-integers from the invoice field and made sure the invoice number remained within the set limits, before the query is built. This is a much better approach and notice that all of the validation is done on the server, not in the HTML. Attackers can change the HTML much more easily than the code on your server.
If you are using other programming languages, OWASP has a more general data validation project that offers advice for using regular expressions to validate data as well as Stinger, a validation library for Java. All these tools are available on the OWASP Web site .
Unvalidated Web application input is the equivalent of leaving the door to your data center propped open with a brick. If an attacker is smart enough to notice the problem, he will probably be able to craft an attack pretty quickly and ruin your day. The time and effort required to close these holes is small, so close and lock that door!
About the Author
Al Berg, CISSP, CISM is Information Security Director of New York City based Liquidnet (www.liquidnet.com). Liquidnet is the leading electronic venue for institutional block equities trading and the 4th fastest growing privately held financial services company in the US.
