I forgot to mention: HTTP responses that are ENTIRELY user-generated
(i.e., via "ns_write") will NOT be validated with this change.
Code which sends responses back via ns_write MUST validate its inputs
and ensure that the HTTP response it sends back is valid and conforms to
the spec. as necessary.


On 2004.07.16, Dossy <[EMAIL PROTECTED]> wrote:
> The issue being discussed is the HTTP response injection described in
> this paper:
>
>     http://www.sanctuminc.com/pdf/whitepaper_httpresponse.pdf
>
> The idea is that there may be ways for user-supplied input to go,
> unsanitized, into the HTTP response returned from the server.  This can
> be used to send a faked HTTP response as part of the pipeline for HTTP
> keep-alive connections.
>
> Briefly:
>
>     Client makes two requests on the same connection via HTTP
>     keep-alive.
>
>     The server responds with what appears to be 3 responses to the 2
>     requests.
>
>     The first and third responses are the actual responses from the
>     server, while the second response is actually data from the first
>     response, using the weakness illustrated in the paper (refer to URL
>     above), splitting the HTTP response by being able to control the
>     data placed in a HTTP response header.
>
>
> The HTTP/1.1 specification indicates that CRLF is an end-of-header
> marker EXCEPT when followed by a continuation-line.  See the paragraph
> about LWS:
>
>     http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html
>
> Therefore, at the server level, when sending back "structured" HTTP
> response headers (i.e., via "ns_returnredirect", or via "ns_set [ns_conn
> outputheaders] key value") we can implement a check where:
>
>     if there is a CRLF sequence in the value portion of the header
>     and it is not followed by either an SP or an HT
>     then
>         truncate off the CRLF and everything following it
>         and send a message to the server log at Warning level about it.
>
>
> This also raises the issue that AOLserver currently does NOT accept HTTP
> requests where header lines are split across multiple lines via
> header-continuation.  With regard to strict compliance to the spec.,
> this is a bug and should be addressed separately.
>
> I hope to have a fix and interim patch available for this by early next
> week.  Does anyone have any issues with the proposed solution above?

--
Dossy Shiobara                       mail: [EMAIL PROTECTED]
Panoptic Computer Network             web: http://www.panoptic.com/
  "He realized the fastest way to change is to laugh at your own
    folly -- then you can let go and quickly move on." (p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.

Reply via email to