SQL injection – past, present and future

SQL injection was first introduced in the late 90’s. A successful execution of this attack results with direct access to the database used by the application, giving the attacker the ability to manipulate SQL queries. As a result, the attacker may be able to insert, update, delete or retrieve information from the vulnerable application.

SQL injection is used in order to exploit the web application, one example being “bypass authentication”. In many cases, web applications require a login to the application before getting access to privileged information. When a user performs a login action he is actually sending his username and password to the web application, then the web application validates the user’s credentials against stored data in the database.

In order to explain how SQL injection can be executed in this case, I will show a pseudo example of a possible SQL injection flaw.

After the user submits his username and password to the application login page, this HTTP request is sent to the web application:

When this request arrives to the web server, the web application extracts the value from the username and password fields and creates an SQL query to the database trying to figure out if “david” is a legitimate user and if so make sure his password is indeed “123456”. In this case the SQL query will look like:

All seems OK so far, but what if we send something else instead? For example, assuming that the attacker knows ‘david’ is a legitimate user to the application but the attacker does not know David’s password and the attacker would like to get into David’s account, the attacker can send this value in the password field: ‘ or ‘1’=’1. This value will be sent to the application and the new SQL query will look like:

‘ or ‘1’=’1 is a logical condition that will always return true. Adding this value to the SQL query changes the logical condition and as a result, the query will always be true regardless if the right password was supplied, allowing the attacker to bypass login authentication.

Over the years this vulnerability was wildly used to exploit applications in a variety of incidents. As a result, application IT and developers’ awareness grow side by side with the attacker’s sophistication.

More than 10 years after it was first introduced it is still a very effective attack. Looking at the reported SQL injection vulnerabilities at BugTraq in July. I can see 33 new SQL injection vulnerabilities on a variety of web applications. This is a substantial amount of vulnerable applications, taking into consideration that these are the vulnerabilities that were found and reported. What about the rest of the vulnerabilities out there?

• Those that were never found by White Hat penetration testers
• Those that were found but were not patched
• Those that exist on custom-made applications (and not reported in a list of vulnerabilities for generic applications, such as BugTraq)

While there is no doubt in the present that web application administrators need to use effective ways to find and mitigate such vulnerabilities, future threats are just around the corner. One that I came across last week was the new Denial of Service (DDoS) tool developed by Anonymous, the tool which is said to exploit SQL vulnerabilities to support the group's future campaigns.

SQL injection is usually associated with information leakage (though it can also be used to bypass authentication or injection of malicious data), but it can also be used as a means to bring the application “down to its knees”.

SQL injection has been with us for more than 10 years and it looks like it is here to stay. A valuable way to protect applications from SQL Injection, DDoS and other attack vectors is by using a web application firewall (WAF) like BIG-IP ASM. Also, inserting a WAF into the software development lifecycle allows developers to design applications that are tested, and security policies created, that protect web sites from vulnerabilities like SQL Injection before there are released into production. Deploying a WAF is the first step in creating a protected environment for applications to stay at peak performance while holding vulnerabilities at bay.