23 lines
2.2 KiB
Plaintext
23 lines
2.2 KiB
Plaintext
HTTP Response Splitting is a type of web application vulnerability that occurs when an attacker manipulates the data input into HTTP headers. This manipulation can lead to the creation of additional, unauthorized HTTP responses. The vulnerability arises when user-supplied data is not properly validated and sanitized before being included in an HTTP response header. This can potentially allow an attacker to control the contents of the HTTP response received by other users, leading to a variety of consequences such as cross-site scripting (XSS), session hijacking, cache poisonning, or malware delivery.
|
|
|
|
== Why is this an issue?
|
|
|
|
Without proper validation or sanitation, an attacker with control over a header's content could insert line return characters in it and inject arbitrary content in the HTTP response. This includes headers, their content, and the response body.
|
|
|
|
=== What is the potential impact
|
|
|
|
HTTP Response Splitting is a significant security concern due to its potential to compromise the integrity and confidentiality of web applications and their users' data. Typical exploitation scenarios include Cross-Site Scripting (XSS), phishing attacks or cache poisonning.
|
|
|
|
==== Cross-Site Scripting (XSS)
|
|
|
|
When an attacker successfully exploits an HTTP Response Splitting vulnerability, they can inject malicious scripts into the HTTP response. These scripts can be executed in the user's browser, leading to an XSS attack. This can result in unauthorized access to sensitive user data, such as login credentials or personal information.
|
|
|
|
==== Phishing Attacks
|
|
|
|
An attacker can use this vulnerability to redirect users to a malicious website that looks identical to the original one. Unaware users might provide sensitive information like usernames, passwords, or credit card details, thinking they are on a legitimate site.
|
|
|
|
==== Cache poisonning
|
|
|
|
By controlling the content and headers of the HTTP response, an attacker can force the application's hosting infrastructure to store a maliciously crafted web page in a cache. Every user that will later try to access the page or resource which cached version has been poisoned will therefore be presented with malicious content.
|
|
|
|
Such an attack can make the impact of other mentioned exploitation scenario higher. |