http response splitting vulnerability

Ray 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?

Ray

On Wed, Aug 5, 2009 at 10:58 AM, Kurt Hansen <khansen at charityweb.net> wrote:

> Hello,
>
> Our server is checked each day by McAffee to see if there are any
> vulnerabilities.
>
> It found one that I'm not sure what to do. Here's the description from
> McAfee:
>
> >>QUOTE
> 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:
>
> >>QUOTE
> 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:
>
> %0D
> %0A
> %0D%0A
> \r
> \n
> \r\n
> <<END QUOTE
>
>
> How can I implement this fix in nginx? I'm using it as a reverse proxy.
>
> Thanks!
>
> Take care,
>
> Kurt Hansen
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20090805/da893375/attachment.html>


More information about the nginx mailing list