The Anatomy of a SQL Injection Attack

The reasons SQL injections are so dangerous are:

• They are common - roughly 60% of all breach incidents involved SQL injections
• They can be automated - large botnets can launch attacks against numerous web sites
• They can help an attacker escalate privileges
• They can give an attacker complete access to a database
• They are profitable for the attacker

Performing a Simple Attack

The following walkthrough will take you through a simple SQL injection attack to see just how this works. This is not meant to be a “hacking” tutorial. It is simply a way to show you just how easily a web site can be compromised using this technique.

While you can see just exactly how this works, you can try this for yourself by downloading HacMe Casino from Foundstone. HacMe Casino is a web site that was built with multiple vulnerabilities left in it.

As you can see from the screenshot above, there is a login section. This is an ideal entry point for this type of attack because the authentication process of most web applications checks the credentials against a database that makes use of SQL.

In order to properly execute this attack, we need to trick the database into believing that what we enter is true. For example, a valid user with the Login John_Doe and the Password winbig could enter these credentials into the text boxes and click Login. When they are checked against the database using the query SELECT * FROM users WHERE (username=’’ AND password=’’). Imagine that in this example, both are both TRUE so the user is granted access. But what if these credentials don’t match up against the database? Let’s see what happens:

The result is an unsuccessful login because the statement was not TRUE. The Login did not equal John_Doe and/or the Password did not equal winbig. We could keep trying to brute force our way in but even with a tool to automate this, we could be waiting for a long time. Instead, what if we entered something we knew to be true? Take for instance the statement 1=1. That is a true statement, but it is not going to work. We need to enter in a valid SQL string so let’s use ') OR 1=1-- instead. By entering this as the value for the Login, and leaving the Password value blank, we are presented with this:

We are now successfully logged in as Andy Aces. And why Andy? Because he had the unfortunate luck of being the first entry in the users table of the database and the query SELECT * FROM users WHERE (username=’’) OR 1=1—AND password=’’) returns just that.

Another way this can be put in place is to look at the URL when successfully logged into a site. For instance, an attacker can create a legitimate account on a shopping site. When they login, he notices that the URL reads: http://onlinestore.com/accountView?id=Gf4b3sO8550. Changing the id to the string used earlier, ') OR 1=1--, could cause the server to display a page with all the account records, not only the attacker’s.

Considerations

The examples listed above represent a SQL injection vulnerability in its simplest form. Most attacks launched against web sites involve much more sophistication, but that doesn’t mean to say that something as simple as a=a won’t work.

Seeing just how easy this type of attack is to perform makes it clear as to why it is something that needs to be taken seriously and needs to be defended against.

Related Articles:

Why Web Application Security?
Securing Cloud Data
OWASP Top 10 2010