On 7/13/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > How can I fix thee? let me count the ways... > > * pass a chunked body always (no-body requests don't go chunked).
We tried to send C-L whenever practical because it is common for a origin server not to be able to handle chunked. It looks like the default configuration will be broken for some folks with input filters, such as origin server = Apache mod_cgi, or origin server = IIS (somebody else's comments). So previously we optimized for fool-proof operation instead of efficiency, and the administrator could tune for efficiency if they could determine that there was no issue with the back-end server handling chunked. > * validate that the C-L counted body length doesn't change. It looks like we are counting bytes after they go through input filters here, and then comparing that byte count with the specified C-L header field. That doesn't have to match since filters can change the size. (Admittedly I'm probably misunderstanding something.) > * follow RFC 2616 for C-L / T-E in the request body C-L / T-E > election logic. Can you be more specific about what exactly had to be done for RFC 2616 conformance? > * do not forward HTTP/1.0 requests as HTTP/1.1, unless the admin > configures force-proxy-request-1.1 What is the harm? The potential value is that the administrator can tell us to use chunked iin the case where there is an input filter and the origin server can handle chunked. http://svn.apache.org/viewcvs/httpd/httpd/trunk/CHANGES?rev=218978&r1=218977&r2=218978&view=diff > ============================================================================== > --- httpd/httpd/trunk/CHANGES (original) > +++ httpd/httpd/trunk/CHANGES Wed Jul 13 20:42:22 2005 > @@ -1,12 +1,19 @@ > Changes with Apache 2.1.7 > [Remove entries to the current 2.0 section below, when backported] > > + *) SECURITY: CAN-2005-2088 > + proxy: Correctly handle the Transfer-Encoding and Content-Length > + headers, discard the request Content-Length whenever T-E: chunked > + is used, always passing one of either C-L or T-E: chunked whenever > + the request includes a request body, and no longer upgrade HTTP/1.0 > + requests to the origin server as HTTP/1.1. Resolves an entire class > + of proxy HTTP Request Splitting/Spoofing attacks. [William Rowe] I'm so confused while trying to draw the line between alternate RFC-compliant philosophy fixes for actual RFC violations fixes for security issues I think CHANGES should be crystal clear on what change has a security implication.
