By Eran Levy in Knowledge Base — Apr 26, 2023

Preventing SQL Injection: Is WAF Enough?

Probably not TBH

Executive Summary

SQL injection attacks remain a significant threat, and defending against them is crucial for ensuring data security and user privacy.
While Web Application Firewalls (WAFs) are commonly used to combat SQL injection attacks, they may not provide complete protection on their own.
Attackers can bypass WAFs by exploiting their rule-based nature, using techniques such as nested encodings, and incorporating JSON syntax.
A multi-layered security strategy is recommended, involving WAFs, input sanitization, prepared statements, stored procedures, and secure coding practices.

Defining the Parameters

SQL injections remain a prevalent attack vector. Protecting against them is critical to prevent data leaks, preserve user privacy, and protect the integrity of web applications. [6]

Web application firewall (WAF) systems are often considered the main line of defense again SQL injection attacks. They might even be enough to pass an audit. [2] But are they actually a sufficient line of defense?

Let's start by explaining how WAF works to prevent SQL injections, and then proceed to show cases where it might fail to do so.

How WAF defends against SQL injection

A Web Application Firewall (WAF) is designed to protect against SQL injection attacks by monitoring network traffic at the application level [1] . It inspects and blocks incoming requests for potentially malicious signatures, character sequences, or patterns indicative of an SQL injection attempt [6][1].

By monitoring and filtering HTTP GET and POST requests, WAFs can block data packets deemed malicious, identify and block known harmful SQL syntax, and parse incoming SQL syntax to assess its potential harm [4][7]. They may also add "escape" characters to SQL in order to 'de-risk' it [7].

While WAFs can offer a valuable layer of security against SQL injection attacks, their effectiveness depends on their configuration, the specific rules they employ, and their ability to recognize potential SQL injection attempts [3]. Let's look at some challenges that might arise.

When WAF waffles

There are many situations in which WAFs may fail to protect against SQL injections:

Unknown attack patterns and signatures: WAFs focus on detecting known attack patterns and signatures, which leaves room for more sophisticated or unknown attack methods to bypass their defenses [1].
Bypassing techniques: Attackers can manipulate the payload, use nested encodings, or place the malicious part of the request beyond the bytes of the request checked by the WAF, allowing them to exploit loopholes within the set rules and configurations [4].
Misconfiguration: If a WAF is not configured correctly, uses only general rules, or is not tightly tuned to the specific web application, it may not provide sufficient protection against more sophisticated or uncommon SQL injection attacks [3].
Updates and adjustments: If a WAF is not updated or adjusted regularly, changes made to the application by developers make the protection ineffective [3].
Non-network traffic data: A WAF is not able to deal with issues arising from the application's own code or data sources other than incoming network traffic, potentially leaving vulnerabilities exposed [3].
Fail open and fail close settings: Some WAFs are vulnerable to fail open and fail close settings during software/hardware failures, allowing attackers to exploit these vulnerabilities with DoS or DDoS attacks [4].
Zero-day exploits: WAFs cannot protect against zero-day exploits, where vulnerabilities are discovered and exploited by attackers before developers or system administrators are aware of the issue [4].
JSON syntax: WAFs may fail to recognize JSON-syntax in SQL injection payloads as potentially malicious, allowing attackers to bypass WAF protection [7].

Examples

Here are three examples (taken from the source below) that highlight the limitations of WAF in protecting against SQL injection attacks:

JSON Syntax Bypassing WAF[7]: Claroty researchers were able to bypass Amazon Web Services' (AWS) built-in WAF by using JSON syntax in their SQL injection attack. By prepending simple JSON syntax to the start of the SQL request, they could exfiltrate sensitive information using the SQLi vulnerability over the cloud. The same JSON-in-SQL attack was found to work against WAFs from Cloudflare, F5, Imperva, and Palo Alto Networks.
Inconsistent WAF Blocking[8]: A Reddit user tested several SQL injection payloads against a WAF and found that the WAF blocked some requests based on certain keywords while still allowing other suspicious queries. For example, /?id=1' or 1=1-- (a TRUE SQL injection) returned a 403 error, indicating that the WAF blocked the request, while /?id=1' or 1=2-- (a FALSE SQL injection) returned a 404 error, which suggests that the WAF did not block this request.
WAF Bypass with Mixed-Case Letters[1]: An attacker could circumvent case-sensitive WAF rules by sending a custom request with mixed-case letters, bypassing the rule and allowing the malicious request to reach the protected application. This demonstrates that WAFs can be bypassed by using techniques that exploit their rule-based nature.

Midway Summary: Is WAF Enough?

Based on the trusted sources we've used for this article, the prevailing opinions on WAFs as a solution for protecting against SQL injections can be summarized as follows:

WAFs are helpful but should not be considered the sole solution for protecting against SQL injections[2][5][6]. They can provide a layer of security but should be used in conjunction with other security measures like input sanitization, prepared statements, stored procedures, and proper coding practices [3][4][5].
The effectiveness of a WAF depends on its configuration, tuning, and ability to adapt to the specific application [3]. A poorly configured or outdated WAF may provide inadequate protection or a false sense of security [8].
WAFs have limitations and can be bypassed using various techniques, such as exploiting loopholes within their rules and configurations, using nested encodings, and employing JSON syntax [4][7]. This makes them insufficient as the sole security measure for web applications.
A comprehensive security approach, including defense in depth and echelonized defense principles, is recommended to better protect against SQL injection attacks [2]. This can involve a combination of WAFs, SQL firewalls, and other security systems and best practices [4].

Beyond WAF: Additional Measures to Consider

So what can you do to go beyond WAF and make sure your apps are safe from SQL injection? To ensure robust protection, engineering teams should implement a comprehensive security approach that includes a combination of WAFs and the following measures:

Input sanitization and proper escaping [2]: Implement good input sanitization and proper escaping in web application code to prevent the execution of malicious SQL code.
Prepared statements and stored procedures [3][5]: Use prepared statements and stored procedures for database requests. These techniques separate user input data from SQL instructions, reducing the risk of SQL injection.
SQL firewall [4]: Employ an SQL firewall as an additional layer of security, operating right in front of the database to block any other suspicious requests.
Secure coding practices [6]: Adopt DevSecOps and other best practices for web application development, such as using parameterized queries, sanitizing user input, and following security guidelines to avoid common vulnerabilities.
Object-relational mapping (ORM) [2]: Utilize proper ORMs like LINQ or jOOQ, which help reduce the risk of improper SQL query construction.
Web application and API protection (WAAP) [4]: Implement WAAP systems that focus on both web application and API security, providing protection beyond what a basic WAF offers.
Runtime application self-protection (RASP)[4]: Use RASP tools that protect applications during runtime by analyzing the application's behavior and identifying any malicious activity.
Intrusion detection and prevention system (IDPS)[4]: Complement WAFs with IDPS that focus on network protocols such as DNS, SMTP, RDP, SSH, etc., enhancing overall security.
Security information and event sanagement (SIEM) systems[2]: Leverage SIEM systems for monitoring events and analyzing anomalies, which can help identify potential threats and vulnerabilities.
Regular updates and patches [7]: Keep WAFs, firewalls, and other security systems updated and patched to ensure their effectiveness in protecting against SQL injection and other attacks.

Remember: as in many other cases in security engineering, no single solution should be considered the sole line of defense. Instead, a combined approach involving multiple security controls and best practices can help create a more robust and resilient security posture.