Summary: After all, what are SQL injection attacks?

Nowadays, the majority of the corporate web applications use relational databases to store data belonging to the company itself and to its customers, including sensitive information such as:

• Access credentials and personal information;
• Catalogue of products and services;
• Orders, bank account statements and information about payments;
• Client lists and contacts at suppliers.

The format used by the majority of the web applications for access to these databases is a query language developed in the 70’s by IBM laboratories, i.e., the query structure language, widely known under the acronym SQL. Normally, the applications do incorporate data supplied by user in SQL language, aiming at building specific interactions to system functionalities and to its database.

If instructions are assembled in an unsafe way (allowing user to modify the general structure of the query request) the application can become vulnerable to what we commonly call SQL injection, i.e., a flaw that allows an ill-intentioned user to reprogram the communication between the application and the database, and, by doing so, he/she may obtain as a result the manipulation or arbitrary extraction of data.

Bearing in mind the way applications support themselves in an exclusive way into the database, this type of vulnerability can yield reflections in all the corporate system, facilitating theft of access credentials and confidential information, modification of vital processes and even the jeopardy of business.

Technically, the attack exploits the syntax of the interpreter of the SQL database, independent of technology and it is normally found in all types of application developed for the web. Some program languages such as PHP and ASP are more susceptible to this type of attack, however, this does not mean that other languages and frames could not be equally exploited.

Is my application vulnerable to SQL injection attack?

To better understand if your application is vulnerable to SQL injection flaws, we will describe the way on how an application can be exploited from the utilization of an interaction with a code that has apparently been working in a correct way. A  hacker begins its “job” starting from the analysis of some specific points of the application:

• Performs inspection in the forms and data input points of application which apparently are not filtering the use of meta-characters (error codes and failure message);
• Performs tests for construction of SQL requests in order to dodge eventual protection mechanisms for use of meta-characters;
• Combines attack with utilization of stored procedures to conceal injection of meta-characters;

Example of attack:

Initially, we will use a query described below as example of vulnerability. When an user uses the research field to look for all the CRAFT editor’s books, the application executes the following query toward the database:

SELECT autor, titulo, ano FROM livros WHERE editor = ‘CRAFT’ AND publicado=1

This query forces the database to verify each line within the book table, to extract each record where the editor column bears the CRAFT content and published with value 1 and, at the end, to return the set of all these records, publishing the result on an HTML page. Now, the user wants to perform a search for all books produced by the L’CRAFT and this makes the application execute the following query:

SELECT autor, titulo, ano FROM livros WHERE editor = ‘L'CRAFT’ and publicado=1

The interpreter executes the query analyzing what is between simple inverted commas and obtains the value L and, following this action, it finds the expression CRAFT which is not a valid SQL syntax and ends up generating an error:

Incorrect syntax near 'CRAFT'.
 Server: Msg 105, Level 15, State 1, Line 1
 Unclosed quotation mark before the character string '

This error message indicated that the application has produced  an unexpected behavior, i.e., the general structure of the query request toward the database (which previously yielded correct results) was changed in an arbitrary way and could not be successfully completed.

If the hacker could perform structural modifications to the query request toward the database to allow reprogramming of its initial functionalities, the application will become vulnerable to SQL injection. An example would be to modify research to list list all available books through the following term:

CRAFT' OR 1=1--

Therefore, this request would be performed in the following way, within the database:

SELECT autor, titulo, ano FROM livros WHERE editor = ‘CRAFT’ OR 1=1--’ and publicado =1

The CRAFT’ OR 1=1– condition makes that the WHERE clause be always evaluated as true and ignores the rest of the query. This query allows invader to ignore the requirement that query returns only items that are property of the authenticated user; the database checks each line on table and extracts each record where the publish column bears “CRAFT” value or where 1 is equal to 1, thus making that the query now returns to the application all the inputs stored in the table, independent of their proprietor.

The use of meta-characters that are interpreted as comments (as in the case of sequence “–“) is often employed in the SQL injection attacks as it allows you to ignore the rest of the query created by the application developer.

An alternate form would be the utilization of inverted commas without using the comment symbol and finish injection by inserting the research term:

CRAFT' OR 'a' = 'a

The result obtained would be:

SELECT autor, titulo, ano FROM livros WHERE editor = ‘CRAFT’ OR 'a'='a and publicado=1

This is perfectly valid and reaches same result of attack 1 = 1 that returns all books written by the CRAFT.

Making attacks more sophisticated.

In order to collect information the hacker can extract the database version, what can be done in any DBMS. It is possible to extract the database version by injecting the following query into the MS-SQL and MySQL:

‘ UNION SELECT @@version,NULL,NULL–

What are the impact and main consequences of attacks?

The above examples show how a hacker can bypass the application logic and access all the database records. For this reason, it must be considered as a high severity attack. The impact caused by a well succeeded SQL injection attack can generate serious problems such as:

• Exposure of database sensitive records;
• Exposure of company’s database to competitors;
• Modification of database (Insert/Update/Delete)
• Obtaining arbitrary access to the operation system;
• Obtaining arbitrary use of network.

In a practical way, the main consequences observed in the most recent SQL injection attacks are related to company’s reputation face to the exposure by the media of the non-authorized accesses to internal data and of the value of the affected, stolen, modified or erased data.

Correction of vulnerable codes

A traditional approach to injection attack prevention is to deal with them as an entry validation problem and accept only characters (whitelist) of safe values or identify and escape (blacklist) from potentially malicious values.

Always opt  for parametrized SQL instructions as they require less maintenance and can offer more guarantees in what refers to security and counter-measures such as privilege limitations for the database server and so on. Other points to be verified are:

• Inspect all entry points in order not to allow use of meta-characters:
• In case use of meta-characters is made necessary, use the mechanism to protect them in a correct way. There are various functions that perform the procedure to escape characters as to avoid they are  interpreted in an inadequate way by the web application.
• Make use, whenever possible, of specific database functions such as stored procedures, which, despite being also vulnerable to SQL injection attacks, they also carry the condition to avoid exaggerated exposure of the application logic and to limit types of parameters received from user.

Stored procedures can prevent some types of SQL injection, however, this is not a definitive solution for such problem. For example, the following excerpt from a stored procedure is vulnerable to an inject SQL attack:

procedure get_item (
 itm_cv IN OUT ItmCurTyp,
 usr in varchar2,
 itm in varchar2)
 is
 open itm_cv for ' SELECT * FROM items WHERE ' ||
 'owner = '''|| usr ||
 ' AND itemname = ''' || itm || '''';
 end get_item;

Generally, SQL injection problems can be detected in a more efficient way by an IT security professional, however, this activity can be automated by means of tools that might perform the source-code analysis (whitebox) and those that can analyze the interface during execution time (blackbox), like N-Stalker.

How N-Stalker can help you!

The N-Stalker Web Application Security Scanner 2012 can help your organization find SQL injection issues in an automatic way. N-Stalker Free Edition’s standard installation brings a big set of predefined policies which already detects this vulnerability.

Download free edition of N-Stalker 2012.

Educational References

• SQL injection explained

 

• WordPress under SQL injection attack