David M Williams
Thursday, 13 November 2008 18:42
Opinion and Analysis
Page 1 of 3
15 years ago Dan Farmer wrote a program called SATAN designed to help sysadminis detect vulnerabilities in their networks. He was criticised because of the massive potential for malice if used by "the wrong people" and was fired by his employer, SGI. Now, I'm not in Farmer's league but I'm going to risk my reputation here and now to practically explain SQL injection by cracking two publicly available web sites.
Chances are you've heard of SQL; that's an internationally-recognised standard language used for creating, querying and manipulating databases, whether by Microsoft, Oracle, IBM, Sun Microsystems or any other vendor.
SQL instruction are fairly robust when a programmer or database admin is entering them against a database directly. Yet, the vast bulk of database queries are performed by software, not by humans. Any program which persistently records information is most likely using a database in the background.
Consequently, the program is generating SQL commands on the fly, and building into them pieces of information which were supplied by an end user. And there's the risk; end users aren't always going to type in sane or sensible or safe things.
“SQL injection” is thus the term assigned to a particular form of hacking/cracking action that seeks to exploit such dynamically-generated SQL instructions by inserting extra commands.
Let's illustrate with an example. Suppose you have a database table called USERS with fields USERNAME and PASSWORD. A web site might prompt people to log in with a form that has two fields, txtUsername and txtPassword. The expectation is you type in your valid username and password, and that only legitimate users will do this, and that they won't try anything funky.
When the user clicks “Login” the backend of the web page validates your credentials by executing an SQL query like this:
“select * from USERS where USERNAME = '” + txtUsername.Text + “' and PASSWORD = '” + txtPassword.Text + “'”
This query requests the database divulge all the users who have a username and password matching that which has been entered by the web site visitor. Assuming the user entered a username of Tom and a password of gluc77 the SQL query actually sent to the database would be
select * from USERS where USERNAME = 'Tom' and PASSWORD = 'gluc77'
All well and good. You will notice that we use the single quote character to delimit text strings. And here's where our injection comes in. Want to log in for free? Try entering a username of ' or 1=1 --
Now, let's get that clear; the actual username to type in is
' or 1=1 --
The username begins with a single quote and ends with two minus signs. It doesn't matter what the password value used is. The SQL query sent to the database becomes
select * from USERS where USERNAME = '' or 1=1 -- ' and PASSWORD = ''
In SQL -- is a special sequence that means everything following is purely a descriptive comment for human beings and ought to be ignored by the database. Therefore the command executed is
select * from USERS where USERNAME = '' or 1=1
The database now duly returns the entire table of users because there are now two possible conditions that can be satisfied. Either the username is blank ('') or the value of 1 is equal to 1, which of course it always is. So, every single line in the table matches. The web site will pull out the first row and proceed, effectively logging the web site visitor in as that person – which typically is the web site administrator.
Well and good, but what's theory without practice? Here's how to find a site that is vulnerable to such an attack and, in fact, two such sites that (at the time of writing) are indeed ripe for it.
CONTINUED
