Welcome back to our blog series on the top reported vulnerabilities in our Bug Bounty and CVD programs.
In our previous blogs, we have already revealed the insights about XSS and IDOR vulnerabilities. If you haven’t read those, hurry up and find out more about those two top reported vulnerabilities.
But today we are going to talk about Structured Query Language (SQL) injection and discuss the types of this vulnerability, which of those are more common, where they occur, as well as what the outcome of a possible attack could be. Following that, you will find out the ways to mitigate the impact and most importantly, the steps that one can possibly undertake to prevent this vulnerability from happening!
SQL, or Structured Query Language, is a de facto standard language used for interacting with databases. It allows you to organize, manage and retrieve archived data from a database. SQL injection is a vulnerability where an attacker can interact with a database by altering SQL statements. This is often done through forms like input fields, login forms or in the URL.
In-band SQL injection
When the data is returned in the response of the website it is called in-band SQL injection. Because the data gets returned immediately this type of SQL injection is easy to detect. When causing an error, information about the structure of a database is returned in the error. This then can be used to enumerate tables, columns and other useful information.
When the structure of the tables is known, UNION can be used in a statement to retrieve data from arbitrary tables.
Out-of-band SQL injection
When the data is returned through a different channel than the website it is called out-of-band SQL injection. An attacker can make a request to a website that is vulnerable to SQL injection with a payload. This payload will collect information from the database and send it back to a service controlled by the attacker. For example, in a payload data is collected which is then sent back to the attacker's listener service with a DNS request.
Out-of-band SQL injection is less common because this vulnerability only occurs when specific features are enabled on the database server.
Blind SQL injection
With blind SQL injection less data is returned in the response. This makes it harder to gain information, but still this type of injection is not less dangerous. Even though information is harder to gain, it is still possible to interact with the database and delete, alter or gain information.
To know whether or not a SQL statement was successful, SLEEP(5) can be used. This will cause 5 seconds of delay with a successful statement. If there is no pause in the response, the statement was unsuccessful.
Another method for determining whether a SQL statement is successful, is by using SQL queries that result in boolean values. The resulting value will be something like True/False. A True, or equivalent of True, response confirms that the SQL statement was successful.
SQL injection can be abused to extract data from a database, but another use is bypassing authentication. For example, when logging in to a website, the database checks if the input matches the information in the database. If the given username and password match, a boolean value True is returned. Knowing this, it is not even necessary to retrieve usernames and passwords from the database. All that is needed is a way to force the query that is used to authenticate the user to evaluate to True. This can be done by inputting ' OR 1=1;-- into a password form when supplying an existing username. Since 1=1 is a true statement the database returns True to the application after which an attacker is logged in without valid credentials.
A SQL injection attack can result in unauthorized access to all data stored in a database, or even execution of Operating System commands. This information can then be used to impersonate a user, or get more access by using the admin credentials.
Another impact is the alteration of the database, meaning that the information can be changed or deleted. By deleting data the availability of an application can be affected.
Because of the high impact and many possibilities with SQL injection it is often considered a high or critical vulnerability.
Preventing SQL injection
Prepared statements with parameterized queries can be used to prevent SQL injection.
A prepared statement query is a means of pre-compiling a SQL statement so that all you need to supply are the parameters that need to be inserted into the statement for it to be executed.
This ensures that an attacker is not able to change the intent of a query, even if SQL injection is possible.
There are ways of mitigating impact when prevention of SQL injection is not possible.
To mitigate SQL injection user input should be filtered. Characters that can be used to trigger SQL injection can be blacklisted. Another way of ensuring these characters cannot be used, is with output encoding. With output encoding the characters that are used for SQL injection will be converted to an equivalent of that character. This way the characters are not recognized as SQL language, and will not be executed as such.
A WAF(Web Application Firewall) can help protect against SQL injection by filtering the traffic between the website and the internet.
Output filtering and a WAF only help mitigate the impact and should not be relied on to prevent SQL injection.
We hope you found this information useful, and we have far more interesting insights on the top reported vulnerabilities that still yet to come! Stay tuned for the upcoming blog!
SQL injection cheat sheet.
SQL Injection Prevention Cheat Sheet.
Don’t let vulnerabilities become your weakness: implement a Coordinated Vulnerability Disclosure program
Written by Zerocopter
June 29, 2022
Share this blog: