http response splitting vulnerability
gunblad3 at gmail.com
Wed Aug 5 07:15:20 MSD 2009
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> 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
> 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 proxy.
> Take care,
> Kurt Hansen
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx