Full Report
Carriage Return - Line Feed (CRLF) or response splitting is a vulnerability where a newline can be added to an HTTP response in order to modify it. For instance, it can be used to change incoming headers, force save a response and much more. It's always felt like a mystery to me and how it works. So, I just read through some reports. The one linked is fairly simple: add in a %0d%0aKey:Value. The %0d%0a allows the adding of an arbitrary header. This report also has more linked reports that are interesting that are related to Twitter. This one is interesting because the CRLF injection did not work with CRLF. Instead, they had to do some funky unicode encoding with %E5%98%8A. If I had to guess, this was a server-level protection and had nothing to do with the software that Twitter built. Another pattern I noticed was this occurring with redirects. With these, a redirect from http to https sets the path of the URL to be the content of the path. Since this wasn't escaping the newlines, this led to a serious CRLF injection within the redirect. I tend to blame the server implementation for this. Anything being added into an HTTP response that contains a newline should simply be escaped - there's no reason this shouldn't be the standard. According DayZeroSec, this is also a common Nginx misconfiguration with some variables being used in locations that are unintended. Super weird bug class but CRAZY impact when discovered. Redirects and different encodings seem to do the trick in many cases.
Analysis Summary
# Vulnerability: HTTP Response Splitting (CRLF Injection)
## CVE Details
- CVE ID: N/A (The provided context describes a general vulnerability class, not a specific, assigned CVE)
- CVSS Score: N/A
- CWE: CWE-113: Improper Neutralization of CRLF sequences in HTTP Headers ('HTTP Response Splitting') (Inferred)
## Affected Systems
- Products: Various web applications, servers, and services that construct HTTP responses based on user-controllable input. Mentioned specific cases include systems utilizing Nginx with specific misconfigurations.
- Versions: Not specified, as this is a class vulnerability.
- Configurations: Occurs when user-controlled input containing Carriage Return (`%0d`) and Line Feed (`%0a`) characters is reflected directly into an HTTP response header or context without proper escaping. Misconfigurations in server software (e.g., Nginx) are specifically noted as a cause.
## Vulnerability Description
Carriage Return - Line Feed (CRLF) Injection, or Response Splitting, allows an attacker to inject arbitrary newline characters (`%0d%0a`) into an HTTP response. This injection enables the attacker to terminate existing headers and insert new, malicious headers (e.g., setting cookies, cache control, or initiating unauthorized redirects). The vulnerability is exploitable when any variable being added to an HTTP response contains unescaped newline characters. Specific instances noted include:
1. Direct injection using standard CRLF sequences (`%0d%0a`).
2. Exploitation via non-standard or Unicode encoding (e.g., `%E5%98%8A`) when standard CRLF sequences are blocked by server-side protection.
3. Application in redirect flows where user input dictates the redirect path/content, leading to the injection of new headers directly into the resulting redirect response.
## Exploitation
- Status: PoC available (via demonstrated payload examples like `%0d%0aKey:Value` for header injection).
- Complexity: Low (If standard CRLF sequences work) to Medium (If special encoding is required).
- Attack Vector: Network
## Impact
- Confidentiality: High (Can be used to poison caches or set new session cookies).
- Integrity: High (Can force unintended actions like unauthorized redirects or arbitrary header modification).
- Availability: Potential (Depending on the forced response modification).
## Remediation
### Patches
- No specific vendor patches were provided as the context covers a vulnerability class. Patches would involve updating affected vendors' software (e.g., Nginx versions if misconfiguration is the root cause) or fixing the application logic itself.
### Workarounds
1. **Input Validation/Escaping:** Implement a strict policy to escape or reject any input destined for addition to HTTP response headers that contains newline characters (`\r`, `\n`, or their encoded equivalents like `%0d` or `%0a`).
2. **Server Configuration Hardening:** Ensure server configurations (like Nginx) do not use sensitive variables in locations where they can be bypassed or misused to affect header construction.
## Detection
- Indicators of Compromise: Presence of HTTP responses containing `%0d%0a` or similar encoded newlines in unexpected locations, particularly within HTTP response headers (e.g., `Set-Cookie`, `Location`).
- Detection Methods and Tools: Web Application Firewalls (WAFs) configured to detect and block CRLF sequences in request or response streams. Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) tools targeting HTTP header manipulation.
## References
- Vendor advisories: N/A (General vulnerability class discussion)
- Relevant links - defanged: (No specific URLs provided in the context besides general mentions of reports).