Request Smuggling in Aspnet

Request smuggling exploits inconsistencies in how front-end proxies (like IIS, Nginx, or cloud load balancers) and back-end Aspnet applications parse HTTP requests, particularly around Transfer-Encoding and Content-Length headers. In Aspnet Core, the Kestrel server strictly follows RFC 7230, but front-end proxies may interpret ambiguous or malformed headers differently, allowing attackers to smuggle requests that bypass security controls.

Aspnet-specific vectors often involve middleware that processes headers before routing. For example, if an application uses app.UseForwardedHeaders() to trust X-Forwarded-For or X-Forwarded-Proto, an attacker might inject duplicate or conflicting Transfer-Encoding headers to cause the proxy to see one request while Aspnet sees two. Another pattern occurs in Aspnet Framework (non-Core) when using HttpRuntime.ProcessRequest with custom ISAPI filters that mishandle chunked encoding.

Real-world impact includes bypassing authentication: an attacker smuggles a request to /admin/deleteUser that appears as a benign /public request to the proxy but is interpreted as two requests by Aspnet, with the second carrying privileged actions. This has been observed in CVEs like CVE-2020-0609 (ASP.NET Core Denial of Service via request smuggling) and CVE-2021-26411 (HTTP.sys remote code execution, though not pure smuggling, highlights parsing risks in the HTTP stack).

middleBrick detects this by sending sequences of malformed requests with conflicting Transfer-Encoding and Content-Length headers (e.g., both present, or chunked with invalid lengths) and observing whether the Aspnet backend processes more requests than the front-end indicates. It checks for differential state changes, such as unexpected session creation or access to protected endpoints, without requiring authentication.

Detecting request smuggling in Aspnet requires observing how the application handles ambiguous HTTP parsing at the edge. middleBrick performs active black-box testing by sending crafted request sequences that exploit common smuggling techniques: CL.TE (Content-Length vs Transfer-Encoding), TE.CL, and TE.TE, focusing on headers Aspnet-specific pipelines may mishandle.

For Aspnet Core, middleBrick checks if the application uses app.UseHsts() or app.UseHttpsRedirection() in ways that could be bypassed via smuggling—for instance, if a smuggled request to HTTP port reaches Kestrel before HTTPS redirection occurs. It also tests for header injection via X-Forwarded-* when ForwardedHeadersOptions is misconfigured to trust all proxies.

In Aspnet Framework, detection targets System.Web pipeline events like BeginRequest where custom modules might read headers inconsistently. middleBrick sends requests with duplicate Transfer-Encoding headers (e.g., two Transfer-Encoding: chunked lines) and monitors for double-processing symptoms, such as two log entries for a single client request or unexpected 400/500 errors only on the second request in a sequence.

Example detection payload sent by middleBrick:

POST /api/data HTTP/1.1
Host: target.example
Content-Length: 13
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: target.example
X-Internal: true

Mitigating request smuggling in Aspnet requires aligning front-end proxy and back-end parsing behavior, primarily by eliminating ambiguous header usage and ensuring strict validation.

For Aspnet Core, the most effective fix is to disable support for ambiguous Transfer-Encoding at the server level. Since Kestrel already rejects conflicting Content-Length and Transfer-Encoding by default (returning 400), the risk often lies in front-end misconfiguration. Ensure your reverse proxy (IIS, Nginx, Azure Front Door) is configured to:

• Reject requests with both Content-Length and Transfer-Encoding headers
• Normalize headers before forwarding (e.g., strip duplicate Transfer-Encoding)
• Use proxy_set_header Transfer-Encoding "" in Nginx to prevent passing through

In code, avoid relying on headers that proxies may alter. Instead of using X-Forwarded-For for security decisions, use connection-level properties via HttpContext.Connection.RemoteIpAddress. If you must use forwarded headers, configure ForwardedHeadersOptions strictly:

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto,
    KnownNetworks = { new IPNetwork(IPAddress.Parse("10.0.0.0"), 8) }, // Only trust known proxies
    KnownProxies = { IPAddress.Parse("10.0.0.100") }
});

For Aspnet Framework, apply the June 2021 HTTP.sys cumulative update (KB5003638) which improves request parsing safety. Additionally, in web.config, enable request filtering to reject malformed headers:

Finally, use middleBrick’s continuous monitoring (Pro/Enterprise tiers) to scan for smuggling vulnerabilities on a schedule, ensuring regressions from proxy updates or Aspnet patches are caught early.