Technology news and Jobs
The Linux distillery
A real-world web site crack before your eyes
The Linux distillery
A real-world web site crack before your eyes | A real-world web site crack before your eyes |
|
| by David M Williams | |
| Thursday, 13 November 2008 | |
|
Page 1 of 3 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 |
| < Next story in category | Previous story in the category > |
|---|








