Behind your web application lies databases that contain usernames, passwords, and critical client data. These databases should be very robustly protected, and security measures should be implemented to do so.

If the correct inputs are not sanitized, your databases can become compromised. SQL Injection attacks are based on malicious inputs that work to extract relevant data and information from your web application databases. It is important to note that the SQL injection is not limited to enter through input forms or URLs, it can be injected through cookies and HTTP headers as well if the web application uses these as data which further is treated into its databases. Login forms, with usernames and passwords, can be susceptible to this attack if the form accepting the login inputs are not properly sanitized. Let us look at a simple example:

Username Password

Considering this above login form is susceptible to an SQL injection, simply by intercepting the request and appending it with a malicious SQL injection the attacker can get authenticated as admin since ‘1’=’1’ for SQL will always return ‘True’:

Get /login?username=’admin’&password=”+or+’1’=’1’ HTTP/1.1

Another example we can look at is malicious queries using ‘UNION’. To make a use of ‘UNION’, an attacker must know the number of columns as the statement constructed needs to have same number of columns. To know the number of columns an attacker can perform hit and try with NULL and observe the behavior of the web application. For example, once the attacker has the number of NULL as the number of columns the server responds with some data instead of predefined errors such as “internal error”.

The following can return list of usernames and passwords from the table ‘user’:

GET /find?info=tag+UNION+SELECT+username,+password+FROM+users-- HTTP/1.1

SQL injection is not only limited to just retrieving data, if done properly an attacker can do more damage than that by manipulating, deleting, or replacing the data. The statements can be used with SQL injections are SELECT, INSERT, UPDATE, DELETE.

For example, once an attacker retrieves the list of usernames from the previous example of SQL injection, the same request can be utilized to delete a user, even admin:

GET /find?info=tag+UNION+DELETE+ FROM+users+WHERE+user=’admin’-- HTTP/1.1

Furthermore, SQL injections are not just limited to SQL databases, but can also be used to perform system command executions. Here is an example of injecting a PHP script onto the web application and then an attacker can visit this injected script to run system commands:

GET /find?info=tag+UNION+SELECT+123,+‘<?php+system($_GET["command"]);+?>'+into+outfile '/var/www/command.php'—

If the malicious file is well put in place, an attacker can then access the file and pass system commands as parameters which the malicious script is expecting https://domain/command.php?command=date

The first line of defense to prevent such attacks is have your web developer write, or re-write, the application code that will take inputs and sanitize them before passing them on to obtain information from the databases. Another method, which can be combined with this, is to place your web application behind a web application firewall (WAF), that will help sanitize inputs to not allow such attacks to be performed. The web application firewall (WAF) will look at irregular inputs and prevent them from being launched on your databases. However, if the WAF is not properly configured, it can still let custom crafted malicious injections pass. Indeed, evaluating your web application as standalone to see the level of robustness to prevent such injections gives the best peace of mind.