Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57660
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.22 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: internals@lists.php.net
References: <D5EC076D-8518-4CDC-913F-5A3F3BB97367@sektioneins.de>
 <op.v83qfyebidpuyk@slws007.slhq.int>
Date: Fri, 03 Feb 2012 15:01:38 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_I=2ES=2ET=2E?=
Message-ID: <op.v83vw0bcidpuyk@slws007.slhq.int>
In-Reply-To: <op.v83qfyebidpuyk@slws007.slhq.int>
User-Agent: Opera Mail/11.61 (Win32)
Subject: Re: [PHP-DEV] The case of HTTP response splitting protection in PHP
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

On Fri, 03 Feb 2012 13:03:24 +0100, Gustavo Lopes <glopes@nebm.ist.utl.pt>  
wrote:

> On Fri, 03 Feb 2012 12:06:26 +0100, Stefan Esser  
> <stefan.esser@sektioneins.de> wrote:
>
>> [snip]
>> obviously inside PHP no one cares about reviewing security patches.
>>
>
> Perhaps then you'd want to comment on:  
> http://nebm.ist.utl.pt/~glopes/misc/bug60227.diff , which addresses the  
> NUL byte issue, although now I'm thinking that since we're in the  
> business of validating HTTP headers, we could also forbid the other  
> control characters that are forbidden by the spec (not just LF and CR).
>

I've committed a different version that also forbids \0 (since, as Stefan  
says, a NUL byte can result in the truncation of the rest of the header)  
and that accepts a CRLF:

http://svn.php.net/viewvc/php/php-src/trunk/main/SAPI.c?r1=323043&r2=323042&pathrev=323043

If you or anyone else find any problem, please report a bug; otherwise  
I'll merge to 5.3 and 5.4 once 5.4 is out of code freeze.

Thanks

-- 
Gustavo Lopes