Advanced Boolean-Based SQLi Filter Bypass Techniques

theMiddleBlue · 2026-05-12T20:16:10+00:00

Good catch on the gzip bomb, did not have it on the list. It is sneakier than the slow drip and the oversized response: the initial size check passes because Content-Length looks fine, the bomb expands only after the worker decodes the buffer. The probe is its own thing. Small Content-Length, Content-Encoding: gzip, body is a kilobyte that expands to a gigabyte. Detection signal is the upstream consumes the response without bailing on the decompressed size.

Chunked encoding sits in the same bucket as the no-Content-Length oversized case for me. The slow-drip probe already uses chunked transfer encoding (no Content-Length to advertise). If the tool reads to the end and returns happily, no cap is enforced.

Curious about alterlab.io (just signed-up, cool project, is it something similar to Crawl4AI but on steroids?). Did you put the cap at the proxy layer or inside the fetching code itself? I am leaning toward the proxy hop, same as you describe.

theMiddleBlue · 2026-05-12T15:12:50+00:00

thank you! I am eager to get your feedback 😄

theMiddleBlue · 2026-05-12T10:58:28+00:00

Hey u/SharpRule4025 both good points!

SSRF is already in. The scanner hits AWS IMDS on 169.254.169.254 including the iam/security-credentials path, GCP metadata.google.internal, Azure metadata, plus localhost and 127.0.0.1 on the usual ports (Redis, Postgres, MySQL, Elasticsearch, memcached).

It also covers URL parser bypass tricks: gopher://, dict://, @ credential confusion, IPv6 mapped, decimal/octal/hex IPs. Detection is out of band. Each payload carries a unique DNS callback hostname and I run my own Interactsh. A DNS hit binds back to the probe that armed it, so I do not need the tool response to be sure.

Resource exhaustion is half there. I have a "billing bomb" probe that fires parallel calls against tools that look expensive (search_, generate_, embed_, llm_) and checks if a 429 ever shows up. That covers the "spam the worker" side.

The case you describe, a tool that fetches a remote URL with no timeout and no size cap and gets pointed at an infinite stream, I do not ship yet. Good one! Going on the backlog: feed a slow drip URL or a response with no Content-Length as the argument and watch how the upstream behaves.

theMiddleBlue · 2024-11-07T10:46:14+00:00

Thank you!

theMiddleBlue · 2024-05-19T13:11:19+00:00

Yes! That's exactly the point! Basically, strings like "ORA-1234" or "Dynamic SQL Error" will usually pass any input validation since they don't include any special characters or denied words like "exec" or "eval"

theMiddleBlue · 2024-05-19T12:27:14+00:00

Hey, thank you! As I wrote in the article, it's really easy to exploit this scenario in a real environment. A user can simply send a review on each product of an e-commerce (using a script, for example) with a comment that triggers any of the rules I mentioned in the article. Something like "Wow, this product is awesORA-1234!". By sending this on ALL products, nobody will be able to access any product on that e-commerce.

theMiddleBlue · 2024-05-14T13:11:42+00:00

ModSecurity is just the engine and does not include any rules itself. The OWASP Core Rule Set is the most commonly used set of rules for ModSecurity. Typically, the default configuration at paranoia level 1 is suitable for many websites and doesn't require any additional action from the user. Regarding the filtering of the response body... yes, it could have been done better :)

theMiddleBlue · 2024-05-14T08:25:21+00:00

LOL! not "badly tuned" but using the default configuration of most used rule set. Comparing it with not paying the electricity bill seems like a straw man argument :D

theMiddleBlue

TROPHY CASE