SQL Injection: Bypassing Input Filters

Hello! Welcome back to the SQL Injection module.

In our last lesson, you saw how to use SQLMap to automate the detection and exploitation of SQL injection vulnerabilities. We also touched upon its --tamper scripts, which can modify payloads to evade basic Web Application Firewalls (WAFs). However, as you advance, you'll encounter sophisticated filters and custom sanitization routines that can outsmart automated tools. In these situations, your success will depend on your ability to manually analyze the defense mechanism and craft a bespoke payload to bypass it.

This lesson is all about that manual process. We're going to dive into the art and science of writing SQL injection payloads that bypass common input filters and sanitization. This skill is a significant differentiator between a script-user and a professional penetration tester or bug bounty hunter.

1. Understanding Your Adversary: How Filters and WAFs Work

To bypass a defense, you must first understand how it operates. Web Application Firewalls (WAFs) and application-level filters are the primary defenses against SQL injection. They sit between the user and the web server, inspecting incoming requests for malicious patterns.

To get a solid foundation on what WAFs are, how they work internally, and the general categories of bypass techniques, please watch the following video.

As the video explained, most WAFs that you'll be able to bypass operate on a negative security model (blacklisting). They maintain a list of known-bad signatures (e.g., ' OR 1=1, UNION SELECT, <script>) and block any request that matches. Our goal is to craft a payload that is functionally equivalent but doesn't match any of these signatures.

2. A Systematic Approach to Bypassing Filters

Bypassing a WAF is not about throwing random payloads at it; it's a methodical process of reconnaissance and iterative payload crafting.

This process involves:

1. Finding the Filter: Start with a classic, simple payload you know will be blocked (e.g., ' UNION SELECT 1,2--). The block confirms a filter is in place.
2. Probing the Rules: Isolate what part of the payload is being blocked.
   • Try sending just '. Does it get blocked?
   • Try sending UNION. Does that get blocked?
   • Try sending a space .
   • This is a process of elimination to understand the WAF's blacklist.
3. Crafting the Bypass: Once you know the "forbidden" words or characters, you can use various techniques to build a payload that avoids them.

The following guide explains this iterative process beautifully.

3. Common SQLi Bypass Techniques

Now, let's explore the arsenal of techniques you can use in the "crafting" phase. The "Awesome-WAF" GitHub repository is an invaluable resource for this.

Let's break down the most important techniques from that resource and others, with a focus on SQL injection.

a. Keyword & Syntax Obfuscation

The goal here is to use alternatives to blacklisted keywords like SELECT, UNION, OR, and AND.

• Case Variation: This is the simplest trick. If a WAF is only looking for union, it might miss uNiOn or UNION.
  • Blocked: union select
  • Bypass: uNiOn sElEcT
• Comments: SQL comments can be inserted in the middle of keywords to break up the signature.
  • Blocked: union select
  • Bypass: union/**/select or union--comment%0Aselect
• Alternative Operators: Many SQL dialects have alternatives for common operators.
  • OR can be replaced with ||
  • AND can be replaced with &&
  • = can be replaced with LIKE or < or >
• Atypical Syntax: Use less common but valid functions that a WAF developer might not have considered.
  • Instead of substr() or substring(), you might use LPAD().
  • ... WHERE id=1 might be rewritten as ... WHERE id IN (1).

b. Whitespace Bypass

If the WAF is blocking spaces around keywords, you can use other characters that the database will interpret as whitespace.

• URL-encoded characters: %09 (tab), %0a (newline), %0d (carriage return).
• Comments: /**/ is a classic replacement for a space.
• Parentheses: In some contexts, ( and ) can replace spaces.

Blocked: SELECT user FROM users
Bypass: SELECT(user)FROM(users)

c. Encoding and Normalization

This is where you can exploit differences between how the WAF and the backend server interpret encoded data.

• URL Encoding: All payloads are URL-encoded by the browser, but you can sometimes bypass filters by double-encoding characters.
  • ' -> %27 (single encoding) -> %2527 (double encoding). A naive WAF might decode once, see %27, and let it pass. The server then decodes it again, revealing the malicious '.
• Hex Encoding: You can represent strings in hex format, which might not be on the WAF's blacklist.
  • Blocked: 'admin'
  • Bypass: 0x61646d696e
• XML/HTML Entity Encoding: If the data is being passed through an XML or HTML parser, you can use entity encoding. This is a more niche but powerful technique.

Let's watch a practical demonstration of a WAF bypass using XML encoding.

Test your understanding!

A WAF is blocking any payload containing the word SELECT. You are trying to perform a UNION-based SQL injection. Which of the following techniques would be the most likely to succeed in bypassing this specific filter?

1. ' UNION sElEcT user, pass FROM users--
2. ' UNION anD 1=1--
3. ' UNION /**/SELECT/**/ user, pass FROM users--
4. Both 1 and 3.

Show answer

4. Both 1 and 3. Case variation (sElEcT) and using comments (/**/SELECT/**/) are both direct attempts to obfuscate the SELECT keyword itself to evade a signature-based filter. Option 2 does not include the necessary SELECT statement to perform a UNION-based attack.

d. Advanced Techniques

• HTTP Parameter Pollution (HPP): If a WAF only inspects the first instance of a parameter, you can sometimes sneak a payload past it. Different server technologies concatenate or prioritize parameters differently.
  • Request: ?id=1&id=' UNION SELECT 1,2--
  • WAF sees: id=1 (Looks safe)
  • PHP (backend) sees: id=' UNION SELECT 1,2-- (Uses the last instance)
• Known Bypasses: Some WAFs have publicly known bypasses. The Awesome-WAF resource lists several for common products like ModSecurity and Imperva. These are great to review as they show real-world examples of the techniques we've discussed. (See sections on ModSecurity and Imperva in resource LINK).

Conclusion

Mastering manual bypass techniques transforms you from someone who simply runs tools to someone who can solve complex security puzzles. It requires creativity, a deep understanding of SQL, and a methodical approach to analyzing defenses.

Key Takeaways:

• Understand the Defense: WAFs and filters primarily use blacklists (signature matching). Your goal is to create a payload that is functionally valid but doesn't match a known bad signature.
• Follow a Methodology: Don't guess. Follow the probe-analyze-craft cycle. Start with a known-bad payload to get blocked, then iteratively modify it to pinpoint the exact filter rules.
• Master Your Arsenal: The most common bypass techniques involve obfuscating keywords (case, comments), finding alternatives for whitespace (encoded chars, parentheses), and using different encodings (URL, Hex) to create an "impedance mismatch" between the WAF and the backend server.
• Creativity Wins: This is a cat-and-mouse game. WAF developers create rules, and hackers find ways around them. The techniques here are a starting point; the ability to combine them and invent new variations is what defines an expert.

Next Lesson Preview:
So far, we've focused on injections where we get a response from the application, either directly (error-based, union-based) or indirectly (blind). But what if the application gives no response at all? In our final SQL injection lesson, we will cover Out-of-Band (OOB) SQL Injection, a powerful technique that forces the database server to make an external network request to a server you control, exfiltrating data even when no other channel is available.