CVE-2015-5144

What it actually does

The vulnerability stems from improper input validation in several of Django's core validators, which use a flawed regular expression that fails to properly sanitize newline characters. This allows an attacker to inject characters like carriage return (CR) and line feed (LF) into data that is later used in an HTTP response header. This can result in an HTTP Response Splitting attack, where the attacker can inject arbitrary headers and even a custom response body, fundamentally compromising the integrity of the server's HTTP responses.

Why it matters to the business

Exploitation can lead to cross-site scripting (XSS), web cache poisoning, and session hijacking attacks against the application's users. These attacks can result in the theft of sensitive user data like session cookies, defacement of the website by injecting malicious content, or redirection of users to phishing sites. Such incidents can cause significant reputational damage, loss of user trust, and potential regulatory penalties depending on the data compromised.

How an attack unfolds

An unauthenticated remote attacker identifies an input field in a Django application that uses one of the vulnerable validators (EmailValidator, URLValidator, validate_ipv4_address, or validate_slug). The attacker submits a specially crafted string that includes a newline character followed by custom HTTP headers and a new response body. The vulnerable validator incorrectly accepts this input. When the application reflects this malicious input into an HTTP response header, such as a 'Location' header during a redirect, the newline character causes the response to be 'split.' This allows the attacker's injected headers and body to be processed by the user's browser or intermediate caches as if they were legitimate, leading to client-side attacks.

How to fix it

To remediate this vulnerability, upgrade Django to a patched version. The specific version depends on the branch you are currently using: - Users of Django 1.8.x should upgrade to version 1.8.3 or later. - Users of Django 1.7.x should upgrade to version 1.7.9 or later. - Users of Django 1.4.x should upgrade to version 1.4.21 or later. - Django 1.5.x and 1.6.x are end-of-life and no longer supported; applications using these versions should be migrated to a supported version of Django immediately.

How to confirm the fix worked

To confirm remediation, verify that the installed Django version is one of the patched versions or newer by running `python -m django --version` in the application's environment. To test for the vulnerability, you can use a web vulnerability scanner or manually submit strings containing URL-encoded newline characters (e.g., `test%0d%0aInjected-Header:foo`) to input fields handled by the affected validators. A patched system will reject or sanitize the input, preventing header injection, while a vulnerable system may reflect the injected header in the response.

Typical attack path

1. Attacker identifies a vulnerable Django application endpoint that uses a flawed validator for user input.
2. Attacker crafts a payload containing URL-encoded newline characters (%0d%0a) followed by malicious HTTP headers and/or a response body.
3. The payload is submitted to the application via a web form or API parameter.
4. The application's validator improperly validates the input, allowing the newline characters to persist.
5. The application incorporates the malicious string into an HTTP response header.
6. The server sends the malformed response, which is interpreted by the client or a proxy as two separate responses.
7. The victim's browser executes the malicious second response, leading to attacks like XSS or session cookie theft.

How to detect it

Monitor web server access logs, WAF logs, and application logs for HTTP requests containing URL-encoded newline characters (`%0d`, `%0a`) within parameters, particularly those corresponding to email addresses, URLs, IP addresses, or slugs. An alert on such patterns may indicate an exploitation attempt. Furthermore, monitoring outbound HTTP traffic for anomalies, such as responses with multiple `Content-Length` or `Content-Type` headers, or an unexpected response body, could indicate a successful attack.

• %0d
• %0a
• %0D
• %0A

What your security team should do

• Immediately identify all applications using vulnerable Django versions and prioritize upgrading them to a patched release.
• If immediate patching is not feasible, implement a temporary mitigation by using a Web Application Firewall (WAF) to block requests containing URL-encoded newline characters (`%0d`, `%0a`) in request parameters.
• Conduct a code review to identify all instances where user-supplied input is reflected in HTTP response headers and ensure proper output encoding is applied as a defense-in-depth measure.
• Update dependency scanning tools to ensure they can detect this and similar vulnerabilities in third-party libraries.