SQL injections represent a code injection technique used to attack applications and the data they hold. They usually occur when user input is required, for example, username, but the user gives an SQL statement instead.
SQL injections exploit vulnerabilities in the application layer. One example is when a user’s input is either incorrectly filtered, or the user’s input is not strongly typed and unexpectedly executed.
SQL injections are mostly known as a website attack vector, but they can be used to attack any SQL database. To make an SQL injection attack, an attacker must first find vulnerable user inputs within the web page or application. When the attacker creates input content and sends it, malicious SQL commands are executed in the database. This way an attacker can gain complete control over the affected database.
SQL injections have been around for quite some time and most of them are automated. Seventeen years ago, the SQL Slammer computer worm caused a denial of service (DoS) on targeted Internet hosts. The attack tragically slowed down traffic on the entire internet. It spread rapidly, infecting most of its 75,000 victims within ten minutes.
Despite widespread awareness of SQL injections and the damage they can cause, not much has changed. These days most web applications remain vulnerable.
Types of SQL injection attacks
User input triggered SQL Injections are the purest form of an SQL Injection attack. Applications typically accept user inputs through front-end forms and then pass the data to a database for processing. If the application fails to sanitize user inputs, an attacker can inject SQL strings into a database and delete, copy, or modify the content of the database.
Cookies store client state information locally. An attacker, or malware, can modify cookies to inject SQL strings into the database.
HTTP headers and other server variables are also at risk of SQL injection attacks. Forged headers containing arbitrary SQL strings can inject code into the database if the application fails to sanitize inputs.
Second-order SQL injection attacks pose a higher risk as they are designed to remain dormant for a period and not run immediately. Even if the inputs are secure from an immediate attack, they can be vulnerable to second-order SQL Injection (SQLi).
To break it down, we have the following three types of SQL injection attacks:
Union-based SQL Injection
Union-based SQL Injection represents the most popular type of SQL injection and uses the UNION statement. The UNION statement represents the combination of two select statements to retrieve data from the database.
Error-Based SQL Injection
An error-based SQL injection is the purest form, but this method can only be run against MS-SQL Servers. In this attack, the malicious user causes an application to show an error. Usually, you ask the database a question and it returns an error message which also contains the data they asked for.
Blind SQL Injection
In this attack, no error messages are received from the database; We extract the data by submitting queries to the database. Blind SQL injections can be divided into 2 types:
- Boolean-based SQL Injection
- Time-based SQL Injection
How to test for SQL injection vulnerabilities?
Before we get into detection, let’s first understand when the application layer communicates with a DB Server to access data. Typical cases when an application needs to talk to a DB are:
- Authentication forms
- Search engines
- E-Commerce sites
We need to make a list of all input fields which contain values that could be used to generate an SQL query and test them separately, trying to interfere with the query and to produce an error.
The first test usually consists of adding a single quote (‘) or a semicolon (;) to the field or parameter being tested. A single quote is used as a string terminator in SQL and, if not filtered by the application, can lead to an incorrect query. A semicolon is used to end an SQL statement and, if it is not filtered, it is also likely to cause an error.
Standard SQL Injection Testing
A query is generally used to authenticate a user, usually, it will be structured similar to:
The values are generally obtained from users using a web form. A malicious user can insert SQL statements that are always true. If the site or application is vulnerable, the system will authenticate the user without knowing the username and password.
In some cases, the first row of a user table would be an administrator user, and this may be the profile returned.
Fingerprinting the Database
Every DBMS has unique characteristics and varies from other DBMSs in many aspects. This includes special commands, data retrieval functions, etc.
When the testers shift to a more advanced SQL injection exploitation, they need to know what the back-end database is.
The first approach to finding out what back-end database is used is by perceiving the error returned by the application. If there is no error message, or there is a message, but it is a custom error message, the validator can try to inject fields into the string utilizing different concatenation techniques.
By utilizing automated application security testing, organizations can stay a step ahead of attackers looking for an easy payday. Testing your application with tools like NexDAST is easy and cost-effective. Sanitize your inputs, and test to verify your mitigations are successful.
SQL Injections pose a severe risk. How can you protect yourself?
Programming languages communicate with SQL databases using database drivers. Drivers allow an application to construct and run SQL statements against a database. Parameterized statements insure that parameters passed into SQL statements are treated safely.
A safe way of running an SQL query in JDBC using a parameterized statement would be:
In contrast, an explicit construction of the SQL string is dangerous:
The difference is the way data is passed to the executeQuery(…). In the first instance, the parameterized string and the parameters are passed to the database separately. That allows the driver to interpret the parameters correctly. In the second example, the complete SQL statement is constructed before the driver is invoked, meaning we are vulnerable to maliciously crafted parameters.
Input validation and parameterized queries, including prepared statements, are the only sure way to prevent SQL Injection attacks. All inputs have to be sanitized, not only web form inputs such as login forms. It’s good practice to turn off the visibility of database errors on production sites. Database errors can be leveraged with SQL Injections to gain information about your database.
NeuraLegion’s NexDAST is a dynamic application security testing tool capable to detect a variety of vulnerabilities, including SQL Injection vulnerabilities. By utilizing artificial intelligence, NexDAST, unlike other dynamic application security testing tools on the market, does not report false positives.
All created reports are ISO and PCI compliant. They offer the right information regardless of your job title, be it an executive or developer roll. With the power of AI, our DAST tool does not only test and detect known vulnerabilities, but crafts new attack vectors in order to find unknown, Zero-day vulnerabilities. With built-in natural language processing algorithms, at the same time, NexDAST tests for business logic flaws.
Want to know more about how our DAST tool can help you stay secure from SQLi? Feel free to contact us.