Most security professionals know what SQL injection attacks are and how to protect their Web applications against them. But, they may not know that their preventative measures may be leaving their applications open to blind SQL injection attacks. SQL attackers are getting savvier, and understanding how their attacks work is key to keeping your organization's Web applications secure. Let's review both types of SQL injection attacks and how they occur, and look at what organizations can do to prevent them.
Plain SQL injection attacks
Web applications commonly use SQL queries with client-supplied input in the WHERE clause to retrieve data from a database. When a Web application generates such queries without checking or preprocessing the user-supplied data to ensure it's valid, a SQL injection attack can occur. By sending unanticipated input, an attacker can create and submit SQL queries to pass commands directly to a database. Hackers typically test for SQL injection vulnerabilities by sending the application inappropriate input to try to generate an invalid SQL query. If the server returns an error message, the attacker can use information from the error message to try to gain illegal access to the database. This is a SQL injection attack.
Blind SQL injection attacks
Many system administrators respond to SQL injection attacks by suppressing the display of database server error messages. However, that doesn't tackle the core problem, which is poor coding. Hiding error messages is really just "security by obscurity," though it does challenge the attacker who now has to build an understanding of the application, the database and the structure of the tables, etc., through the injection process itself. This 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.
Preventative measures
As you can see, even if your Web application does not return error messages, it may still be susceptible to blind SQL injection attacks. However, you can protect your organization's applications against both attacks with the following best practices:
1. Create a policy that enforces secure coding practices to ensure vulnerability detection and assessments are performed during any application development or deployment.
2. Have your developers identify where data enters or exits the application and ensure that validation occurs for every part of the HTTP request before letting it anywhere near scripts, data access routines and SQL queries. This will prevent user-supplied data from being able to modify the syntax of SQL statements.
3. Completely isolate your Web applications from SQL using stored procedures, which the application should execute using a safe interface, such as JDBC's CallableStatement or ADO's Command Object. If SQL statements must be generated on the fly, use PreparedStatements, as both PreparedStatements and stored procedures compile the SQL statement before the user input is added, making it impossible for user input to modify the actual SQL statement.
4. Consider using a vulnerability assessment tool to automate the discovery of SQL injection and other security vulnerabilities.
5. Develop an incident response plan. Having a detailed and well-rehearsed plan will help you handle any attack that occurs in an orderly and effective manner, and minimize the impact to your organization.
------------------------------------
About the author: Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications.
This article originally appeared on SearchSecurity.com.
