Offensive Security Researcher & Quantum Cryptography Analyst

generic_chunked: Checking for Vulnerabilities in Chunked Transfer Encoding

Abdul Wahab Junaid
generic_chunked: Checks for vulnerabilities in chunked encoding

Chunked transfer encoding is one of those HTTP/1.1 features that quietly runs behind almost every modern web server, and when it’s implemented incorrectly, it becomes the root cause of some genuinely serious vulnerability classes — HTTP request smuggling, buffer overflows, and denial-of-service conditions among them. generic_chunked is the test module I associate with checking exactly this: whether a target server or intermediary handles chunked encoding safely.

What Is generic_chunked?

generic_chunked refers to a vulnerability check (most commonly recognized as a test category/plugin within scanners like Nikto, and as a concept tested manually with tools like curl and Burp Suite) that probes how a web server parses HTTP chunked transfer-encoded request and response bodies. The goal is to identify servers vulnerable to historic and recurring issues tied to chunked encoding parsing — including the class of bugs that led to CVE-2002-0392 (Apache chunked encoding memory disclosure/DoS) and the modern wave of HTTP request smuggling vulnerabilities caused by inconsistent chunked-encoding parsing between a front-end proxy and a back-end server.

How Chunked Encoding Works (and Why It’s Risky)

In chunked transfer encoding, instead of sending a Content-Length header, the sender breaks the body into a series of chunks, each prefixed with its size in hexadecimal:

4\r\n
Wiki\r\n
5\r\n
pedia\r\n
0\r\n
\r\n

That’s a valid chunked body spelling “Wikipedia,” terminated by a zero-length chunk. The parsing logic required to correctly interpret this — reading a hex size, reading exactly that many bytes, expecting a \r\n, repeating until a zero-size chunk — is more complex than simple Content-Length-based parsing, and that complexity is exactly where implementation bugs creep in:

How the Check Works

A generic_chunked style test typically works by sending a series of deliberately malformed chunked requests and observing the server’s behavior:

  1. Baseline valid chunked request — confirm the server correctly handles standard chunked encoding at all.
  2. Oversized chunk-size field — send a chunk-size header far larger than the actual data provided, checking whether the server hangs, errors gracefully, or crashes.
  3. Non-hex characters in the chunk-size field — malformed chunk-size values to see if input validation is missing.
  4. Missing terminating chunk — omit the final 0\r\n\r\n and observe connection-handling behavior (hang vs timeout vs graceful close).
  5. Conflicting Content-Length and Transfer-Encoding headers — sending both headers with different framing information is the classic smuggling probe, since RFC-compliant behavior requires Transfer-Encoding to take precedence, but not every implementation follows this correctly.

Running the Check via Nikto

If you’re using Nikto, chunked-encoding-related checks are included as part of its broader test database and are triggered automatically during a standard scan; you can narrow a scan toward misconfiguration/protocol-level tests with:

nikto -h http://192.168.56.101 -Tuning 2

Manual Testing with curl

To manually test a baseline valid chunked request:

curl -v -X POST http://192.168.56.101/ \
  -H "Transfer-Encoding: chunked" \
  --data-binary $'4\r\nWiki\r\n5\r\npedia\r\n0\r\n\r\n'

To test a conflicting Content-Length/Transfer-Encoding combination (a classic request smuggling probe), you’ll generally need raw socket control since curl normalizes headers — this is where Burp Suite’s Repeater (with “Update Content-Length” disabled) or a raw script using Python’s socket module becomes necessary:

import socket

payload = (
    "POST / HT TP/1.1\r\n"
    "Host: 192.168.56.101\r\n"
    "Content-Length: 6\r\n"
    "Transfer-Encoding: chunked\r\n"
    "\r\n"
    "0\r\n\r\n"
    "G"
)

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("192.168.56.101", 80))
s.sendall(payload.encode())
print(s.recv(4096).decode(errors="replace"))
s.close()

This kind of test needs to be run against the exact front-end/back-end topology you’re authorized to assess, since request smuggling is fundamentally about disagreement between two systems, not a single server’s behavior in isolation.

Real-World Use Case (Authorized Lab Only)

In a lab setup with an Nginx reverse proxy in front of an older Apache backend, I sent a request containing both a Content-Length and a Transfer-Encoding: chunked header with intentionally conflicting framing. The front-end Nginx proxy forwarded the request based on Content-Length, while the Apache backend parsed it based on Transfer-Encoding, causing the two systems to disagree about where the request ended — allowing a smuggled second request to be interpreted by the backend as belonging to the next legitimate user’s connection. This is a classic, well-documented HTTP request smuggling pattern (CL.TE), reproduced strictly in an isolated authorized lab to demonstrate the impact for a report.

Workflow Integration

Troubleshooting & Common Mistakes

Best Practices

FAQ

Is generic_chunked a specific standalone tool? It’s best understood as a test category/technique — implemented as a check within scanners like Nikto and manually reproducible with raw HTTP crafting — rather than a single standalone executable.

Does this only affect old servers? No — while the original 2002-era Apache chunked encoding bug is long patched, the broader class of chunked-encoding parsing inconsistencies (especially request smuggling between proxies and backends) remains a live, actively researched vulnerability area today.

Can this cause a denial of service? Yes — some malformed chunked payloads can cause resource exhaustion or hangs in vulnerable implementations, which is why testing should always be scoped and authorized carefully.

Summary

Chunked transfer encoding’s complexity, relative to simple Content-Length framing, makes it a recurring source of parsing bugs — from historic buffer overflows to today’s HTTP request smuggling attacks between proxies and backend servers. Understanding how generic_chunked-style checks work, and being able to reproduce them manually with raw sockets or tools like Burp Suite’s smuggling extension, is essential for accurately assessing modern multi-tier web architectures.

References

Exit mobile version