Tweet
Some variants of the SQL injection attack exists and these types are related to how the vulnerability is visible or not and how an attacker may confirm if an attack is successful or not.
Error Based SQL Injection
Adding a quote to a parameter in a GET request by tampering with the URI is some times enough to reveal if a web site is vulnerable to a SQLi attack. If the application is not sanitizing the input and is merging the invalid user input into the SQL query and attempts to execute the request, the underlaying database may return an error to the web site. This error is what makes the attack error-based. The web site will return a visual representation of the SQL query the application attempted to execute including what ever the attacker managed to inject. This kind of injection is easy for the attacker to work with because the end result of the tampered SQL query is visible and therefore it is easy to correct any errors using just a bit of trial and error. In this attack UNIONs are often used to inject additional results. Stored Procedures may also be a target for this kind of attack. Another way of attacking is to use tautology in which the attacker attempts to express the same in order to bypass any validation. This could be to add OR 1=1 to a query. An attack often include the first part of the original query from the application. To make sure any part of the original query trailing the injected query, the remainder of the original query may be commented out using "--", "##" or what ever the target DBMS uses for SQL remarks.
Time-Based Blind SQL Injection
In cases in which the application does not return errors it is not directly visible if the injection was successful or if the query did not return anything. In that case another technique is required to determine if the attack was successful. This is much more time-consuming and takes a lot of trial and error just to investigate how the query internal to the application is build. The technique used is to modify the complete SQL query to make the underlying database sleep for some seconds if the query was executed successfully; the web application will load at normal speed if the query failed but will sleep for some seconds if the query executed successfully. The delay have to fit the load time of the web application under normal circumstances and it is not uncommon to set the delay to 10 seconds. To accomplish this the attacker will attempt to use true or false statements in the SQL query. In case the query is true the pause will be implemented, telling the attacker that the complete query succeeded. If the application does not hang for 10 seconds longer than normal load time, the query either returned false or failed to execute. Blind SQL Injections does not require to be time-based. If a generic error page is returned but with no useful information returned to the attacker, this could still be considered blind.
Even though internal errors like this should never be presented to the end user in a production environment, this is sometimes the case. Errors, warnings and any other information that is not meant for the end user to see, should be written in logs.
Evading Detection Mechanisms
Some IDS systems have the capability to monitor database applications and are effective at detecting activities that may indicate an attack.
To evade such an IDS system or to prevent detection there are some techniques available. In many cases IDS systems use signature-based detection which means that many attacks will seek to avoid resembling known attacks. If an attacker matches a known pattern, it will trigger an alert.
Some ways to do this include
Countermeasures
SQL injection is a hard attack to defend against and is a very powerful attack if successful but mitigations are available to make them less damaging or less likely to occur. One of the most effective mitigations is the use of well-done input validation before this input is merged with the SQL query. It is recommended to sanitize user input server-side because client-side is more likely to be defeated by the attacker but both could be in place.
Some of the common mitigations include the following
Error Based SQL Injection
Adding a quote to a parameter in a GET request by tampering with the URI is some times enough to reveal if a web site is vulnerable to a SQLi attack. If the application is not sanitizing the input and is merging the invalid user input into the SQL query and attempts to execute the request, the underlaying database may return an error to the web site. This error is what makes the attack error-based. The web site will return a visual representation of the SQL query the application attempted to execute including what ever the attacker managed to inject. This kind of injection is easy for the attacker to work with because the end result of the tampered SQL query is visible and therefore it is easy to correct any errors using just a bit of trial and error. In this attack UNIONs are often used to inject additional results. Stored Procedures may also be a target for this kind of attack. Another way of attacking is to use tautology in which the attacker attempts to express the same in order to bypass any validation. This could be to add OR 1=1 to a query. An attack often include the first part of the original query from the application. To make sure any part of the original query trailing the injected query, the remainder of the original query may be commented out using "--", "##" or what ever the target DBMS uses for SQL remarks.
Time-Based Blind SQL Injection
In cases in which the application does not return errors it is not directly visible if the injection was successful or if the query did not return anything. In that case another technique is required to determine if the attack was successful. This is much more time-consuming and takes a lot of trial and error just to investigate how the query internal to the application is build. The technique used is to modify the complete SQL query to make the underlying database sleep for some seconds if the query was executed successfully; the web application will load at normal speed if the query failed but will sleep for some seconds if the query executed successfully. The delay have to fit the load time of the web application under normal circumstances and it is not uncommon to set the delay to 10 seconds. To accomplish this the attacker will attempt to use true or false statements in the SQL query. In case the query is true the pause will be implemented, telling the attacker that the complete query succeeded. If the application does not hang for 10 seconds longer than normal load time, the query either returned false or failed to execute. Blind SQL Injections does not require to be time-based. If a generic error page is returned but with no useful information returned to the attacker, this could still be considered blind.
Even though internal errors like this should never be presented to the end user in a production environment, this is sometimes the case. Errors, warnings and any other information that is not meant for the end user to see, should be written in logs.
Evading Detection Mechanisms
Some IDS systems have the capability to monitor database applications and are effective at detecting activities that may indicate an attack.
To evade such an IDS system or to prevent detection there are some techniques available. In many cases IDS systems use signature-based detection which means that many attacks will seek to avoid resembling known attacks. If an attacker matches a known pattern, it will trigger an alert.
Some ways to do this include
- Sophisticated matching techniques designed to use alternative means of representing queries.
- HEX coding, or converting queries into their hexadecimal representation.
- Liberal use of whitespaces.
- Use of comments in code to break up statements.
- Concatenating strings of text to create SQL keywords.
- Obfuscated code, or a SQL statement that has been made difficult to pattern match.
Countermeasures
SQL injection is a hard attack to defend against and is a very powerful attack if successful but mitigations are available to make them less damaging or less likely to occur. One of the most effective mitigations is the use of well-done input validation before this input is merged with the SQL query. It is recommended to sanitize user input server-side because client-side is more likely to be defeated by the attacker but both could be in place.
Some of the common mitigations include the following
- Avoid the use of dynamic SQL. There are queries that are build on demand. Dynamic statements are generated from the options and choices made on the client side. Such statements should be avoided in favor of using stored procedures or predefined statements.
- Perform maintenance on the server regularly and keep an eye out for software updates and patches.
- Intrusion detection systems also play a vital role in protecting database systems. Some IDS systems have the capability to monitor interactions at the database layer.
- Harden a system to include the operating system and database. Every database has countless options and features, of which only a handful tend to be used regularly. Disabling unneeded features prevents them from being used during an attack.
- Exercise least privilege and give the database and the application that uses it, only the access they need.
- Ensure that applications are well tested before being deployed in a production environment.
- Avoid default configurations and passwords.
- Disable error messages outside development environments.
- Use reverse proxies or Web Application Firewalls (WAFs) when ever possible.