Hardening Your Web Application Against SQL Injections

What is SQL?

Structured Query Language (SQL) is a specialized programming language for sending queries to databases. Most small and industrial- strength database applications can be accessed using SQL statements. SQL is both an ANSI and an ISO standard. However, many database products supporting SQL do so with proprietary extensions to the standard language. Web applications may use the user-supplied input to create custom SQL statements for dynamic web page requests.

What is SQL Injection?

SQL injection is a technique that exploits a security vulnerability occurring in the database layer of a web application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed. It is, in fact, an instance of a more general class of vulnerabilities that can occur whenever one programming or scripting language is embedded inside another.

“SQL Injection” is a subset of the unverified/unsanitized user input vulnerability (“buffer overflows” are a different subset), and the idea is to convince the application to run SQL code that was not intended. If the application is creating SQL strings naively on the fly and then running them, it’s straightforward to create some real surprises.

Many organization’s web servers have been compromised just because of SQL Injections, including big names which I would not like to mention here, you can search it easily on the Internet.

What is Blind SQL Injection?

This particular type of attack is called a blind SQL injection attack because the attacker cannot take advantage of detailed error messages from the server or other sources of information about the application. Getting the SQL syntax right is usually the trickiest part of the blind SQL injection process and may require a lot of trial and error. But, by adding more conditions to the SQL statement and evaluating the Web application’s output, an attacker will eventually determine whether the application is vulnerable to SQL injection.

Blind SQL injection a special case that plays on the web developers or website owners sense of security. While they may think that everything on the server is tightly guarded a Blind SQL injection attack will silently be playing truth or consequences with the web server. This type of attack though very time consuming is one that provides the most potentially damaging security hole. This is because an attacker gets not only access but is provided with an enormous amount of knowledge about the database and can potentially gain access to a server file system. This type of attack is one that is automated and requires a good amount of setup to succeed. But once it is done it does not require a great deal of effort to repeat.

What is Error message SQL Injection?

Web applications commonly use SQL queries with client-supplied input in the WHERE clause to retrieve data from a database. When a Web application executes such queries without validating or scanning the user-supplied data to ensure it’s not harmful, a SQL injection attack can occur. By sending unexpected data, an attacker can generate and submit SQL queries to a web applications database. A test for SQL injection vulnerabilities takes place by sending the application data that generates an invalid SQL query. If the server returns an error message, that information can be used to try to gain uncontrolled access to the database. This is the basis of one of the most popular SQL injection attacks.

Hiding error messages does not stop the SQL injection attack. What typically happens is the attacker will use the knowledge gained from the failure of this attack to change tactics. What they turn to is blind SQL injection.

Why SQL Injection?

When a web application fails to properly sanitize user-supplied input, it is possible for an attacker to alter the construction of backend SQL statements. When an attacker is able to modify a SQL statement, the process will run with the same permissions as the component that executed the command. (E.g. Database server, Web application server, Web server, etc.). The impact of this attack can allow attackers to gain total control of the database or even execute commands on the system.

When a machine has only port 80 opened, your most trusted vulnerability scanner cannot return anything useful, and you know that the admin always patches his server, this is the point where a malicious hacker would turn to web hacking. SQL injection is one of the type of web hacking that requires nothing but port 80 and it might just work even if the admin is patch-happy. It attacks on the web application (like ASP, JSP, PHP, CGI, etc) itself rather than on the web server or services running in the OS.

Types of SQL Injections:

There are four main categories of SQL Injection attacks against databases layer in Web Application

1. SQL Manipulation: manipulation is a process of modifying the SQL statements by using various operations such as UNION. Another way for implementing SQL Injection using SQL Manipulation method is by changing the where clause of the SQL statement to get different results.

2. Code Injection: Code injection is a process of inserting new SQL statements or database commands into the vulnerable SQL statement. One of the code injection attacks is to append a SQL Server EXECUTE command to the vulnerable SQL statement. This type of attack is only possible when multiple SQL statements per database request are supported.

3. Function Call Injection: Function call injection is a process of inserting various database function calls into a vulnerable SQL statement. These function calls could be making operating system calls or manipulate data in the database.

4. Buffer Overflows: Buffer overflow is caused by using function call injection. For most of the commercial and open source databases, patches are available. This type of attack is possible when the server is unpatched

SQL Injection Prevention Techniques:

Mitigation of SQL injection vulnerability would be taking one of the two paths i.e. either using stored procedures along with callable statements or using prepared statements with dynamic SQL commands. Whichever way is adopted the data validation is a must.

a. Input validation

Data sanitization is key. Best way to sanitize data is to use default deny, regular expression. Write specific filters. As far as possible use numbers, numbers, and letters. If there is a need to include punctuation marks of any kind, convert them to HTML encoding them. SO that ” become “or > becomes “>” For instance, if the user is submitting the E-mail address allow only @, -, . And _ in addition to numbers and letters to be used and only after they have been converted to their HTML substitutes

b. Use of prepared statement

The prepared statements should be used when the stored procedures cannot be used for whatever reason and dynamic SQL commands have to be used.

Use a Prepared Statement to send precompiled SQL statements with one or more parameters. Parameter place holders in a prepared statement are represented by the? And are called bind variables. Prepared statement are generally immune to SQL Injection attacks as the database will use the value of the bind variable exclusively and not interpret the contents of the variable in any way. PL/SQL and JDBC allow for prepared statements. Prepared statements should be extensively used for both security and performance reasons.

c. Use minimum privileges

Make sure that application user has specific bare minimum rights on the database server. If the application user on the database uses ROOT/SA/dbadmin/dbo on the database then; it surely needs to be reconsidered if application user really needs such high amount of privileges or can they be reduced. Do not give the application user permission to access system stored procedures allow access to the ones that are user created.

d. Stored procedures

To secure an application against SQL injection, developers must never allow client-supplied data to modify the syntax of SQL statements. In fact, the best protection is to isolate the web application from SQL altogether. All SQL statements required by the application should be in stored procedures and kept on the database server. The application should execute the stored procedures using a safe interface such as Callable statements of JDBC or CommandObject of ADO.

Article Source: http://EzineArticles.com/1301170

By | 2017-11-01T20:58:13+00:00 September 22nd, 2017|Technical Track|0 Comments

About the Author:

Certified Information Systems Security Professional(CISSP); Certified Ethical Hacker (CEH); Certified EC-Council Instructor (CEI); Microsoft Certified Trainer (MCT); and Microsoft Certified Professional (MCP).

Leave A Comment