The Anatomy of a SQL Injection Attack

SQL injections are one of the most dangerous attacks used against web applications. In 2010, they were ranked in the top spot for the OWASP Top Ten and second in the CWE/SANS Most Dangerous Programming Errors.



FAQs

Got questions about dotDefender? Please visit our knowledgebase for answers or contact Support at support@applicure.com.


Featured Blog Posts

What is Cross-Site Scripting (XSS)?

Cross site scripting, or XSS, constantly holds the number one spot as the most common ... read more ...

Microsoft confirms critical IE bug, works on fix

suggests using blocking tool, but does not plan to issue emergency patch ... read more ...

WikiLeaks, the Mega-D botnet and online privacy led the way in cyber-security news this past week.

... read more ...

The reasons SQL injections are so dangerous are:

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.

Hacme Home

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:

Hacme Login

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:

Hacme Profile

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:

Database Security Best Practices
Google Codelab
Who is Minding Your Data in the Cloud?

Please Wait...