TinyWeb CRLF Injection (CVE-2024-5193)

Technical Details

Root Cause

When TinyWeb HTTP Server processes requests that result in HTTP redirects (302 responses), the request URL path is used to construct the Location header value. Prior to version 1.99, URL-encoded CRLF sequences (%0D%0A) in the request path were URL-decoded and included directly in the response headers without sanitization.

The CRLF characters (Carriage Return \r = %0D and Line Feed \n = %0A) are HTTP header delimiters. When injected into headers, they allow attackers to terminate the current header and inject arbitrary additional headers.

Affected Code Path

1. Client sends request with CRLF in URL: GET /path%0D%0AX-Injected:evil HTTP/1.1
2. TinyWeb URL-decodes the path to: /path\r\nX-Injected:evil
3. ReturnNewLocation() creates redirect with unsanitized path
4. Response includes injected header in Location field

Attack Vector

An attacker sends an HTTP request with CRLF sequences in the URL:

GET /path%0D%0AX-Injected-Header:%20malicious-value HTTP/1.1
Host: target.example.com

When TinyWeb redirects (e.g., adding trailing slash to directory), the response contains:

HTTP/1.1 302 Moved Temporarily
Location: /path
X-Injected-Header: malicious-value/
...

Exploitation Scenarios

• HTTP Response Splitting: Inject complete HTTP responses to serve malicious content
• Header Injection: Add arbitrary headers like Set-Cookie to hijack sessions
• Log Spoofing: Inject fake log entries into access_log, agent_log, referer_log
• Cache Poisoning: Inject headers that cause proxy caches to store malicious responses
• XSS via Headers: Some browsers may execute JavaScript in certain injected headers

Exploitation Requirements

• TinyWeb version 1.98 or earlier
• Network access to the TinyWeb server
• A request path that triggers a redirect (e.g., directory without trailing slash)

Fix Applied in Version 1.99

Version 1.99 implements the StripCRLF() function that removes all CR (#13) and LF (#10) characters from strings before they are used in HTTP response headers.

StripCRLF Function (SrvMain.pas lines 881-897)

function StripCRLF(const s: AnsiString): AnsiString;
var
  i, j, len: Integer;
begin
  len := Length(s);
  SetLength(Result, len);
  j := 0;
  for i := 1 to len do
  begin
    if (s[i] <> #13) and (s[i] <> #10) then
    begin
      Inc(j);
      Result[j] := s[i];
    end;
  end;
  SetLength(Result, j);
end;

Applied in ReturnNewLocation (SrvMain.pas lines 1419-1426)

function ReturnNewLocation(const ALocation: AnsiString; d: THTTPData)
  : TAbstractHttpResponseData;
begin
  // CVE-2024-5193: Strip CRLF to prevent HTTP header injection
  // Without this, attacker could inject headers via: GET /path%0D%0AEvil:Header
  d.ResponseResponseHeader.Location := StripCRLF(ALocation);
  Result := THttpResponseErrorCode.Create(302);
end;

The fix ensures that any CRLF characters in the URL path are stripped before being included in the Location header, preventing header injection attacks.

Proof of Concept

A proof of concept demonstrating this vulnerability was published by the security researcher:

# CRLF Injection Test
curl -i "http://target:80/test%0D%0AX-Injected:%20pwned"

# Expected vulnerable response (TinyWeb <= 1.98):
HTTP/1.1 302 Moved Temporarily
Location: /test
X-Injected: pwned/
...

# Fixed response (TinyWeb >= 1.99):
HTTP/1.1 302 Moved Temporarily
Location: /testX-Injected: pwned/
...

Note: In the fixed version, CRLF characters are stripped, so the injected content becomes part of the Location value rather than a separate header.

Mitigation

Recommended: Upgrade to TinyWeb version 1.99 or later.

Workaround: If upgrade is not immediately possible:

• Place TinyWeb behind a reverse proxy that sanitizes CRLF sequences in URLs
• Use a Web Application Firewall (WAF) to block requests containing %0D or %0A
• Monitor logs for suspicious requests containing encoded CRLF sequences

Timeline

Credit

Vulnerability Discovery: Senatorhotchkiss (VulDB User)

Fix Implementation: Maxim Masiutin (current maintainer)

Other TinyWeb CVEs

See TinyWeb CGI Command Injection Security Advisory for details on the command injection vulnerability.

Vendor Response Note

According to VulDB, the original vendor (RITLABS S.R.L.) was contacted about this vulnerability but did not respond. The fix was implemented by the current open-source maintainer (Maxim Masiutin) who took over maintenance of TinyWeb in 2021.

TinyWeb is now maintained at github.com/maximmasiutin/TinyWeb where security issues can be reported and will be addressed promptly.