This attack is applicable to IBM DB database in your server. SQL Injection is a kind of method used by hackers to access, modify and delete the data inside the database. By leveraging SQL Injection hackers will also be able to bypass authentication and access unauthorized data from databases. In some cases, it can even be used to execute commands on the operating system, potentially allowing an attacker to escalate to more damaging attacks inside the network where the application is hosted. Based on different strategies used by the hackers for injecting the SQL commands there are different categories like In Band SQL Injection, Inferential SQL Injection and Out of band SQL injection. Boolean based SQL injection is a kind of Inferential SQL Injection.
It is a technique which relies on sending an SQL query to the database which forces the application to return a different result depending on whether the query returns a TRUE or FALSE result. Depending on the result, the content within the HTTP response will change, or remain the same. This allows an attacker to infer if the payload used returned true or false, even though no data from the database is returned. Even though it is a slow attack this will help the hacker to enumerate the database.
A vulnerable data access layer of an application can build an SQL query as shown below from the above URL request.
If the application is vulnerable to SQL injection probably it will not return anything and the hacker will next inject a query with a true condition (1=1). If the content of the page is different than the page that returned during false condition, then the hacker is able to infer that, SQL injection is working. Now the hacker is able to verify it he all set to use other SQL Injection methods.
Depending on the back-end database configuration, its privilege setup and the operating system, a hacker can mount one or more of the following type of attacks :
SQL injection flaws typically look like this:
The following (Java) example is UNSAFE and is a typical example.
In a prepared statement with the parameterized query, the developer has to define all the SQL code and then pass in each parameter to the query later. This helps the database to differentiate between code and data, regardless of the input.
This statement prevents an attacker from changing the intent of a query even if SQL commands are inserted by him.
Language Specific Recomandations
Safe Java Prepared Statement Example
Safe C# .NET Prepared Statement Example
Hibernate Query Language (HQL) Examples
Stored procedures are not always trustworthy in all types of SQL injecton. A stored procedure gives the same effect of a parameterized querry, if it is implemented correctly. A stored procedure language requires the developer to build SQL statements with parameters. SQL code for a stored procedure is defined and stored in the database itself. This is then called from the application. Both of these techniques have the same effectiveness. The implementation is dependent on your organization.
Safe Java Stored Procedure Example
Safe VB .NET Stored Procedure Example
There are many non legal locations for the use of bind variables., such as the names of tables or columns and sort order indicator. For this, whitelist input validation is the most appropriate defense. The name of tables or columns are usually extracted from code and not from user parameters. But, it uses parameter values are used instead of this, then parameter values should be mapped to the legal expected table or column names to make sure invalidated user input doesn’t get run in the query.
For a sort order, it is best if the user supplied input is converted into boolean, and then that boolean is used to select the safe value to append to the query. This is important in dynamic query creation. For example:
This technique is used, if any other injection prevention techniques are unusable. It is probably a better choice even though, the methodology is weak compared to the defenses and cannot guarantee it will prevent al SQL injection in all situations. This is usually recommended to retrofit legacy code when implementing input validation isn’t effective.
In this technique, each DBMS supports one or more characters escaping schemes specific to certain kinds of queries. If admin logs in then escape all user supplied input using the proper escaping scheme for the database. The DBMS will not confuse that input with SQL code written b the developer, thus avoiding any possible SQL injection vulnerabilities.