A new report by iMPERVA shows that
from 2005 through today, SQL injection has been responsible for 83% of successful hacking-related data breaches.
Based on the sites they were monitoring, over half of attacks originate in United States.
Country Number of Originating Attacks %
United States 48176 58
Sweden 8850 11
China 6709 8
Great Britain 4970 6
Vietnam 2412 3
Netherlands 1963 2
Bulgaria 1359 2
Ecuador 1356 2
European Union 1093 1
Germany 971 1
Other 4748 6

The vectors of attacks are:

  • Direct Query Manipulation This is often done by appending a logical expression with a known value to the parameter that the application expects, like:? OR 1=1 to get a true value or 1?/**/ aND/**/?8?=?3 to get a false value. This type of vectors is most often used to establish the existence of a SQL injection vulnerability.
  • Discovering the Database Structure Assuming that the application exposes SQL errors it encounters, one of the ways to discover the number of columns in a table is using the SQL Order By clause: the database returns an error when the order parameter is an invalid column. The traffic shows that some attackers begin by sending: 6? Order By 10000 /*. Since 10000 is an invalid identifier for a column, the attacker hopes to receive an error. Upon error, the attacker proceeds to decrease the parameter (e.g. 6? Order By 50 /*) until the commands complete without an error (this is usually done in a binary search fashion to achieve improved efficiency). This, in turn, confirms that the current parameter for the ordering of the results is in fact the number of columns in the table.
    The process continues by querying the database metadata tables to discover the names of those tables and columns that may contain valuable information. An example of such observed attack contains the following input: 2755?) and 1=convert(int,(select top 1 table_name from information_schema.tables))--
  • Union Select SQL Injection The UNION SELECT statement allows the chaining and retrieval of the results of two separate SQL SELECT queries that have nothing in common. Upon success, the injection of Union Select allows the attacker to retrieve data from a particular database table even though the application was designed to access another table.
    Some of the observed attacks simply performed checks to see whether the application is vulnerable to Union Select injection, for example by injecting into an HTTP parameter the value: 34 UNION SELECT 12345. In a more dangerous example, the following value was injected into an application?s forum page in order to retrieve the personal details of a user, for which the attacker guessed the application-given identifier: XXXX%?) UNION SELECT MEMBER_ID, M_STATUS, M_NAME + ?/? + M_EMAIL + ?/?, M_LEVEL, M_EMAIL, M_COUNTRY, M_HOMEPAGE, M_ICQ, M_YAHOO, M_AIM, M_TITLE, M_POSTS, M_LASTPOSTDATE, M_LASTHEREDATE, M_DATE, M_STATE FROM FORUM_MEMBERS WHERE (M_NAME LIKE ?.
  • Time-based blind SQL injection Sometimes, when an attacker executes a SQL Injection attacks, the server responds with error messages from the database server complaining that the SQL query syntax is incorrect. To prevent exposing any information about the database to an attacker, secure applications respond with a generic prepared error page. This makes exploiting a potential SQL Injection vulnerability more difficult but not impossible. Blind SQL injection is a technique for stealing data from the database by asking a series of True and False questions through SQL statements. An attacker may verify whether a sent request returned True or False in a few ways. One of these methods is using a time consuming operation, e.g. ?waitfor delay?, that will delay the server responses if the expression is True.
    For example, we have observed injection into a web form?s returned HTTP parameter of the value: x? wAiTfOr dELay ?0:0:20?--. In this case, the attacker checks if the application is vulnerable to SQLi. If the application and its database accept the injected value x, it will also wait for 20 seconds ? a noticeable delay that the attacker?s tool can identify, marking this parameter as vulnerable to injection. In a similar but more specific usage, we have observed injection into the New Customer parameter of a Login form of the value: No?);waitfor delay ?0:0:05?;--. In this case the attacker attempts to bypass the application?s login flow, with the hopes that a successful injection (identified by the five seconds delay he specified) will let him impersonate an existing user.
    As a side note, injection of waitfor delay can be used by an attacker to tie up resources in the application and cause Denial of Service.
  • Bypassing simple parameter sanitation Attackers are aware that applications usually sanitize the user?s input before creating a database query from it. However, if this validation of the input is naive, an attacker can bypass it by simple means like inserting SQL-ignored comments (denoted by /* and */) into the input string (e.g. 1?/**/aND/**/?8?=?3), switching between lower-case and upper-case characters (e.g. x? wAiTfOr dELay ?0:0:20?--), or using SQL string functions like concat() and char() to create the value for injection indirectly, without triggering the application?s injection detector. Another frequent evasion technique in the traffic is to encode the injected command using its characters? ASCII values, like: 1 DeClARe @x varchar(99) set @x=0x77616974666f722064656c61792027303a303a323027 exec(@x)-- which the database translates and understands as: 1 waitfor delay ?0:0:20?--.

Given recommendations to prevent SQL Injection attacks are:
  • Detect SQL injection attack. Using a combination of application layer knowledge (application profile) and a preconfigured database of attack vector formats. Detecting SQLi must normalize the inspected input to avoid evasion attempts.
  • Identify access patterns of automated tools. In practice, SQLi attacks are mostly executed using automatic tools. Various mechanisms exist to detect usage of automatic clients, like rate-based policies and enforcement of valid client response to challenges.
  • Create and deploy a blacklist of hosts that initiated SQLi attacks. This measure increases the ability to quickly identify and block attackers. Since we observed that the active period of host initiating SQLi is short, it is important to constantly update the list from various sources.

For full report click here.