Repository: ESP32Async/ESPAsyncWebServer
File: src/AsyncWebHeader.cpp
Location: Lines 6–32

Summary

A CRLF (Carriage Return Line Feed) injection vulnerability exists in the construction and output of HTTP headers within AsyncWebHeader.cpp. Unsanitized input allows attackers to inject CR (\r) or LF (\n) characters into header names or values, leading to arbitrary header or response manipulation.

Vulnerable Code

AsyncWebHeader::AsyncWebHeader(const String &data) {
  if (!data) {
    return;
  }
  int index = data.indexOf(':');
  if (index < 0) {
    return;
  }
  _name = data.substring(0, index);
  _value = data.substring(index + 2);
}

String AsyncWebHeader::toString() const {
  String str;
  if (str.reserve(_name.length() + _value.length() + 2)) {
    str.concat(_name);
    str.concat((char)0x3a);
    str.concat((char)0x20);
    str.concat(_value);
    str.concat(asyncsrv::T_rn);
  }
  // ...
  return str;
}

Details

• Input vector: The constructor processes a string containing the header, splitting at the first colon, but does not validate or sanitize the header name or value.
• Output vector: The toString() method formats and emits the header using potentially unsafe values.
• Risk: If an attacker controls the input, they can inject CR or LF characters to:
  If an attacker can control the input to AsyncWebHeader (either directly or indirectly), they could inject carriage return (\r) or line feed (\n) characters into either the header name or value. This could allow the attacker to:
  • Inject additional headers
  • Manipulate the structure of the HTTP response
  • Potentially inject an entire new HTTP response (HTTP Response Splitting)
  • Cause header confusion or other HTTP protocol attacks

Impact:

• HTTP Response Splitting: If user-supplied input is passed to AsyncWebHeader without sanitization, an attacker could perform HTTP response splitting, leading to:

  • Cross-site scripting (XSS)
  • Cache poisoning
  • Session fixation
  • Bypassing CORS or security headers

• General Protocol Violation: Invalid HTTP headers or malformed responses, potentially breaking clients or enabling additional attacks.

Example exploit:

"X-Header: value\r\nInjected-Header: injected"

Results in:

X-Header: value
Injected-Header: injected

Recommendation

Reject Unsafe Input by Throwing an Exception

The recommended mitigation is to immediately reject any header name or value containing CR (\r) or LF (\n) characters by throwing an exception.

Example Fix

static bool containsCRLF(const String &input) {
    return input.indexOf('\r') != -1 || input.indexOf('\n') != -1;
}

AsyncWebHeader::AsyncWebHeader(const String &data) {
    if (!data) {
        return;
    }
    int index = data.indexOf(':');
    if (index < 0) {
        return;
    }
    String name = data.substring(0, index);
    String value = data.substring(index + 2);
    if (containsCRLF(name) || containsCRLF(value)) {
        // Log the incident if desired
        // log_e("CRLF injection attempt detected");
        throw std::invalid_argument("Header name or value contains prohibited CR/LF characters");
    }
    _name = name;
    _value = value;
}

• This ensures that any attempt to inject CRLF sequences is blocked, and the application is made aware of the issue through exception handling.
• Logging can be added for auditing or monitoring purposes, but the exception should prevent further unsafe processing.

References

• OWASP: HTTP Response Splitting
• CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')
• CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')

Severity

High — Permits manipulation of HTTP headers and responses, which can enable a wide range of attacks.