We Bricked Up the Backdoor Ourselves

One of the most fascinating challenges we worked on last year for our business intelligence product was defending against SQL Injection. Interestingly, at the time we were testing and deploying this capability, I hadn’t delved deeply into the methodology, much like the situation today.

However, the research I conducted afterwards was truly exciting and enlightening. If you work in software development or testing, this story might be of interest to you.

What is SQL Injection? (In Simple Terms)

To explain it, let’s imagine a login page. A user enters their username and password and clicks the “Login” button. What happens behind the scenes? Our application sends a “command” or “query” to the database to verify the user’s existence.

For example, if the user enters aria and password 1234, the final command becomes:

The database searches for a match; if a user exists, access is granted.

How Does the Attack Happen?

Instead of a normal username, a hacker enters a malicious SQL command! For example, in the “Username” field, they might type: text

And in the password field, any arbitrary string like abc. Now, the command sent to the database changes drastically:

What does this query do? The database interprets it as: “Select a user where either the username is empty, OR where ‘1’ equals ‘1’ (which is always true!) and the password is abc.”

The result? The condition OR ‘1’=‘1’ always evaluates to true, overriding the entire query logic, and the database returns the first user from the table (who is likely an administrator!). The hacker gains access to the system without knowing the password. This vulnerability is not limited to login!

This security weakness can exist anywhere user data is directly concatenated into a database query, such as search forms, filter and sort functions, URL parameters, contact forms, surveys, and HTTP headers. For example, consider a search form built with the following query:

If a user enters this phrase into the search box:

The final query becomes:

This command first returns all products and then executes the DROP command, which deletes the entire Products table! The – sequence comments out the rest of the original command.

What about more advanced attacks?

Classic attacks are just the beginning. More sophisticated methods exist:

• Blind SQL Injection: The attacker does not directly see the query results but can infer data by analyzing server response times or error messages (e.g., if the first character of the admin’s password is ‘a’, the server delays for 5 seconds!).

• Out-of-Band SQL Injection: The attacker exfiltrates stolen data via a secondary channel, such as a DNS request, to a server they control.

• Second-Order SQL Injection: The malicious payload is first stored in the database (e.g., in a comment). Later, when a privileged user (like an admin) accesses that data, the payload is activated.

How Can We Defend Against It?

Combating SQL Injection is not just a “feature”; it is an architectural concern requiring a multi-layered strategy (Defense in Depth):

1. Prevention: The mandatory use of Parameterized Queries (Prepared Statements). This is the primary, non-negotiable line of defense.

2. Sanitization: Validating and filtering all user input based on an allow-list.

3. Least Privilege: Connecting the application to the database using a user account with the minimum necessary permissions (e.g., never use the root user!).

4. Obfuscation: Never display raw database error messages to the end user.

5. Detection: Using a Web Application Firewall (WAF) to identify suspicious patterns.

6. Hardening: Disabling dangerous and unnecessary database features.

Each of these security practices could be explained in detail, which is beyond the scope of this post. Securing our product against this attack was a journey, not a destination. Now, we can scale our application with greater confidence.