Bypassing Cloud Firewalls: Size Does Matter

Table of contents

Hey everyone 👋

This week I want to switch gears from smart contracts and dive back into something more web-app flavored: firewall bypass techniques in cloud environments. If you’ve ever tested apps behind Akamai, AWS CloudFront, or Cloudflare, you’ve probably noticed how resilient they can be against classic attacks. Rate-limiting, WAF signatures, bot protections… the whole package.

But here’s the catch: most of these protections are still “size-sensitive.” In other words, how you shape your request can determine whether it’s blocked or allowed through.

Why Size Matters

Many WAFs set thresholds for request length or body size. Too short and it looks suspicious; too long and it might be truncated or ignored. Clever attackers exploit this to sneak payloads past filtering layers.

What makes this interesting is that bypasses often don’t affect the whole app, but only specific endpoints. A typical example: the /login endpoint. It usually has stricter protections (blocking brute-force attempts or filtering payloads). With size-based evasion, you can sometimes slip through those controls and suddenly brute-force passwords on a page that looked bulletproof.

On top of that, some WAFs add a second defense mechanism: rate limiting. If you send too many requests too quickly, you’ll get blocked, even if your payloads are well-shaped. The trick? Tools like Burp Suite or Nuclei let you tune the request rate. Simply slowing down your attack to stay under the radar can be enough to bypass these protections.

Example Request

POST /login HTTP/1.1
Host: target-app.com
User-Agent: Mozilla/5.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 8450   ← 👈 Notice: body size >8KB, may bypass inspection

username=admin&password=pass123
&padding=AAA[...]AAA   ← 👈 Artificial padding to increase request size

In this example, the Content-Length is deliberately set above 8KB and the request body is inflated with dummy data (AAA[...]AAA). Some WAFs won’t fully inspect payloads past a certain size, which allows attackers to sneak through.

Practical Tips

• Identify the WAF first → Look at response headers (e.g., server: AkamaiGHost, x-cache, cf-ray, etc.) or use dig to check DNS mappings and confirm what service sits in front of the app.
• Vary request sizes systematically → 1KB, 10KB, 100KB, 1MB. Watch what breaks or slips through.
• Play with chunked transfer encoding → Splitting payloads into pieces may bypass reassembly limits.
• Test edge cases → Minimum valid request, maximum allowed request, and right around known inspection caps.
• Adjust your rate → If the WAF has per-second request controls, just throttle your tool (Burp, Nuclei, ffuf) to fly under the radar.

Wrapping Up

Firewalls in the cloud are strong, but they’re not perfect. Their need to balance security vs. performance often introduces blind spots and size-based bypasses are a classic example. For auditors, it’s a reminder: don’t just test functionality broadly, target those “sensitive” endpoints like login, signup, or password reset where controls are strictest. That’s usually where size tricks and careful throttling have the biggest payoff.

Stay sharp 🕶️
Ruben

Chapters

ERC-20s in the Wild: Why Vanilla Assumptions Breaks

Previous Issue

arrow_upward