This is a sample attack pattern. The pattern illustrates the layout of the Response Splitting Pattern.
Sample Attack Pattern
Information for this sample pattern obtained from: Amit Klein, Watchfire whitepaper:
Divide
And Conqure: HTTP Response Splitting, Web Cache Poisoning Attacks and Related Topics, 2005
1.
Name: Response
Splitting
2.
Type: Injection
– Subtypes: HTTP Response Manipulation
3.
AKA: N/A
4.
Description:
HTTP Response Splitting techniques provide attackers
with new attack vectors for defacing website content and end-users.
User controllable input parameters placed into HTTP response headers in the
absence of adequate data validation creates the potential for HTTP Response Splitting
attacks. HTTP Response Splitting attacks allow for both local and remote cache poisoning
which can result in arbitrary content being displayed to website visitors.
This type of attack is possible when server script code embeds user data
in HTTP response headers in the absence of any data validation.
More information:
http://www.watchfire.com/resources/HTTPResponseSplitting.pdf
5.
Attacker Intent:
To forge an HTTP Response that appears to have come
from a legitimate source. This will
result in the attacker gaining access to sensitive information which can be used
for identity theft through the interception of sensitive information or forced phishing
attacks wherein the victim unknowingly provides information to a rogue web page.
An attacker may also be able to deface a web site in
a localised per user manner through this attack by injecting information that appears
to be coming from a legitimate source.
6.
Motivation:
The primary motivation for this type of attack is financial
gain though the abuse of personal information obtained from the victims.
A secondary motivation is notoriety through the localised defacement
of a web site which could also result in reputation damage of the owner of the vulnerable
system.
7.
Exploitable Vulnerability:
The attack is made possible when user supplied input
is used in the response headers of HTTP Responses.
If the input is not checked for extra CR/LF characters, and unnecessary HTML
style <html>,<head>,<body>, etc. tags Response Splitting is possible.
8.
Follow-On Attacks
Response splitting attacks usually lead to:
a.
Cross Site Scripting
b.
Web Cache Poisoning
c.
Cross User Attacks
d.
PII Exposure attacks
e.
Browser Cache Poisoning
9.
Participants:
The Vulnerable Server – Hosts the vulnerable web page,
accepts the Request and supplies the corrupted HTTP Responses.
The Attacker – Creates and sends the poisoned request
which the server returns as a split response.
The Victim – Receives the poisoned split response and
potentially supplies sensitive information to a rogue web page.
10.
Process Diagram:
(In Progress)
11.
Dependencies and Conditions:
For an attack to be able to steal a victims information,
the TCP connection must be shared.
This is common when proxy servers are used.
This is an HTTP only attack.
The attack relies on:
•
The application using HTTP
•
The application accepting user input which is used
in the response headers
•
Several of the follow-on attacks rely on a shared
TCP connection (i.e. Proxy)
12.
Sample Attack Code:
Payload similar to the following would be sent to in
the input the vulnerable application which supposedly is being placed in the response
header by the application.
a. http://www.poorsite.com/abc.asp?Queryparameter=charset=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2019%0d%0a%0d%0a<html>Hacked!</html>
b.
If you get back page with Hacked! displayed, then application
is vulnerable to response splitting attacks.
13.
Existing Exploits:
At least one exploit has been published for this attack
pattern.
http://security.nnov.ru/Gdocument958.html
14.
Mitigation Types
Input / Output Validation and Filtering
Input / Output Encoding
15.
Recommended Mitigation:
a. Context Sensitive Encoding
For each input used in HTTP headers, it must be properly
encoded using an encoding mechanism e.g. IOSec. At a minimum strip CR and LF characters
from data embedded into HTTP response headers.
b. Perform White-list validation on input
For each input, define what is acceptable though either
a regular expression, a list of acceptable characters, domain constrains or type
casting and enforce this validation on the server side.
Example:
This can be implemented by one or more means. For example,
one can:
1.
Strip CR and LF characters from data embedded in to HTTP
response headers. For Example :
Function StripCRLFChar(strSource)
strSource=Replace(strSource,vbcr,"")
strSource=Replace(strSource,vblf,"")
strSource=Replace(strSource,vbcrlf,"")
StripCRLFChar=strSource
End Function
2.
Build a regular expression that defines an inclusions list
of acceptable character sequences. For example:
if (Regex.IsMatch(Request.Form["ZIP"], "^\d{5}-\d{4}$"))
{
// validation passed
}
else
{
// validation failed
}
3.
If the input is of a primitive type, one can cast it. For
example:
int x = Int.Parse(Request.Form(“param”))
4.
If the input can only be from a small (but varying) domain,
one can define conditional statements to validate them. For example:
if ( (Request.Form(“favColor”) == “RED”) || (Request.Form(“favColor”) == “ORANGE”)
)
{
// validation passed
}
else
{
// validation failed
}
5.
If input is URL then IOSec.AsUrl function can be used to
verify the user supplied URLs. For example
ReturnURL = IOSec.AsUrl(ReturnURL)
The functionality implemented in IOSec.AsUrl is as follows:
public static string AsUrl( string
strInput )
{
if (strInput == null)
{
return "";
}
// this pattern will represent well-constrained URLs
string AURegex = @"^(?:http|https|ftp)://[a-zA-Z0-9\.\-]+(?:\:\d{1,5})?(?:[A-Za-z0-9\.\;\:\@\&\=\+\$\,\?/]|%u[0-9A-Fa-f]{4}|%[0-9A-Fa-f]{2})*$";
if (! Regex.IsMatch(
strInput, AURegex ) )
{
throw new Exception( "Unsanitized value passed
to AsUrl" );
}
return( strInput );
}
16.
Related Patterns:
Cross Site Scripting
Cache poisoning
17.
Related Alerts, Listings
and Publications:
CVE Database:
CVE-2007-0047,
CVE-2006-6699,
CVE-2006-6697,
CVE-2006-6374,
CVE-2006-6373,
CVE-2006-5566,
CVE-2006-4505,
CVE-2006-3105,
CVE-2006-3016,
CVE-2006-0515,
CVE-2006-0207,
CVE-2005-4579,
CVE-2005-4521,
CVE-2005-3982,
CVE-2005-3791,
CVE-2005-3348,
CVE-2005-3633,
CVE-2005-3621,
CVE-2005-2065,
CVE-2005-2060,
CVE-2005-1951,
CVE-2005-1405,
CVE-2005-1180,
CVE-2005-0843,
CVE-2005-0175,
CVE-2004-2512,
CVE-2004-2208,
CVE-2004-2146,
CVE-2004-2145,
CVE-2004-2054,
CVE-2004-1584,
CVE-2004-1564,
CVE-2004-1516,
CVE-2004-1507,
CVE-2004-1470,
CVE-2004-1620,
CVE-2004-1687,
CVE-2004-1656,
CVE-2004-2055
CERT:
VU#625878
OWASP:
http://www.owasp.org/index.php/HTTP_Response_Splitting
Papers:
Watchfire HTTP Response Splitting 2005:
http://www.watchfire.com/securityzone/whitepapers.aspx