A new type of SQL injection technique can bypass the protections afforded by web application firewalls (WAFs) to attack websites, web applications and databases. Here's how to make sure your organization isn't impacted.
How the new SQL injection attacks work
Like most SQL injection attacks, this new method sneaks actionable code into what should be inert data inputs so that databases will execute hidden commands and potentially extract, change or delete data.
SQL injection (SQLi) attacks abuse structured query language, or SQL, which works with relational databases. Most WAFs can sanitize or block potentially malicious SQL syntax in data that has been submitted by website or web-app users.
However, this new SQLi variant, disclosed in December 2022 by Israeli-American security firm Claroty, adds a different type of code to the mix: JavaScript Object Notation (JSON), which is used by websites, web apps and web clients to efficiently exchange data.
Many JSON commands are recognized and parsed by some of the most widely used relational-database management systems (RDBMS), including MySQL, Microsoft SQL Server, SQLite and PostgreSQL. As a result, malicious JSON commands that have been snuck into SQL inputs may be executed.
Yet until recently, few WAFs recognized that JSON commands embedded in SQL syntax could be malicious. Taking advantage of this knowledge gap, Claroty used JSON-in-SQL to evade Amazon Web Services' built-in WAF and steal an administrator session cookie from a web app in a proof-of-concept exercise.
"Attackers using this novel technique could access a backend database and use additional vulnerabilities and exploits to exfiltrate information via either direct access to the server or over the cloud," said the Claroty report. "WAFs offer a promise of additional security from the cloud; an attacker able to bypass these protections has expansive access to systems."
Claroty said the same methods worked against WAFs from Cloudflare, F5, Imperva and Palo Alto Labs. Two other WAFs, Check Point's CloudGuard AppSec and its open-source spin-off, open-appsec, were discovered to be immune to this type of attack.
How to patch your WAF against the new SQL injection attacks
All five known affected WAF vendors pushed out patches before the Claroty report was posted. Amazon did so in January 2022, according to the Claroty report, and F5's release notes show that its patches were issued in March 2022.
A sixth firm, Barracuda Networks, pushed out updates to its WAF in mid-December 2022, a few days after the report. The open-source WAF ModSecurity, available as a plug-in module for the Apache, Microsoft IIS and Nginx web-server engines, appears to have been patched against the JSON bypass in January 2023.
If you use any of the WAFs mentioned above, use its regular update mechanisms to make sure its rules and software are fully caught up.
But what if your organization's WAF isn't among these? If so, then you'll need to reach out to the WAF's vendor or software maintainer and inquire if a patch for the JSON-based WAF bypass is available.
There's no one-size-fits-all test to see if your website or web app might be vulnerable to this attack. MySQL, PostgreSQL and other database management systems each support different sets of JSON syntax. Some WAFs already recognize some bits of JSON but not others. It's hard to know exactly what might slip through the cracks in each situation.
How to harden your web apps against future SQLi attacks
There are several time-tested ways to minimize the chances of a successful SQL attack against your website or web app.
Use app-sec testing tools during development.
These tools should catch syntax errors and weak points before code is implemented. Both static application-security testing (SAST) and dynamic application-security testing (DAST) will be useful in finding potential SQL-injection vulnerabilities.
"Let's say an application fetches data from an SQL database based on user input from a web form," explained Invicti's Zbigniew Banach in an August 2022 blog post.
"A SAST tool might identify the source code fragment that does this and warn the developer that the SQL query in a specific line of code is assembled in an insecure way and could potentially lead to an SQL injection (but might not). A DAST tool will find the web form on a page and run security checks to simulate actual SQL injection attacks."
Filter and sanitize user-provided database inputs.
Escape user inputs so that embedded SQL command characters cannot be executed, validate submitted data to make sure it's of the expected type (e.g., that names consist of letters rather than numbers or special characters), block known malicious bits of SQL syntax such as ' OR 1=1, and consider whitelisting valid SQL statements so that only necessary and desired procedures and functions can be run.
Set up your SQL database to use prepared statements and parameterized queries.
This adds a little overhead, but it separates the SQL commands from the inputs by first drafting a statement with placeholders, then adding the actual inputs to replace the placeholders. It's much safer than dynamically generating SQL statements containing unfiltered user data.
Use stored procedures.
These are precompiled sequences of SQL instructions that are stored on the database and which the RDBMS can call on when needed. They further separate SQL commands from data inputs.
Encrypt sensitive data stored in the database and hash and salt user passwords.
These procedures won't prevent SQL injection, but they will create a cushion against the worst-case consequences.
Restrict database access.
Not every user or app should have access to the database, and none should have any more privileges than they need. Even web apps should only have limited privileges on databases.
Use a web application firewall.
Despite the bypass described above, WAFs offer a great deal of protection for your sites and apps and will monitor database communications to spot and block potential SQLi attempts.
Do not display database error messages to regular users.
If you must, then minimize what the error messages say. Overly verbose error messages give away too much information.
Block or minimize browser display of extended URLs that expose SQL queries.
Amazon may let its users see URLs full of ampersands, question marks and equal signs, but you don't have to. They might tell adversaries too much about your database's structure.
Minimize sharing of databases.
Ideally, each web application or website should have its own database.
Keep your networking and database software patched and updated.
This goes for WAFs, next-generation firewalls and database-management systems. They won't do the best job possible unless they're up to date.
Penetration-test your websites and web apps.
This should be a routine procedure, whether you have it done by outside consultants or by an in-house red team. Web application scanners, full-scale pen-testing tools like Metasploit or SQL-specific tools like SQLMap should all yield useful results.
