Saturday, January 23, 2016

Blind SQL Injection Attack



Many web applications use SQL to store and retrieve sensitive data required by the users. It may be user credentials, transaction details or it may be other data useful to the web application.


For example, let's suppose a user wants to search for the availability of a book in a ecommerce website. To do that, he will first enter the author or title of the book in the search bar. At that time, the web application will receive the user input, process it and make appropriate SQL query to the database. It will then process the output returned by the database and display that to the user nicely formatting it.


But, sometimes a web application can have security vulnerabilities and the attackers can exploit those to update, delete or steal sensitive data stored in the database. A Blind SQL Injection Attack, which is a type of SQL Injection Attack, is one such attack widely perpetrated by the attackers.




What is a Blind SQL Injection Attack


Suppose, in a web application ecommerce.com, a user can search for a particular book with the name of the author or title or description of the book. When the user inputs “John” in the search bar, the following URL is loaded :


ecommerce.com/books.php?author=john


This results in execution of the following SQL query to the database :


SELECT * FROM bookinfo WHERE author = 'john';


And, the output is nicely formatted and shown to the user.


But, suppose an attacker loads the URL :


ecommerce.com/books.php?author=john OR 1=1


If the web application embeds the user input to SQL query directly, it would result in the following SQL query in the database :


SELECT * FROM bookinfo WHERE author = 'john' OR 1 = 1;


And, in that case, the web application will list all the books in their database in the webpage shown to the attacker.


Now, the attacker can load the following URL next :


ecommerce.com/books.php?author=john AND 1=2


And, if the web application has Blind SQL Injection vulnerabilities, this will result in execution of the following SQL query :


SELECT * FROM bookinfo WHERE author = 'john' AND 1 = 2;


Clearly, the database will return 'false'. And, if the web application shows generic error messages or shows error messages from the database, it will reveal enough information to the attacker. By executing these two queries, the attacker will be confirm that the web application has Blind SQL Injection vulnerabilities and now he can execute even more queries to extract more information like version of SQL used etc. These type of attacks which test the database with various queries, like true and false queries and extract information so that the attacker can plan for even more attacks, are called Blind SQL Injection attacks.




How is Blind SQL Injection Attack different from SQL Injection Attack



Blind SQL Injection Attack is a particular type of SQL Injection Attacks. Normally, in SQL Injection Attacks, the attacker exploits the security vulnerabilities of the web application to trick it to execute malicious SQL queries, that can update the database, delete sensitive data or reveal sensitive data like username, password or credit card numbers to the attacker. In Blind SQL Injection Attack, the attacker may not directly update or delete the database, but it can make several queries to the database and deduce information from it so that he can now make even more attacks.

Both SQL Injection Attacks and Blind SQL Injection Attacks are difficult to catch, but with some precautions it can be mitigated.





Mitigation


There are couple of precautions we can take to mitigate this attack.


  • User input should not be embedded in the query directly. Instead, parameterized statements that work with parameters should be used.
  • Type constraints of variables should be properly checked before executing the query.
  • For parameterized statements, parameters should be escaped properly. For example, in PHP mysqli_real_escape_string() can be used to escape parameters.
  • Certain characters can even be forbidden to be used in the query.
  • Database permissions should be limited appropriately. Some tables can be restricted to be fetched without appropriate permissions.
  • Bin2hex() and unhex() can be used to convert the parameters to/from hex values. The advantage of this is, the output of unhex() function is returned as a string and not interpreted.


No comments:

Post a Comment