Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:26211 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 92756 invoked by uid 1010); 23 Oct 2006 23:12:11 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 92739 invoked from network); 23 Oct 2006 23:12:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Oct 2006 23:12:11 -0000 Authentication-Results: pb1.pair.com smtp.mail=penguin@php.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=penguin@php.net; sender-id=unknown Received-SPF: error (pb1.pair.com: domain php.net from 85.235.23.12 cause and error) X-PHP-List-Original-Sender: penguin@php.net X-Host-Fingerprint: 85.235.23.12 kbhn-vbrg-sr0-vl207-012.perspektivbredband.net Linux 2.4/2.6 Received: from [85.235.23.12] ([85.235.23.12:52599] helo=mail.ter.dk) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 96/48-39788-74C4D354 for ; Mon, 23 Oct 2006 19:12:09 -0400 Received: from workpenguin (workpenguin [192.168.1.32]) by mail.ter.dk (Kaffemaskine) with SMTP id 884C38A434D; Tue, 24 Oct 2006 01:14:06 +0200 (CEST) To: rasmus@lerdorf.com (Rasmus Lerdorf) Cc: PHP internals Date: Tue, 24 Oct 2006 01:11:25 +0200 Message-ID: <9hiqj2dupeap8a98pfisf637joqhobd8jq@4ax.com> References: <453C81F8.7080606@hardened-php.net> <453CFE17.5020809@lerdorf.com> In-Reply-To: <453CFE17.5020809@lerdorf.com> X-Mailer: Forte Agent 1.91/32.564 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] PHP 5.2.0 release with "broken" input filters From: penguin@php.net (Peter Brodersen) On Mon, 23 Oct 2006 10:38:31 -0700, in php.internals rasmus@lerdorf.com (Rasmus Lerdorf) wrote: >I had left out SERVER filtering in the initial version for much the same= =20 >reasoning, but it turns out that a good chunk of holes were due to the=20 >fact that people used $_SERVER['REQUEST_URI'] unfiltered. Trying to=20 >teach people which SERVER vars are safe and which aren't isn't a fun=20 >task and the whole point of the filter extension is to take away the=20 >guessing game. More well-known, the same goes for the HTTP headers populated in _SERVER as well, even though some might be less obvious than other. HTTP_HOST could be tainted as well in some cases where a DNS entry and ServerAlias of *.example.com exists. An attacker could trick a user into visiting www.%22%3EXSS.example.com which at least IE6 would accept as a valid URL. --=20 - Peter Brodersen