How to Prevent Blind SQL Injection Attacks?

You are probably aware that SQL injection (SQLi) attacks are the oldest, most prevalent, and lethal kind of web application vulnerabilities and probably know how to prevent attacks that leverage the SQLi vulnerabilities. However, despite these efforts, you may be leaving your web applications/ websites vulnerable to blind SQL injection, a subtype of SQLi vulnerabilities.

In this article, we will explore in-depth about Blind SQLi attacks, Blind SQL Injection types, and how to prevent them.

What are Blind SQL Injections?

Blind SQL Injection attacks occur when the backend database interprets data inputs by the attacker as an SQL command, not as normal data inputs by users. Typically, attackers leverage web applications that show generic error messages without mitigating SQLi vulnerable code. The attackers ask true or false questions to the backend database of such a vulnerable application and The existence of SQL injection is determined basis the response of the application.

The major point of difference between Blind SQLi and classic SQLi is the way in which the attacker retrieves data from the backend database. In classic SQLi attacks, the attacker can see database errors or outputs of the malicious SQLi commands in the web app. When the database doesn’t show error messages or output to the malicious command, the attackers steal data by asking a series of true or false questions to the backend database and see if the application or page loads correctly, time is taken to process the SQL query or the other such changes. Blind SQL injections are time-consuming and difficult to exploit but not impossible and produce similar results for the attackers.

Blind SQL Injection Types

• Content-based Blind SQLi: Here, the attacker analyzes the difference (if any) in the way a page load or the change in the content length of the page; based on the inputs supplied by An attacker

Ex;

The below application URL

http://www.example.com/item.php?id=2

this will send the below as the request in the database.

SELECT title, description, body FROM items WHERE ID = 2

The attacker then injects the below as the query;

http://www.example.com/item.php?id=2 and 1=2

the resultant SQL query be like;

SELECT title, description, body FROM items WHERE ID = 2 and 1=2

The above query will be a false result and hence the application will not display any data output; whereas on injecting a true statement; the application will show some data.

By comparing the outputs received; one can conclude the existence of a SQL injection attack,

• Time-based Blind SQLi: Here, the attacker analyzes if the database pause for a time period specified by him/her before returning the results

Microsoft SQL Server uses “WAIT FOR DELAY ‘0:0:10’’

PostgreSQL uses pg_sleep()

Impact of Blind SQLi Attacks

The impact of Blind SQLi attacks is similar to that of classic SQL Injection attacks. It gives the attacker access and control over the backend database server. They can

• Database fingerprinting: in case of a time-based approach being used. This helps in database fingerprinting and there are specific time-delay payloads for specific databases
• Steal sensitive customer and/or business information such as credit card numbers, personal information of customers/ employees, patents, IP, etc.
• Read, add, update, or delete data or tables from the database or execute administrative commands.
• Gain privilege escalation that enables them to completely gain control over the server/ application/ operating system.

Preventing Blind SQLi Attacks

It is important to note that the skills and tools required to exploit blind SQLi vulnerabilities may differ widely from classic SQLi vulnerabilities, but the prevention techniques are very similar for kinds of SQL Injections. Very often, the developer’s ill-founded, poorly thought and weak efforts to protect the web application against classic SQLi vulnerabilities cause blind SQLi vulnerabilities. For instance, turning off error reporting.

Ensure Secure Coding Practices

Regardless of what language you are using, the coding practices you use must be in sync with the OWASP Secure coding guidelines. Most web development platforms offer mechanisms to avoid all SQL Injections. Use parameterized queries instead of dynamic queries (details below). Remember to implement a whitelist of special characters from all user-input fields (comments, contact form, etc.). and to use the input encoding.

Consider using Database Layer Access (DAL) as it enables you to centralize the issue or Object Relational Mapping (ORM) systems as they use only parameterized queries. In either case, convert all legacy codes based on these new libraries.

Use Parameterized Queries

Avoid dynamic SQL queries at all costs and use parameterized queries instead. Parameterized queries are prepared statements that enable you to effectively and robustly mitigate Blind SQL Injections. So, locate all dynamic SQL queries and convert them to parameterized queries.

Comprehensive and Intelligent Security Scanning Tool is a Must-Have

Using a comprehensive and intelligent security scanning tool, regularly scan your web application (right from the developmental stages) to identify new bugs and gaps that can cause SQLi attacks.

Onboard a Managed and Robust Security Solution

Scanning can only identify gaps and vulnerabilities. To protect your web application against these attacks, these vulnerabilities need to be secured and patched until they are fixed. Onboarding a robust and managed security solution like AppTrana which offers an intelligent and managed WAF, regular security audits, and pen-testing and the services of certified security experts to ensure that your application is secure at all times against vulnerabilities including blind SQLi.

Stay tuned for more relevant and interesting security updates. Follow Indusface on Facebook, Twitter, and LinkedIn