In this article, we will learn what a SQL Injection is, how to use it, and how to protect ourselves from it.
Technology is vital in modernity; not only do individuals rely upon the digital world for leisure, but many more use it for the professional arena. Our technological footprints, small as they may be, are meticulously recorded at all times and by various sources. All the recorded information and more are translated into relative databases. These databases can then use the data in various ways, like linking accounts across devices.
In today’s technologically booming world, applications and their data sources are under more threat than ever. Data-driven applications are among the most common targets for web-based cybersecurity attacks, especially those with SQL Injection vulnerabilities.
SQL refers to “Structured Query Language,” a code format that allows an application to interact with its database. SQL injections, also termed SQLi, are malicious SQL statements that let the user manipulate an infected target. Most commonly, targeted websites suffer cyberattacks that exploit the web application’s access to a database server. SQLi is explicitly created to access databases, but the desired outcome is variable.
Some SQL injection attackers want sensitive company data, user information, and consumer details; others may want to delete, edit, recover, change, or copy database information. Some injections release viruses, while others may export lucrative details to remote or independent servers. Ultimately, only the attacker knows their exact goals.
Every data-driven application that uses dynamic SQL statements to interact with a database has a SQL vulnerability. The fault lies with the application code rather than the database itself; subsequently, developers must consider how to interact with their databases while reinforcing their security. Regarding SQLi, the most susceptible code area is at the back-end of website and database communications.
SQL queries are submission requests to the target website, database, or server. When a query is written as a URL, websites may respond with an HTML code; however, the website may hide the response within the application aspects. Subsequently, when checking for SQL injection vulnerabilities, open the source window to monitor otherwise invisible outcomes.
Additionally, some SQL queries can damage the application when misused, mainly when applications use the same data in multiple instances across their code. If, during the SQL query, the conditionals reach the copied data and then run into an UPDATE or DELETE statement, the attacker may destroy information. The best way to avoid malicious parties destroying data is by preparing many SQL injection defenses.
Depending on the internal structure of the database, attackers have many options to garner information. The goal of these inferential or blind SQL assaults is not to produce a specific set of data. Instead, these queries inform the attacker about the structure of the database. After this, they can use the details to navigate and manipulate sensitive data. The most common blind SQL assaults include:
● Boolean SQL: the assailant sends an SQL query to the database requesting a specific result. Depending on the reaction of the database, the attacker can determine if the query generated a “true” or “false” response. For example, web assaults may take the form of a URL; based on the SQL query results, the HTTP may or may not respond. Attackers may assume a “false” query if it does not respond.
● Time SQL: the attacker transmits an SQL query through to the database. The query asks it to wait a specific amount of time before completing a task like going to sleep. The response time informs the assailant, who can then use the details to determine if the queries are “true” or “false.”
● Error SQL: the agent uses specific actions to cause the database to generate error messages. The attacker then uses this error information to refine the details or target. Sometimes, attackers can use the error information to find critical aspects of the database infrastructure or sensitive data.
● Union SQL: the actor uses a UNION operator to combine the results of two or more select statements into one HTTP response. Attackers can write queries into the URL of a website or enter into the input fields within an application. This injection usually succeeds when a vulnerable SELECT statement targets result sets.
Regarding their end goals, SQLi attackers use one of two injection types. The blind SQLi above helps to inform the attacker and hunt down their ultimate target. The attacker may use an in-band SQLi to both launch and receive the spoils of their assault. These are the most straightforward attacks, which display data when a query is made. In comparison, the less used option is out-of-bound SQLi; this happens when the attacker launches a query and receives the results in another format or on another server.
One of the reasons SQL injections are dangerous is because of their accessibility. Users with limited experience can input a query and easily access a range of information. Examples of SQL queries may include value manipulation, delimiters, and function wildcards.
www.techpanda.org is a well-known SQLi vulnerability web application that is publicly available. Its home page is a login where users can test SQLi techniques.
For the email address enter: [email protected]
And for the password enter: xxx’) OR 1 = 1 —]
The following SQL statement is generated with these submissions (also known as an SQL injection):
SELECT * FROM users WHERE email = ‘[email protected]’ AND password = md5(‘xxx’) OR 1 = 1 —]’);
Let’s break down what’s happening:
SELECT * FROM users: This part of the query selects all rows from the “users” table.
WHERE email = '[email protected]' AND password = md5('xxx'): This part of the query specifies conditions that must be met for a row to be selected. It checks if the “email” column is equal to ‘[email protected]‘ and if the “password” column is equal to the MD5 hash of ‘xxx’. This is an attempt to authenticate a user with a specific email and password.
OR 1 = 1: This is where the SQL injection occurs. The attacker has inserted a condition that always evaluates to true (‘1 = 1’). This effectively bypasses the previous email and password check because the entire WHERE clause now evaluates to true.
—]’);: The double hyphen (–), followed by the closing single quote (‘), and a semicolon (;) are used to comment out the rest of the original query. This is a common technique in SQL injection to prevent any errors that might occur due to the injected code.
The most successful SQL injection results use many variations of attacks to find their goal. OWASP comprehensively reviews some of the best SQLi testing and penetration strategies available.
How to Prevent SQL Injections?
Data-driven applications are vulnerable to SQL injection attacks from the internet. Assailants can launch attacks via software, servers, or the input fields of the application itself; this means attackers don’t need unique technology to discover sensitive details. They can find their way into the database by entering the login page. Thankfully, there are proven ways to help prevent and subvert SQLi attacks:
● Minimize error messages: provide limited or no information about the error or why it happened. Attackers can use the details to reverse engineer access.
● Sanitize user input: add a filter between input fields and application requests. Dynamic SQL statements are particularly vulnerable to these attacks.
● Utilize prepared statements: create the SQL statement first, then identify all the parameters as user-entered data. Details entered outside these parameters are flagged.
Every data-driven application has SQL vulnerabilities. The relationship between the back-end code of an application and a database will always be a target for cyberattacks. Developers can limit these susceptibilities by creating applications with proactive responses to hacking attempts. Databases also have a role in these proactive measures; their security is critical in preventing and defending against SQL injection attacks.
About the Author:
David Lukić is an information privacy, security and compliance consultant at IDstrong.com. The passion to make cybersecurity accessible and interesting has led David to share all the knowledge he has.