SQL Injection attack and database security

SQL Injection attack and database security

The cyberpunk world of ours is getting more real since the cyberattacks are increasing as rapidly as the enormous data is being generated these days. At such time, a software that has the database having expensive data at its core can often have vulnerabilities, less assured components or configurations, and thus can invite malicious attacks. These vulnerabilities in software can often be exploited by cybercriminals and can lead to data breaches and the illegitimate use of the database can be a potential threat to the organization. 
These attacks targeting the database on the servers can often be a DDoS attack, Buffer Overflow attack, or even malware. In the case of DDoS (Distributed Denial of Service), the cybercriminals flood the database server using a load of fake requests and thus increase the query traffic making the service unavailable. In the case of  Buffer Overflow attack, the buffers in memory that temporarily manage the data while being transferred, get overflown when enormous data exceeds the capacity of it and thus the data to be written in buffer overwrites adjacent memory locations. So the cybercriminals may overwrite the executable code of the application and penetrate into databases.

But above all these and other attacks the most vulnerable attack is SQL injection attack, which is one of the most prominent attacks. It is observed that about 32% of attacks are SQL injection attacks.

Tesla faced an SQL injection attack in 2014 where breachers could gain administrative privileges and steal user data. Fortnite, the very popular online game, also discovered a SQL injection vulnerability which could let attackers access user accounts. The Turkish government faced a SQL injection attack in which the attackers breached into the government website and erased debt to government agencies. Popular retail chain 7-Eleven also faced a SQL attack in which the attackers stole over 130 million credit card numbers

Image credits : https://www.avast.com/c-sql-injection

So let’s get to know more about SQL injection!

Note that the content and examples of this blog are meant for learning purposes only, and do not lead in any way to promote cybercrime.

A method of attack that has been at the forefront of the top 10 security risks for web applications for several years: SQL injection. SQL injection is basically that an attacker enters a few lines of code instead of an actual username and password. This when checked against the database, returns true, giving the attacker login access. Wondering how such a simple method of attack could make it to the top of the list of security vulnerabilities? Don’t worry you’re not alone, many developers are thinking of the same thing. One of the reasons why SQL injections are so popular with hackers is the fact that this vulnerability is so easy and quick to exploit. This is due to the strict time constraints during the development stages of applications, where functionality is prioritized and security precautions come last. 

As the term “injections” implies, they are manipulated SQL queries. Therefore, we have to take a closer look at the attack vectors. Common examples of SQL queries on websites include:

• Authentication (login window)

• Search boxes (retrieving relevant information from the database)

• URL (modifying the hyperlink)

The login window provides two boxes in which the user information is to be entered. The information provided is transmitted to the server, and the database is scanned for a matching user.

Figure 1: Login mask for user query

If no matching user is found, the login fails. At the source code level, the string of “Username” and “Password” is used to build an SQL query, which is in turn used to access the database. The code would look something like this:

 var User = getName("Tester");

 var Password = getPass("Passwort1");

 sql_cmd = 'SELECT * FROM Users WHERE Name ="' + User + '" AND Password ="' + + '"'

Resulting SQL query:

→  SELECT * FROM Users WHERE Name = “Tester” AND Password = “Passwort1”

In this example, the user input is accepted without verification and used to build the query. The system trusts the user input. If the user is a hacker who recognizes this vulnerability, they could exploit it as follows.

Figure 2: Login without verification

Special characters and commands are entered in the login fields to complement the SQL query. With the entries shown above, the resulting query would look as follows:

Resulting SQL query:

 →  SELECT * FROM Users WHERE Name =”” or “”=“” AND Password =”” or “”=””‘

The additional OR in the query, which in this case always returns TRUE, results in every entry from the table being displayed. If the login system only checks whether a user with the respective password exists in the database, this query will always produce a positive result. Consequently, this entry would be a universal key for all attackers in an unprotected system.

This is one example of how an SQL injection in login fields can be done. The injection can also be done via the URL of a web page. The URL consists of the address of the web page and a path representing the directory of the server. This file path also includes PHP or HTML parameters reflecting the user’s query.

Examples of URLs:

http://testmysql.com/report.php?id=23

http://www.testmysql.com/search.html?query=test&searchProfile=tester

These parameters in the URL paths can be used for injections. Similar to the first example, the string can be replaced to manipulate an SQL query to serve the attacker’s purposes.

Changed URL: http://testmysql.com/report.php?id=105; DROP TABLE items; —

Resulting query:   →  SELECT * FROM items WHERE id = 105; DROP TABLE items; —

By adding DROP TABLES, another SQL command is added to the query and executed when the connection to the database is established. First, the desired standard query is executed. The database is searched for the ID 105, but immediately afterwards, the entire table and all the data it contains is deleted.

These two examples illustrate how critical injections can be for a database. Of course, you should note that the injections shown above are very simple examples. Such injections cannot be directly called up on any page. In practice, potential attackers have to work harder. Although it is possible to find web pages with such a URL path on Google, e.g.:

inurl:”product.php?id=” site:.de

In most cases, they are secured. Furthermore, the attacker must first get an overview of the system. 

Comparing different database management systems

The databases that support multiple SQL statements in a single request like Microsoft SQL Server and PostgreSQL are at more risk to SQL injection since dynamic SQL statements can be exploited by attaching another statement. An attacker can inject INSERT statements to add new users to the application or to gain certain high-level access privileges.

Oracle and IBM DB2 databases are less exposed and better against SQL injection attacks since there is no multiple SQL statement support, and no INTO OUTFILE function (MySQL). The  SELECT INTO OUTFILE writes the query result rows to a file by using column and row terminators for formatting. This can be vulnerable as most of the time the data is written into this file and this file is stored in the application’s directory which essentially means that the file can be accessed through the browser like eg. “https://mysite.com/outfile.php”.

Ways to prevent SQL injection attacks

Formatting the data

One of the ways of prevention can be proper formatting of data and escaping all the strings or data, the database server will easily distinguish between the input data and the SQL queries, thus avoiding the query injection in it.

Prepared Statements 

Another option to this would be using prepared statements. In our application, most of the time we deal with queries with dynamic data, that is where we substitute the variables on the fly. So there comes a risk of data manipulating the program. For example

 $account_id = 1011; 

$query = "SELECT * FROM accounts where id=$account_id";

Results into below query and is then executed

SELECT * FROM accounts where id=1011

whereas the below code

$injected_id = "1; DROP TABLE accounts;"

 $query = "SELECT * FROM accounts where id=$injected_id";

will be malicious and be executed as

SELECT * FROM users where id=1; DROP TABLE users;

The idea behind using prepared statements is that we don't alter our query, it remains unbroken since the query is sent to the server without embedding data, as if it's a statement template. The dynamic data will be sent with another request and is validated and then used directly at the point of execution after the template is parsed. So this avoids the data to interfere with the statements, preventing the attack.

$db->prepare("SELECT * FROM accounts where id=?");

$db->execute($data); 

Prepared statements are found to be a more convenient and less error-prone approach than formatting.

Patching

Image credits: https://threatpost.com/oracle-releases-biggest-update-ever-308-vulnerabilities-patched/126910/

Database patches targeted at finding vulnerabilities and hotfixing should be conducted often. This is a crucial security practice because attackers are actively seeking out new security flaws in databases, and new viruses and malware appear on a daily basis.

Firewalls

Image credits : https://www.ukfast.co.uk/blog/2019/10/03/web-application-firewall-what-why/

Safeguard the database with a firewall, which won’t permit access to network traffic. Both database and web application firewalls should be used, SQL injection is aimed at surpassing web application security first to gain illegitimate access to your databases. Also, the database firewall only operates at the network layer, whereas WAF operating at the application layer is well able to detect malicious web application traffic.

Every database is structured differently and has different names for the tables, e.g. for the user information. Systems can be actively protected by using standard frameworks. They are tried and tested and continually developed. If such a framework is further customized to fit a system, attacking it becomes even more difficult. The attacker has to make several attempts to find out how queries are verified and which input formats are used. Sometimes, the error messages displayed due to these attempted injections will sometimes give the attacker the information they need for their attack. This is why it is important to check the content of the error messages that a user sees. In the worst case, the error message reveals which database table and which columns contain certain data. With this information, it is very simple to build a corresponding injection. Another important safety measure is using a user with limited rights to access the database. This way, you can prevent commands, e.g. to delete or modify data in the tables. In addition, you should use “stored procedures” to further limit the possibilities to access the database.

Within the framework of a comprehensive quality assurance process, dangerous vulnerabilities can be identified by means of tests and can be eliminated.

There are several tools for testing such security vulnerabilities; they exploit common vulnerabilities to test the systems for weak points. These tools are continually developed and can be used not only by developers but also by testers. Examples of such tools:

BSQL Hacker, SQLmap, SQLNinja, Safe3 SQL Injector, and many more.

Hope you got to explore SQL injection and learn about how you can transform your database and application in a way that it will be less viable to such attacks in the future.

Authors: Rewa Wader | Vedant Dambhare | Aditya Warghane | Siddhesh Wani

Resources:

https://www.exploit-db.com/papers/14635

https://www.imperva.com/learn/data-security/database-security/

https://www.neuralegion.com/blog/sql-injection-attack/

https://www.php.net/manual/en/mysqli.quickstart.prepared-statements.php

https://www.php.net/manual/en/mysqli.real-query.php