Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:13259 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16947 invoked by uid 1010); 11 Oct 2004 17:37:06 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 16573 invoked from network); 11 Oct 2004 17:36:57 -0000 Received: from unknown (HELO chatserv.de) (217.160.175.43) by pb1.pair.com with SMTP; 11 Oct 2004 17:36:57 -0000 Received: (qmail 12840 invoked by uid 1040); 11 Oct 2004 17:36:56 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by localhost with SMTP; 11 Oct 2004 17:36:56 -0000 Date: Mon, 11 Oct 2004 19:36:56 +0200 (CEST) X-X-Sender: sas@chatserv To: Christian Schneider cc: internals@lists.php.net In-Reply-To: <20041011100001.94254.qmail@pb1.pair.com> Message-ID: References: <20041011100001.94254.qmail@pb1.pair.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [PHP-DEV] HTTP Response Splitting From: sascha@schumann.cx (Sascha Schumann) Considering the sapi code where each header() call lands, the code assumes that the buffer contains exactly one HTTP response header. There are also some SAPI modules which specifically expect exactly one header per call. As such, stripping off \n.* seems correct to me. - Sascha On Mon, 11 Oct 2004, Christian Schneider wrote: > I looked through the bug database and the archive of this mailing list but > couldn't find any reference to HTTP Response Splitting. I apoligize if this > has been discussed before :-) > > Basically it means that web applications return unfiltered user-supplied data > in the HTTP header, most commonly when doing a redirect a la > header("Location: $location"); > > See http://www.sanctuminc.com/pdf/Whitepaper_HTTPResponse.pdf for more > information. > > Should we disallow, i.e. strip CRs and LFs from the string passed to header() > to fix the most common vulnerability in current applications? Another idea > would be to give a warning and discard the header but I think I prefer > silently stripping the characters. > > Are there anything we break by doing that apart from removing the possibility > to send multiple headers with one header() call which wasn't officially > supported anyway if I'm not mistaken? > > Any comments? > - Chris > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >