Avoiding SQL Injection Attacks

Randal L. Schwartz

In recent months, the entertainment news was abuzz with how socialite Paris Hilton had had her Sidekick phone "hacked", revealing phone numbers for many famous people, interesting notes about possible profit participation in the "stolen" sex tape, and lurid pictures, all of which were broadcast widely on the Internet. But the quiet word amongst computer security professionals was that this wasn't a matter of hacking into her phone at all, not that the entertainment news people would know or care. Instead, certain individuals have claimed responsibility through a well-known security flaw on T-Mobile's Web site, with which the phone is synchronized. Thus, it wasn't the phone that was the source of information -- it was the Web site.

While the precise steps by which the intruder obtained access may never be known, one of the most common intrusion paths is the SQL Injection Attack. An intruder guesses either by trial and error or determines by examining the source code of the application some field in a form is being used to construct an SQL query. Unless the application carefully verifies the content of this field, or quotes the unusual characters properly, it might be possible for the field's value to escape beyond its intended use and create additional SQL constructs.

Let's look at a specific example. Suppose a bank Web application is trying to show all the bank account balances that belong to me. The SQL might look like:

SELECT account_id, balance
FROM account_data
WHERE account_owner = '[ME]';