http response splitting vulnerability
khansen at charityweb.net
Thu Aug 6 06:18:44 MSD 2009
I tried the application level first. Didn't work, but your advice had me
go back and look again. That did it! I fixed it there.
> Seems like you might need to solve this at the web application level,
> unless the response splitting was done by nginx/backend server itself?
> On Wed, Aug 5, 2009 at 10:58 AM, Kurt Hansen <khansen at charityweb.net
> <mailto:khansen at charityweb.net>> wrote:
> Our server is checked each day by McAffee to see if there are any
> It found one that I'm not sure what to do. Here's the description
> from McAfee:
> HTTP response splitting is the ability for an attacker to modify
> the headers of an HTTP response due to lack of input validation on
> requests that are sent to the application server.
> A vulnerable web application or web server allows the user to
> insert a Carriage Return (%0D or \r) and/or a Line Feed (%0A or
> \n) into the headers of an HTTP response. This is usually done by
> sending modified requests to the web application and the web
> application responding with the user supplied data being inserted
> into a header. The attacker then constructs and attack using a
> CRLF (Carriage Return-Line Feed) attack that has the client
> interpret the data as 2 separate responses.
> <<END QUOTE
> Here's the proposed solution:
> All input that is sent to a web application should not be trusted
> and should be assumed malicious. Characters such as Carriage
> Return (CR) and Line Feed (LF) should be removed from all requests
> before being interpreted by the web application server.
> An attacker can also use encoded Carriage Returns and Line Feeds
> to exploit the web server, and user-specified Carriage Returns and
> Line Feeds serve no business purpose on a web server. Filter the
> following characters from all user supplied input:
> <<END QUOTE
> How can I implement this fix in nginx? I'm using it as a reverse
> Take care,
> Kurt Hansen
More information about the nginx