[prev in list] [next in list] [prev in thread] [next in thread] 

List:       webappsec
Subject:    Re: [WEB SECURITY] Response Header Name Injection Attack
From:       romain <r () fuckthespam ! com>
Date:       2009-03-15 19:23:46
Message-ID: 49BD55C2.4080702 () fuckthespam ! com
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Okay, you got me curious now. Is this supposed the be a new attack that
you found?
Just to let you know, the header injection is quite a common attack...
and I don't see, at least now, how this is different.

Thanks for further explanation.

- --Romain
http://rgaucher.info

Cyrill Brunschwiler wrote:
> #############################################################
> #
> # COMPASS SECURITY ADVISORY http://www.csnc.ch/
> #
> #############################################################
> #
> # Product: Generic Web Application Vulnerability
> # Subject: Response Header Name Injection Attack
> # Effect:  Remotely exploitable, Browser Hijacking
> # Author:  Cyrill Brunschwiler (cyrill.brunschwiler@csnc.ch)
> # Date:    March, 15th 2009
> #
> #############################################################
> 
> Introduction:
> -------------
> Numerous web application injection attacks have been known for 
> some time now. Injection attacks share the common issue that 
> attackers may cause a system to turn data into a valid command
> or markup language. Thus an attacker can escape the data
> context and enter the surrounding framework such as HTML,
> JavaScript, SQL, LDAP and so on.
> 
> Cyrill Brunschwiler of Compass Security, a Swiss Company
> specialized in Penetration Testing and Security Reviews,
> discovered a special form of browser redirection or browser 
> hijacking. Victims may be redirected or hijacked to arbitrary
> web sites in case a web application takes unfiltered user
> input for a response header name. We call this Response Header
> Name Injection.
> 
> The issue is clearly distinguishable from the known Response
> Splitting attack since the Response Header Name Injection 
> attack vector does not include any control characters such as
> carriage returns or line feeds (CR/LF)
> 
> Details:
> --------
> Assume the following code snippet in a web application:
> -
> headerName = request.getParameter("param");
> response.addHeader(headerName, "x");
> 
> The application is installed at http://www.csnc.ch/. Following
> that, an attacker could call the application as follows:
> -
> http://www.csnc.ch/?param=Refresh: 0;http://www.example.com/#
> 
> The application will return the below header which will cause
> the browser to load the referenced URL (www.example.com) after
> the defined timeout (0 seconds).
> -
> HTTP/1.1 200 OK
> Refresh: 0;http://www.example.com/#: x
> ...
> 
> Astonishingly, the refresh header is not an official header
> such as those described in RFC2616. However most web browser
> support the header in a flexible manner. The following forms
> are accepted by common web browsers:
> -
> Refresh: 0; http://www.example.com/
> Refresh: 0; url=http://www.example.com/
> 
> Furthermore, the Set-Cookie header could be used to fixate
> session cookies in applications which suffer session fixation
> but accept cookies only. An attack would then look like:
> -
> http://www.csnc.ch/?param=Set-Cookie: id=123;
> 
> For a list of response headers see:
> http://en.wikipedia.org/wiki/List_of_HTTP_headers
> 
> Remediation:
> ------------
> RFC2616 defines that a field-name (header name) may be a token
> which includes any CHAR except CTLs or separators. The standard
> also makes clear that the colon is definitely a separator and
> must not be part of a header name. Therefore, vendors should
> update their server APIs to enforce this requirement and to 
> reject header names containing colons.
> 
> Excerpt of RFC2616
> -
> token          = 1*<any CHAR except CTLs or separators>
> separators     = "(" | ")" | "<" | ">" | "@"
>                | "," | ";" | ":" | "\" | <">
>                | "/" | "[" | "]" | "?" | "="
>                | "{" | "}" | SP | HT
> 
> However, as long as the frameworks do not properly implement
> the standard, developers must take care of the issue. Thus,
> applications must not take unfiltered input (well, we had
> that before, right?). Parameters that are taken for server
> names must not contain colons (:). Therefore, remove colons
> or replace colons with an appropriate representation. It is
> suggested not to use any other separator to avoid conflicts.
> 
> Known vulnerable Servers and APIs:
> ----------------------------------
> APIs delivered with the below listed servers have been
> identified to be vulnerable to Response Header Name Injection
> Attacks since these APIs allow colons in header names. It is
> very likely that there are further APIs or application servers
> which suffer this generic issue as well.
> 
> - Apache Tomcat 5.5.25
> - Apache Tomcat 6.0.18
> - Oracle WebLogic Server 9.2
> - IBM WebSphere Application Server 7.0
> - Novell Mono 2
> - Microsoft IIS 6
> 
> Known good Servers and APIs:
> ----------------------------
> - None
> 
> Note:
> -----
> Research did not bring up any information on the topic. This
> is most likely due to developers seldom setting server response
> headers to dynamic content. Nonetheless, it was spotted in the
> wild.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJvVXCPqFffxxIpwoRAi3mAKCv4id8+UYBFdczkb4IV5imLuZ8/ACgvPuu
VYsLBNvF2F3s9mqesOFttq8=
=6sdD
-----END PGP SIGNATURE-----



[prev in list] [next in list] [prev in thread] [next in thread]