As an example of this attack, we will suppose an authentication form of a blog, with a username and password field, similar to the figure in the right. When this form will get submitted, the following SQL query will be used to validate if there is such a user with the specified username and password.

“SELECT * FROM users WHERE username='” + usernameVar + “' AND password='” + passwordVar + “' LIMIT 0,1”

The input variables “usernameVar” and “passwordVar” are concatenated with SQL query without being sanitized. Functionality wise, the query looks to be acceptable since it is selecting for one user with the specified username and password. But security wise, this query possess a big flaw. The issue is highlighted if the attacker will provide a value of ‘ OR ‘1’=’1 instead of a valid username and password. Therefore, the SQL query will become like the following:

SELECT * FROM users WHERE username='' OR '1'='1' AND password='' OR '1'='1' LIMIT 0,1

Now, the query is being tampered with the attackers input by changing the queries conditions. This query will select any user with a blank or whatever username since the OR ‘1’=’1′ part is always true. The same applies for the password condition as well. Basically, the query will return the first user in the Users table since it also contains the limit part at the end. Obviously, by using this query the attacker could bypass authentication and use another valid user identity as its own. Furthermore, the attacker can sophisticate the query by identifying somehow the administrator’s username. Many times, the administrator username is shown publicly, or can be easily guessed [11]. If the attacker has the administrator’s username, it can use it in the username field, and a value of ‘ OR ‘1’=’1 in the password field. Assuming that the administrator’s username is “admin@email.com”, the query would be like this:

SELECT * FROM users WHERE username='admin@email.com' AND password='' OR '1'='1' LIMIT 0,1

This query will select a user with the username of “admin@email.com”, and it will bypass the password condition same as in the earlier case. Hence, in this example except authentication bypass, the attacker also escalates its privileges to the administrator by using his account.

Blind SQL injection

This form of attack is very effective in cases when the applications are not displaying any output either database errors or data in user views. In these conditions, the attacker cannot gain knowledge of database directly. Therefore, the attacker can use this technique of doing SQL injection attacks by “blindly” testing the database with boolean logic (true or false) queries and observing the outcome. Hence, this is called Blind SQL injection. Generally, this type of injection is considered to be more difficult. [12] [13]
In the following example, it will be used a Blind SQL injection attack to check if the application is vulnerable to SQL injections or not [14]. Assuming that there is a blog that displays an article with the specified ID as a URL parameter. The URL to access this specific article would be something like:

http://myblog.com/article.php?id=2

And the SQL query to select the article would be like:

SELECT * FROM articles WHERE id=2

In this case, the attacker can inject a query with the intention of returning false, as:

http://myblog.com/article.php?id=2 AND 1=2

In SQL query would look like:

SELECT * FROM articles WHERE id=2 AND 1=2

If the application is vulnerable to SQL injections, it will display nothing. To make sure of that, the attacker can also inject another query that will return true and expect to display the article, as the following:

http://myblog.com/article.php?id=2 AND 1=1

Which would be reflected SQL query like:

SELECT * FROM articles WHERE id=2 AND 1=1

If in the second query the article is displayed, we can conclude that the application is vulnerable to SQL injection. This injection technique can be further refined to construct more sophisticated attacks. The following is another example of Blind SQL injection, which will return true if the MySQL version is 4. Otherwise, the last digit (four in this case) can be changed accordingly until we get the result of true. Whatever number that will cause the application to return true, that would be the exact version number of MySQL database. [14]

http://myblog.com/article.php?id=2 AND 1=1

SELECT * FROM articles WHERE id=2 AND SUBSTRING(@@version,1,1)=4

Database Management System (DBMS) Specific SQL injection

When an SQL injection query successfully exploits an application, does not mean that the same query can work in another vulnerable application. This is due to usages of different DBMSs by different applications. In many cases, DBMS’s implement the same functionality with different SQL statements or have very specific functionalities which can be missing to others. An example of this can note with the timeout functionality. Considering the previous example with Blind SQL injection, we can similarly check if the application is vulnerable to SQL injection by calling a timeout functionality. Then, the timeout should be reflected by making the application delay the result display for a specific amount of time. The following are examples for the timeout functionality injection in different DBMSs. [12] [15]

MySQL:

http://myblog.com/article.php?id=2 AND sleep(10)

SELECT * FROM articles WHERE id=2 AND sleep(10)

MSSQL:

http://myblog.com/article.php?id=2 AND WAITFOR DELAY ‘0:0:10’

SELECT * FROM articles WHERE id=2 AND WAITFOR DELAY ‘0:0:10’

PostgreSQL:

http://myblog.com/article.php?id=2 AND pg_sleep(10)

SELECT * FROM articles WHERE id=2 AND pg_sleep(10)

Compounded SQL injection

This type of SQL injection is relatively new term which represents SQL injection attacks in combination with another type of web application attack [10]. The main combinations of such attacks are [10]:

• SQL Injection + Insufficient authentication
• SQL Injection + Distributed Denial of Service (DDoS) attacks
• SQL Injection + Domain Name System (DNS) hijacking
• SQL Injection + Cross-Site Scripting (XSS)

As an example of a Compounded SQL injection, we will show an SQL injection in combination with a DDoS attack [8]. All DBMS’s have a default value of maximum database connections they can support at the same time. This sometimes is also overwritten by the applications. If this number is exceeded, the database is expected to continuously respond with an error until the number is decreased within the limited range [10]. Now, assuming to have the same vulnerable blog from previous examples, we can inject a specific SQL query that will try to exceed this number by causing a Distributed Denial of Service (DDoS). Also, assuming that the application is built with ASP.NET technology, in which the default connection pool size will be limited to 100 parallel connections for 30 seconds [16]. In this case, the sleep functionality can be used to exceed the 30 seconds limit. Besides this, attackers can create automated tools to engage more than 100 parallel connections. The connections would be targeted to a URL with SQL like below:

http://myblog.com/article.php?id=2 AND WAITFOR DELAY ‘0:0:50’

SELECT * FROM articles WHERE id=2 AND WAITFOR DELAY ‘0:0:50’

In this case, the attacker does a DoS attack that was caused by using an SQL injection technique, and therefore, this is called a Compounded SQL injection attack. While this attack takes place, the application will not be accessible to its legitimate users.

References