Injection: Facts to Know about SQLi
OWASP Top 10 is the standard awareness document for developers and security analysts which represents the security risks to web apps. A1:2017:Injection is listed at the top of web app security risks.
When the untrusted data is sent to the interpreter in the form of query, command, or parameter, the injection flaws such as SQL/NoSQL injection, command injection, LDAP injection, etc. occurs. Sending such unintended commands and queries, an attacker can maliciously execute the queries and commands by tricking the interpreter without having the intended authorization.
The source of data can be an environment variable, parameters, external and internal web services queries.
Injection vulnerabilities are often found in Structured Query Language (SQL), Lightweight Directory Access Protocol (LDAP), XPath, or NoSQL queries, OS commands, XML parsers, SMTP headers, expression languages, and ORM queries. Injection flaws are easy to discover when examining code, whereas scanners and fuzzers can easily help to find such injection flaws.
The injection flaw can lead to data loss, corruption, or breach, loss of accountability, or denial of access and up to complete host takeover whereas the business impact of injection flaws depends upon the application and data.
SQL injection, also known as SQLi is the type of web app injection flaw which allows the attacker to inject the malicious queries along with the parameter or query data and make queries directly to the database. The impact of SQL injection has to lead many data breaches in recent days leading the organization to pay hefty lawsuits and reputational damage. The impact is not limited to these, but can also lead an attacker to persist a backdoor into the system compromising the system unnoticed. SQL injection can be basically divided into three types:
This is the most common, classic and easy-to-exploit of SQLi attacks. This type of injection occurs when an attacker can use the same channel for both launching attack and gathering the obtained result. The in-band SQLi can be divided into two types, error-based and union-based SQLi.
Error-based SQLi: error-based SQLi is a type of in-band SQL Injection that relies on error messages thrown by the database server to obtain information about the structure of the database. In some cases, error-based SQL injection alone is enough for an attacker to enumerate an entire database. While errors are very useful during the development phase of a web application, they should be disabled on a live site or logged to a file with restricted access instead.
Union-based SQLi: Union-based SQLi is a type of in-band SQL Injection that leverages the UNION SQL operator to combine the results of two or more SELECT statements into a single result which is then returned as part of the HTTP response.
This is a type of SQL Injection in which the attack may take longer for an attacker to exploit. But, this attack is also most severe as any other type of SQL Injection. In this type of attack, no data is actually transferred via the web application and the attacker won’t be able to see the result of an attack. Hence, these types of attacks are commonly referred to as blind SQLi attacks. For this type of attack to occur an attacker becomes able to reconstruct the database structure by sending payloads, observing the behaviour of the web app’s response and the database server. The inferential SQLi can be divided into two types, Blind-boolean-based and Blind-time-based SQLi.
Blind-boolean-based SQLi: This is the type of inferential SQLi in which the attacker sends SQL queries to the database. Then the query forces the application to return a different result depending on whether the query response returns either a true or false value. Depending on the result, either the content of the HTTP response changes or remains the same which allows an attacker to know if the result is true or false and hence identify to be vulnerable, despite no data has been obtained from the database.
Blind-time-based SQLi: This is the type of inferential SQLi in which the attacker sends SQL queries to the database. Then, the provided query forces the database to wait for a specified amount of time before responding to the application. The response time from the app indicates to the attacker whether the result of the provided query is either true or false which allows the attacker to know if the result is true or false and hence identify to be vulnerable, despite no data has been obtained from the database.
This is a type of SQL Injection in which the attack is not very common and depends on the features of the DB server utilized by the web app. This type of SQLi occurs when an attacker cannot utilize the same channel for launching the attack and gathering the results. This kind of SQLi depends and relies on the DNS and HTTP requests to deliver the required data to an attacker. As an example of out-of-band SQLi, Microsoft SQL Server’s xp_dirtree command can be used to send the DNS requests to the server which is basically controlled by the attacker. This type of SQLi acts as the alternative to inferential time-based-SQLi as the response from the server becomes unstable.
The risk of SQLi usually remains high to critical depending upon the exploitation scenario. The impact ranges from stealing sensitive information like user credentials, transaction records stored in databases to the massive data breach, deletion of entire tables and also gaining the administrative rights to a database.
The risks of SQL injection in a web app is not the only risk to confidentiality, and integrity of data but the authentication and authorization aspects of the application. An attacker can steal sensitive information like user credentials, trade secrets, or transaction records stored in databases. Also, if the authentication/authorization is also affected by the vulnerabilities, an attacker can impersonate other users as well by maliciously logging in to their account, or as an administrator elevating the privileges.
If SQL injection is found in the application, it should not be ignored by any means and must be fixed as soon as possible.
SQLi flaws in web apps have been around for a long time and are many ways to patch these kinds of flaws. Basically, any type of data that comes from another source like user input, parameters shall not be trusted and regard as to be malicious. So, the simple solution can be the input validation to solve this issue which can be done by following the below-listed points.
Client and server-side input validation based on the blacklisted keyword
Using only the prepared SQL statements along with parameterized queries
PHP data object for a parameterized query
Escape the third-party data like user inputs
Adopt secure coding practices
Using the Web Application Firewall (WAF) to filter the threat