SQL Injection: How Hackers Can Threaten a Corporate Database Without Breaking the Firewall

"Our database has its own firewall protecting it!" — a reassuring claim that, according to author Dũng Nguyễn, almost everyone working in systems, networking and security has heard. But in article #02 of the series "Anatomy of 5 Ways Hackers Break Into Enterprises", he points out a paradox: a firewall controls very well who may connect to a database, but an ordinary network firewall does not by itself guarantee that every query travelling over a legitimate connection is safe. When a web application has a SQL injection flaw, the application server itself — the machine the firewall trusts — sends the manipulated queries to the database, over a perfectly valid session. The firewall stays green, the server keeps running, the database stays online — while data may already have been accessed without authorization.

Quick answers

• What SQL injection is: when a developer builds a SQL statement by concatenating user input directly into the query string, part of that input can be interpreted by the database as SQL syntax, changing the meaning of the query — from looking up one permitted record to retrieving data beyond the intended scope.
• Why the firewall does not stop it: attackers do not connect to the database directly; they send HTTP/HTTPS requests to the website, the application generates a manipulated query, and the application server itself sends it over a connection the firewall already allows (correct source IP, destination IP, TCP port 1433, valid session). The firewall controls connections, not application logic.
• Three different layers of protection, none of which replaces the others: the network firewall controls the path to the database; the WAF detects and blocks many attack patterns at the web layer; a dedicated database firewall can analyze query activity more deeply — but no layer replaces the application's own responsibility to generate safe queries.
• The database account's privileges decide the scale of damage: SQL injection does not automatically mean the attacker owns the whole database. If the application account may only read a small data scope, the impact is significantly contained; if the account has broad rights, write/delete rights or administrative rights, the risk rises sharply — which is why the least-privilege principle is a real layer of defense.
• Detection must look across many layers at once: the WAF, web server access logs, application server exception logs, internal firewall traffic between the Application Zone and the Database Zone, and auditing at the database layer (SQL Server Audit/Extended Events; Oracle, PostgreSQL and MySQL have equivalent mechanisms). Having logs is not enough — logs must be collected, time-synchronized, retained, analyzed, correlated, and owned by someone responsible for acting on them.
• When one is found, do not just block an IP: verify the flaw, determine the affected scope and assess whether data was accessed or altered; developers fix how queries are built at the root (parameterized queries/prepared statements, never concatenating user input into SQL), DBAs review account privileges, network/security teams review WAF and firewall policies, and systems teams preserve logs; then retest to confirm the flaw is fixed and the protective layers behave as designed.

What is SQL injection, really?

Picture a customer-management website: a user types a customer name to search, the application receives the input, builds a SQL query, sends it to the database, and the database processes it and returns results. This flow runs thousands of times a day and is normally harmless.

The risk appears when the developer builds the query by concatenating user input directly into the SQL string. Input that should be treated purely as data can then be interpreted by the database as SQL syntax. An attacker exploits that weakness to change the query's meaning: instead of looking up one permitted record, the query can be manipulated to retrieve data beyond the intended scope.

The author stresses an important caveat against exaggeration: SQL injection does not automatically mean the attacker takes over the entire database or server. The scale of harm depends on many factors — the exploitation conditions, the privileges of the account connecting to the database, and the database configuration — and under special conditions the flaw can also become one link in a wider attack chain. Possible consequences include unauthorized access, information disclosure, or data modification.

Why does a firewall-trusted application become the way into the database?

Consider the familiar architecture: Internet → WAF → Web/Application Server → Internal Firewall → Database Server. The database is firewall-protected; only the application server may connect to it over TCP 1433; the user VLAN is blocked; the internet has no direct access. From a network-segmentation standpoint this is a sound design — and on the dashboard everything looks safe: CPU stable, RAM fine, database online, website running normally, no critical alerts.

But SQL injection does not necessarily begin with a direct connection to the database. It begins with an HTTP/HTTPS request to the website. If the application handles input unsafely, the application itself generates a manipulated SQL query, and the application server then sends that query over the firewall-approved database connection. The network firewall sees a perfectly legitimate session: valid source IP, valid destination IP, valid port, valid session, permitted by policy — but the query may have been manipulated at the application layer.

That does not make the firewall useless: it still blocks unauthorized connections and limits other paths to the database. But it shows a truth the author wants infrastructure people to pay special attention to: connection control cannot fully replace control of application logic. Do not confuse allowing a connection with guaranteeing that everything inside it is safe.

Does a dedicated database firewall solve the problem?

Not all firewalls are alike, and the question is well worth discussing. The three kinds of device play three different roles:

Protection layer	Main role	Limits to understand
Network Firewall / NGFW	Connection control, network segmentation, access policy	Does not analyze query content; a valid TCP 1433 session does not prove the query inside it is safe
WAF	Analyzes HTTP/HTTPS requests, detects and blocks many web-application attack patterns	Operates at the web layer; cannot see the final SQL query the application generates
Dedicated Database Firewall	Analyzes the database protocol, monitors SQL queries, applies policy based on query activity; can detect, alert on or block structurally unusual queries or access to inappropriate data objects	In passive monitoring mode it can alert but not block; if the connection is encrypted and the device has no suitable observation mechanism, analysis is limited; an over-broad policy still lets unwanted queries through; a structurally valid query exploiting a business-logic flaw is very hard to distinguish as malicious

The author's conclusion: a database firewall is a valuable layer of protection, but it does not replace the responsibility to fix the application. No single layer of protection solves everything — the application must still be designed to generate safe queries.

How do database account privileges affect the outcome?

Continuing with the CRM example: the application connects to a SQL Server holding customer information, contracts and transaction history. To deploy quickly, the database connection account was given very broad rights — the application only needs to read and update a few tables, but the account can access many other tables and even perform unnecessary administrative operations.

One day the application develops a SQL injection flaw. If an attacker exploits it successfully, they inherit exactly the privileges the application account holds. If the account may only read a small data scope, the damage can be significantly contained. If the account can access many sensitive tables, the blast radius is much larger; add write, delete or dangerous administrative rights and the risk climbs further.

An application flaw can become far more dangerous when combined with an over-privileged database account. That is why the least-privilege principle (granting only the minimum rights needed) is not paperwork for the design file — it is a real layer of defense, and sometimes correct privilege assignment alone decides whether an attack stays small or becomes a serious incident.

What forms does SQL injection take?

Many people think SQL injection is just typing a special string into a login box to bypass authentication. In reality there are several forms, each with its own exploitation conditions, and not every application is affected the same way:

• Error-based: the application exposes overly detailed database error messages, giving attackers information to infer query or data-structure details.
• Union-based: unexpected data can appear directly in the application's response.
• Blind: the application shows no clear error or data; attackers must infer information from differences in responses or in processing time.
• Out-of-band: under special conditions, information or signals are exfiltrated through a different channel.

All share one essence, as the author summarizes: untrusted data changed how the database understands and executes the query. And that is why SQL injection remains one of the application vulnerability groups that deserves serious attention.

The firewall is green and the website runs — how does IT detect it?

This is the post's most practical question. A SQL injection attack does not necessarily crash a server, push CPU to 100%, drop the database connection, or raise a critical alert on the network firewall. Detection requires looking across many layers:

Observation layer	What to look at	Caveat
WAF	Requests showing SQL injection signs, unusual parameters, abnormal access frequency, repeated exploitation attempts	Do not conclude from a single alert — false positives exist
Web Server	Access logs of IIS, Nginx or Apache: URLs, parameters, response codes, unusual access patterns	The signal is in the access pattern, not a single log line
Application Server	Exception logs, data-processing errors, behavior inconsistent with business functions	Unusual application errors can be traces of exploitation attempts
Internal Firewall	Traffic between the Application Zone and the Database Zone: correlate source IP, destination IP, port, session and connection times	A valid TCP 1433 session alone proves neither the presence nor the absence of SQL injection
Database	Unusual queries, privilege changes, unexpected data access, operations inconsistent with the application account; SQL Server Audit or Extended Events; Oracle, PostgreSQL and MySQL have equivalent logging/audit mechanisms	A database firewall or database activity monitoring (if present) is a very useful additional source

And the author emphasizes one point: having logs is not the same as having incident-detection capability. Logs must be collected, time-synchronized, retained appropriately, analyzed, correlated — and someone must be responsible for handling them. A single log line may say nothing, but combined web logs, WAF logs, firewall logs, application logs and database audit records give the technical team enough to reconstruct the incident. That is the real value of security monitoring.

If SQL injection is found, what must the business do?

Do not just block one IP address and declare the matter closed — an IP address is only part of the story. First verify the flaw, determine the affected scope, and assess the risk that data was accessed or altered without authorization. Then coordinate across technical teams:

• Developers: fix how the application builds queries at the root — use parameterized queries or prepared statements correctly, never concatenate user input into SQL; check other features with similar handling.
• DBAs: review the application account's privileges and remove unnecessary rights; check data access activity, structural changes and signs of anomalies.
• Network and Security teams: review WAF policy, firewall policy and connection flows between network zones; if a dedicated database firewall exists, check its monitoring and blocking policies.
• Systems team: ensure logs are preserved, related systems are checked, and remediation changes cause no unplanned disruption.
• If data may have been accessed without authorization: activate the incident response process, preserve evidence, and assess notification obligations under applicable regulations.

After remediation, retest — not just to check whether the website works, but to confirm the flaw has been addressed and the related protective layers behave as designed. Blocking an IP may reduce immediate risk, but fixing the application flaw and reducing database privileges are what address the root cause and limit the damage.

Questions for managers and business owners

The post's conclusion goes beyond technology. The author recalls: early in his technical career, he thought simply — application bug, call Dev; database bug, call the DBA; server bug, call Systems; network bug, call Network; firewall bug, call Security; everyone minds their own job. But the longer he worked, the more he realized: hackers do not care how a business divides its departments. They do not ask whose responsibility a flaw is, or which contractor deployed the firewall — they only need one exploitable weakness. An application generating unsafe queries, an over-privileged database account, a firewall policy widened for an urgent deployment, an audit system not fully configured, an alert that appeared but nobody handled — each alone may be a small mistake, but combined they can create a very large risk.

And when customer data is affected, nobody can explain that "this is a programming bug, not an infrastructure bug" or "our firewall was still running fine". Responsibility boundaries are necessary in contracts and operations, but they cannot replace a coordinated, end-to-end risk-handling mechanism. Customers do not buy a firewall to admire its dashboard, or a server to watch CPU and RAM — they invest in a system that serves the business and protects valuable data.

Instead of only asking "do we have a firewall protecting the database?", the author suggests managers ask five more questions:

1. Is the application generating safe queries?
2. How far do the database connection account's privileges reach?
3. If the application is exploited, what can the firewall actually limit?
4. Can we detect unusual query activity?
5. And if data has been accessed without authorization, who will detect, investigate and handle it?

Because in the end, a hacker does not necessarily have to break the firewall to threaten the database — it can exploit the very application the firewall allows in. And the scariest part is: the firewall stays green, the server keeps running, the database stays online, the website works normally, yet data the business spent years accumulating may have been accessed without anyone intending it. Not because there was no firewall, but because allowing a legitimate connection was confused with guaranteeing that every action inside that connection is safe. Security cannot be measured only by the number of devices a business has bought.

Frequently asked questions

What is SQL injection, in the simplest terms?

It is a flaw that occurs when an application builds a SQL query by concatenating user input directly into it. Part of that input can then be interpreted by the database as SQL syntax, changing the query's meaning — from looking up one permitted record to retrieving data beyond the intended scope. Per the author, the common essence of all forms is: untrusted data changed how the database understands and executes the query.

With a firewall and WAF in place, how can SQL injection still threaten the database?

Because attackers do not connect to the database directly; they send requests to the website, the vulnerable application generates a manipulated query, and the application server — the machine the firewall trusts — sends it over an already-permitted connection (right IP, right TCP port 1433, valid session). The firewall controls who may connect, and the WAF sees the web layer; neither guarantees the content of queries inside a legitimate connection is safe. A dedicated database firewall looks deeper into queries but has its own limits and does not replace fixing the application.

Does SQL injection mean the hacker owns the whole database?

Not automatically. Per the author, the scale of damage depends on the exploitation conditions, the privileges of the account the application uses to connect to the database, and the database configuration. An account that may only read a small scope limits the damage significantly; a broadly privileged account with write/delete or administrative rights makes the risk much larger. That is why the least-privilege principle is a real layer of defense.

How can SQL injection be detected when every dashboard looks normal?

By looking across many layers at once and correlating them: unusual request patterns and alerts at the WAF; web server access logs; application server exception logs; traffic between the Application Zone and the Database Zone at the internal firewall; and auditing at the database layer (SQL Server Audit/Extended Events, or the equivalents in Oracle, PostgreSQL and MySQL). The author stresses: having logs is not enough — they must be collected, time-synchronized, retained, analyzed, correlated, and owned by someone responsible for acting on them.

What is the right response order when SQL injection is found?

Verify the flaw and assess the affected scope and whether data was accessed or altered first; then coordinate across teams: developers fix the root cause with parameterized queries/prepared statements and review similar features; DBAs narrow the application account's privileges; network/security teams review WAF and firewall policies; the systems team preserves logs. If unauthorized data access is suspected, activate incident response, preserve evidence and assess notification obligations. Finally, retest to confirm the flaw is fixed — do not stop at blocking one IP address.

Conclusion

Dũng Nguyễn's article does not argue against firewalls — on the contrary, the author states that firewalls matter greatly, WAFs matter greatly, and database firewalls have value in suitable architectures. His message is: no single device replaces the responsibility to design and operate the whole system safely. SQL injection is dangerous precisely because it travels the most legitimate path — a trusted application, a permitted connection, a green dashboard. Effective defense is therefore a combination: code that generates safe queries, least-privilege database accounts, correctly configured firewall/WAF layers, logs that are correlated and acted on, and a coordination mechanism spanning teams when an incident occurs. That is also the right way to measure security: not by the number of devices bought, but by the ability to detect, contain and resolve risk all the way through.

Source: the article "Anatomy of 5 Ways Hackers Break Into Enterprises — #02: SQL Injection" by Dũng Nguyễn, posted in the Facebook group Community of Digital Sarch (6 November 2026). The article is a defensive analysis and contains no exploitation instructions; edited and structured by Wotech Electronics. Illustration created by Wotech (the original post had no attached images).