SQL Injection Attacks Explained: With Real-World 2026 Case Study from a North-Indian Bank

SQL injection is the oldest serious web vulnerability and yet it still appears in the OWASP Top 10 in 2026. Why? Because the underlying mistake — concatenating untrusted input into a query — is still made every day, in every Indian framework, by developers who learned secure coding 10 years ago and never updated. This piece explains how SQLi still happens, with a redacted case study from a 2025 incident we observed during a VAPT engagement.

What is SQL Injection?

SQL injection happens when an attacker controls part of a database query the application sends to the server. The classic example:

// VULNERABLE
String query = "SELECT * FROM users WHERE email = '" + userInput + "'";

If the user submits ' OR '1'='1 as their email, the resulting query becomes SELECT * FROM users WHERE email = '' OR '1'='1' — which returns every row in the table.

Real-World Case Study (Redacted, 2025)

A mid-sized regional bank in north India contracted our team for an external VAPT. Within 4 hours we found a classic time-based blind SQLi on their corporate-loan application form. The form had passed automated DAST scans for years because it returned the same HTML for valid and invalid input.

The attacker primitive: a employer_pincode POST parameter went straight into a WHERE clause. We weaponized IF(SUBSTRING(@@version,1,1)='5',SLEEP(5),0) — the response timing leaked one byte at a time.

Total time to full database read: 6 hours. Total time it took the bank to deploy a fix: 3 days. Lesson: a well-structured input-validation policy + parameterized queries would have eliminated the entire attack class in 30 minutes of development time.

Categories of SQLi You Will See in 2026

1. Classic / Error-based — error messages leak data directly
2. Union-based — combine attacker-controlled SELECT
3. Boolean blind — yes/no inference from response differences
4. Time blind — yes/no inference from response timing (our case study)
5. Out-of-band — DNS / HTTP exfiltration via database functions
6. Second-order — payload stored, executed later in another query

How to Find SQLi During a Pen-Test

1. Identify every parameter that touches a database (search forms, sort/filter, IDs)
2. Test each with quote / double-quote / backslash to trigger errors
3. Test boolean differentials — 1 AND 1=1 vs 1 AND 1=2
4. If neither works, time-based: '; WAITFOR DELAY '0:0:5'-- (MSSQL) or SLEEP(5) (MySQL)
5. Once you confirm injection, automate with sqlmap

How to Defend (developer's side)

1. Parameterized queries / prepared statements — non-negotiable
2. ORM with auto-parameterization — Prisma, Sequelize, JPA (be careful with raw queries)
3. Strict input validation — typing, length, allow-list
4. Least-privilege DB user — app should not be db owner
5. WAF as a second layer, never primary defense
6. Annual VAPT — preferably by an external team like Cyber Defence VAPT

For Indian Businesses Specifically

RBI's Master Direction on IT for Banks, IRDAI guidelines, and SEBI's Cyber Security framework all mandate periodic VAPT. Many small banks and NBFCs in Haryana run only superficial scans — exactly the gap that lets old vulnerabilities like SQLi survive into 2026.

FAQs

Is SQL injection still common in 2026?

Yes — especially in older internal applications and government portals.

Are NoSQL databases immune?

No. NoSQL injection (Mongo, etc.) is a real class with similar impact.

Can WAFs alone stop SQLi?

No. WAFs are bypassable; secure code is the only reliable defense.