SQL Injection Threats and Mitigation

Though it has been more than fifteen years since SQL injection attacks were discovered, these are still one of the common database security threats to any organization. SQL or Structured Query Language, is a command-and-control language for relational databases, for example, MySQL, Oracle etc. Content management systems written in ASP.NET, PHP etc., often used these databases as a backend. What it means is that the behaviour as well as content of a large number of websites is built in a database server based on this data.

A hacker can capture sensitive information such as account credentials, modify website content by doing an SQL injection. So, it is essential to have measures in place to avoid any such SQL injection attacks which can put any organization vulnerable to data theft, modification and deletion. One of the best ways to avoid these SQL injections is to run our own SQL injections on the system so as to know beforehand the weak links and possible measures which need to be taken to secure the system. A lot of automated tools are available to perform these tasks, such as Havij. It is a tool that first of all identifies the type of database which is in use, and then uses that knowledge to build queries in conjunction with the characteristics of the database. If a SQL injection is successful by using Havij, it can perform back-end database fingerprint, retrieve DBMS users and password hashes, dump tables and columns, fetch data from the database, run SQL statements, and even access the file system and execute commands on the operating system.

There are many more tools available as well apart from Havij such as, jSQL, Tyrant SQL, SQLmap etc. It is not required to be an expert to be able to identify a SQL injection threat. These automated tools can identify any loopholes and threats to you.

One of the other ways to prevent SQL injection is not to construct SQL queries using any user input, because some special characters inputted by the user may change the whole way the query is interpreted in the backend and eventually churn out the entire data. The queries must be made beforehand as stored procedures, and prepared statements.

An organization can also use software based firewalls to filter out any malicious data. If the firewall is good enough, it will have a comprehensive set of default rules, which can be useful even before a security patch is available. ModSecurity is one such firewall, which is open source and is available for nginx web servers, Microsoft IIS, Apache servers. It provides a set of rules which keep on evolving with time to detect SQL injections, cross site scripting, insecure direct object references and cross site forgery from web attacks. It employs an HTTP and HTML parser to analyse the input stream, which can understand specific features of a protocol such as, content encoding, response and request compression and XML payload as well. Depending upon the information retrieved from the parser, ModSecurity breaks up the HTTP stream into logical entities such as headers, parameters and uploaded files etc. All these elements are inspected independently to get its length and count apart from its content. Some common techniques used for evasion are to use different character encoding or use non canonized path names. To prevent such evasions, ModSecurity transforms the request to a normalized form before inspection. It can also employ normalization functions for different input fields for each inspection performed.

Apart from these, there are always methods and steps which can be taken from our side to prevent any such attacks. First and foremost, an organization must always continuously update and patch its system as soon as possible in the limits of practicality. In today’s world vulnerabilities that hackers can exploit using SQL injections in applications and databases are regularly discovered. This approach though may be costly in the beginning may be worth the money spent if the data stored by the organization is highly critical.

Furthermore, from an organization stand point, it should always be the objective to remove all the unneeded database functionalities which an organization may forget to keep track of but is still there. A hacker can take advantage of such situations. One of the classic example of this situation is xp_cmdshell in Microsoft Windows. The xp_cmdshell extended stored procedure in MS SQL spawns a Windows command shell and passes in a string for execution, which can be very easily used by a hacker to manipulate, extract, and/or alter the system (Anley, C., 2002). Extended stored procedures are in nature compiler Dynamic Link Libraries (DLLs) which use a SQL server specific calling convention to run exported functions which allow SQL server applications to have access to the full power of C/C++.  It is a built-in extended stored procedure that allows the execution of arbitrary command lines. 

Often times, if the database is being accesses using an account with admin privileges, a hacker may be able to get into the database by constantly tracking the user activity of the admin account. Hence, it is advisable to not connect with the database using an account which has admin-level privileges. It should be done when it is completely necessary to do so. By following this practise in general, the entire database cannot be compromised in case there is a hack into the database.

A general practise of an organization should also be to monitor all the SQL statements being made from the database-connected applications. To do so and to automate the entire process, monitoring tools which use machine learning or behaviour analysis can be of pretty much use. The continuous monitoring of these database-connected applications, will make it easy to identify any suspicious SQL statements being executed and any other vulnerabilities as well.

Furthermore, it is also an ideal practise to customize the user input. For example, if a text field is supposed to be used for filling email addresses then only certain special characters should be allowed. If a text field is meant to be used to input phone number then only digits should be allowed in that text field.

In conclusion, SQL injections though very trivial and obvious in nature, still need so many layers of security and protection. The above mentioned methods and steps may be good enough for an organization at present, but continuous evolving nature of the SQL injection hacking loopholes, a continuous effort is required from the organization itself to ensure that any such vulnerability is dealt with proper measures.