Why does Node.js’s HTTP parser need to be so strict?

[DemiMarie]

From reading various comments, it is clear that Node.js’s HTTP parser is as strict as it is to prevent request smuggling attacks. However, it has never been explained what the particular attacks are.

In particular, Node.js does not allow:

• Status lines or field lines that end with a bare LF, which the standard recommends be allowed.
• Whitespace after a chunk length, which RFC9112 permits (but considers obsolete).
• Invalid characters in HTTP/1.x field values, which are permitted by HAProxy and NGINX.

Which specific attacks are blocked by these measures? Is there a concrete security vulnerability in any software that is not so strict?

[Dragon0513]

Node.js’s HTTP parser implements strict measures to prevent HTTP request smuggling attacks, which exploit differences in how front-end (e.g., proxies) and back-end servers interpret HTTP requests. These attacks occur when ambiguous or malformed requests are processed differently by servers in a chain, allowing attackers to "smuggle" malicious data past security controls. Below, I outline the specific measures in Node.js’s parser, the types of request smuggling attacks they block, and examples of vulnerabilities in less strict software, drawing on relevant cases.

1. Disallowing Status/Field Lines Ending with Bare LF

• Node.js Measure: Node.js requires HTTP status and header field lines to end with CRLF (\r\n), rejecting requests with a bare LF (\n) as a line terminator, despite RFC 7230 recommending tolerance for bare LF for backward compatibility.
• Attacks Blocked: This prevents CL.TE (Content-Length to Transfer-Encoding) and TE.CL (Transfer-Encoding to Content-Length) request smuggling attacks that exploit inconsistent line termination handling.
  • In a CL.TE attack, a front-end server (e.g., a proxy) might interpret a bare LF as a valid line terminator, processing a request based on the Content-Length header, while the back-end server (e.g., Node.js) expects CRLF and processes the Transfer-Encoding: chunked header. This discrepancy allows attackers to append malicious data (e.g., a smuggled request) that the back-end interprets as a new request.
  • Example: A request like POST / HTTP/1.1\nHost: example.com\nContent-Length: 13\nTransfer-Encoding: chunked\n\n0\nSMUGGLED could be interpreted differently if the proxy accepts bare LF, forwarding the full request, while the back-end sees the chunked body ending at 0, treating SMUGGLED as a new request.
• Concrete Vulnerability in Less Strict Software:
  • Node.js CVE-2021-22960 (2021): A novel HTTP request smuggling vulnerability was discovered where a proxy accepted a bare LF to terminate the chunk size line, but Node.js required CRLF. This allowed attackers to craft a chunked body interpreted differently by the proxy and Node.js, smuggling a request. The issue was severe because three other servers exhibited similar behavior, amplifying the risk. Node.js patched this by enforcing strict CRLF parsing.
  • HAProxy Vulnerability (2021): HAProxy was found vulnerable to request smuggling because it tolerated bare LF in chunk size lines, enabling attackers to exploit discrepancies with stricter back-ends. This was patched to align with stricter parsing standards.
• Security Risk: By rejecting bare LF, Node.js ensures consistent line termination, preventing proxies or servers that tolerate LF from misinterpreting request boundaries, which could lead to cache poisoning, credential theft, or bypassing security controls.

2. Disallowing Whitespace After Chunk Length

• Node.js Measure: Node.js rejects whitespace after the chunk length in Transfer-Encoding: chunked requests, treating it as invalid, even though RFC 9112 permits it as an obsolete feature (chunk extensions).
• Attacks Blocked: This blocks TE.TE (Transfer-Encoding to Transfer-Encoding) request smuggling attacks by preventing manipulation of chunk extensions.
  • In a TE.TE attack, both front-end and back-end servers support Transfer-Encoding, but one can be tricked into ignoring it due to malformed chunk extensions (e.g., whitespace). For example, a request like POST / HTTP/1.1\nHost: example.com\nTransfer-Encoding: chunked\n\n8 SMUGGLED\n0 (with whitespace after 8) could be processed as valid by a lenient proxy but rejected or misinterpreted by Node.js, allowing smuggling.
  • The whitespace could obscure chunk boundaries, causing the front-end to process the body as one chunk while the back-end sees it differently, smuggling data like SMUGGLED as a new request.
• Concrete Vulnerability in Less Strict Software:
  • Node.js CVE-2021-22960 (2021): This vulnerability specifically involved incorrect parsing of chunk extensions, where Node.js’s parser was exploited in combination with a proxy that allowed whitespace after chunk lengths. Attackers could craft a chunked body that the proxy interpreted one way (e.g., ignoring whitespace) and Node.js another, enabling request smuggling. The fix enforced stricter chunk length parsing.
  • Apache Traffic Server (ATS) with Node.js (2022): In CVE-2022-32213, Node.js’s llhttp parser ignored chunk extensions (including whitespace), while ATS 9.0.0 processed them, leading to request smuggling. This allowed attackers to bypass access controls by smuggling requests through ATS to a Node.js back-end.
• Security Risk: Allowing whitespace after chunk lengths enables attackers to exploit parsers that handle chunk extensions differently, leading to desynchronization. Node.js’s strict rejection prevents this by enforcing a uniform interpretation of chunk boundaries.

3. Disallowing Invalid Characters in HTTP/1.x Field Values

• Node.js Measure: Node.js rejects HTTP/1.x field values containing invalid characters (e.g., non-ASCII or control characters), unlike HAProxy and NGINX, which may permit them for compatibility.
• Attacks Blocked: This prevents TE.TE and header injection request smuggling attacks by blocking malformed headers that could confuse servers.
  • In a TE.TE attack, attackers use invalid characters in headers like Transfer-Encoding to trick one server into ignoring it while another processes it. For example, Transfer-Encoding: chunked\nX: \nTransfer-Encoding: identity could be processed as chunked by a lenient proxy but ignored by Node.js, smuggling a request.
  • Header injection attacks involve injecting control characters (e.g., CRLF) in header values to split requests or smuggle new headers, like Transfer-Encoding: chunked\r\nHost: malicious.com.
• Concrete Vulnerability in Less Strict Software:
  • Node.js CVE-2022-35256 (2022): The llhttp parser in Node.js failed to correctly handle header fields not terminated with CRLF, allowing invalid characters in multi-line headers. This enabled request smuggling by exploiting proxies (e.g., HAProxy) that tolerated such characters, leading to misinterpretation of headers like Transfer-Encoding. The fix enforced strict header parsing.
  • HAProxy and NGINX Behavior: Both HAProxy and NGINX have historically been more permissive with invalid characters in field values, leading to vulnerabilities when paired with stricter back-ends. For instance, HAProxy’s tolerance for invalid characters in headers was exploited in request smuggling attacks when combined with Node.js’s stricter parser, as noted in CVE-2021-22959.
• Security Risk: Permitting invalid characters allows attackers to craft headers that exploit parser differences, enabling request smuggling or header injection. Node.js’s strict validation ensures headers conform to RFC 7230, reducing the attack surface.

Recent Cases and Broader Implications

• Node.js Security Releases (2022): The July and September 2022 releases addressed multiple request smuggling vulnerabilities (CVE-2022-32213, CVE-2022-32214, CVE-2022-32215, CVE-2022-35256), all tied to parser issues like multi-line headers, chunk extensions, and invalid characters. These fixes reinforced Node.js’s strict parsing to prevent smuggling when paired with lenient proxies like ATS or HAProxy.
• Puma Web Server: Puma’s permissive handling of invalid Transfer-Encoding values (e.g., accepting chunk instead of chunked) allowed request smuggling when paired with Apache Traffic Server, which accepted malformed headers. This highlights how less strict parsing in other software creates vulnerabilities exploitable with Node.js.
• General Trend: Research from 2021–2023 (e.g., BSides Singapore 2022) shows that novel request smuggling techniques exploit subtle deviations from HTTP standards, such as bare LF, chunk extension whitespace, or invalid characters. Servers like HAProxy, NGINX, and ATS, which prioritize compatibility, have been repeatedly implicated in vulnerabilities when paired with stricter back-ends like Node.js.

Specific Attacks and Impacts

• CL.TE and TE.CL Attacks: Exploit discrepancies in Content-Length vs. Transfer-Encoding parsing, often using bare LF or invalid characters to manipulate request boundaries. Impacts include bypassing authentication, cache poisoning, or session hijacking.
• TE.TE Attacks: Exploit variations in Transfer-Encoding handling (e.g., whitespace or invalid characters), allowing attackers to smuggle requests that evade WAFs or security policies.
• Header Injection: Invalid characters in headers can split requests or inject malicious headers, leading to XSS, session theft, or server misconfiguration.
• Real-World Impacts: Successful smuggling can lead to:
  • Cache Poisoning: Serving malicious content to users.
  • Credential Theft: Accessing user sessions or tokens.
  • Bypassing Security: Evading WAFs or access controls.
  • DoS: Overloading servers with malformed requests.

Why Node.js’s Strictness Matters

Node.js’s strict parser aligns with RFC 7230 and RFC 9112, rejecting non-compliant requests to ensure consistent interpretation across server chains. Less strict software (e.g., HAProxy, NGINX, ATS) prioritizes compatibility, tolerating deviations that attackers exploit. By enforcing CRLF, rejecting chunk extension whitespace, and validating field values, Node.js mitigates risks from ambiguous requests, especially in proxy-back-end setups.

Recommendations for Other Software

• Adopt Strict Parsing: HAProxy and NGINX should align with Node.js’s strictness, rejecting bare LF, invalid characters, and obsolete chunk extensions by default.
• Use HTTP/2 End-to-End: HTTP/2’s binary framing eliminates many smuggling vectors.
• Normalize Requests: Proxies should normalize ambiguous headers (e.g., reject duplicate Transfer-Encoding) to prevent smuggling.
• Web Application Firewalls (WAFs): Deploy WAFs with rules to detect smuggling patterns, like those offered by Imperva or ThreatX.

Conclusion

Node.js’s strict HTTP parser prevents CL.TE, TE.CL, TE.TE, and header injection request smuggling attacks by rejecting bare LF, whitespace after chunk lengths, and invalid characters in field values. These measures block exploits that rely on parser discrepancies, as seen in vulnerabilities like CVE-2021-22960, CVE-2022-35256, and issues in HAProxy, NGINX, and ATS. Less strict software amplifies risks, making Node.js’s approach a critical defense against real-world attacks like cache poisoning and credential theft.