Penetration Testing mailing list archives
Re: [WEB SECURITY] Response Header Name Injection Attack
From: romain <r () fuckthespam com>
Date: Sun, 15 Mar 2009 15:23:46 -0400
-----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-----
Current thread:
- Response Header Name Injection Attack Cyrill Brunschwiler (Mar 15)
- Re: [WEB SECURITY] Response Header Name Injection Attack romain (Mar 15)