Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63219
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hoa-project.net from 95.130.12.24 cause and error)
Message-ID: <505C5928.6050308@hoa-project.net>
Date: Fri, 21 Sep 2012 14:10:16 +0200
Reply-To: ivan.enderlin@hoa-project.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0a2
MIME-Version: 1.0
To: Ferenc Kovacs <tyra3l@gmail.com>
CC: internals@lists.php.net, laruence@php.net
References: <505C4A06.6040304@hoa-project.net> <CAH-PCH5BAb8v_OWhO1pv7bBUsxvun3=0u-YjO27ktWfU4ssJZQ@mail.gmail.com> <505C5625.7090700@hoa-project.net> <CAH-PCH7ohkh53iS0HEh6u+EsC0M+u_di8YDZCafV1rHuA1noww@mail.gmail.com>
In-Reply-To: <CAH-PCH7ohkh53iS0HEh6u+EsC0M+u_di8YDZCafV1rHuA1noww@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] POST, content-type: application/json and json_decode
From: ivan.enderlin@hoa-project.net ("Ivan Enderlin @ Hoa")

On 21/09/12 14:08, Ferenc Kovacs wrote:
> On Fri, Sep 21, 2012 at 1:57 PM, Ivan Enderlin @ Hoa <
> ivan.enderlin@hoa-project.net> wrote:
>
>> On 21/09/12 13:44, Ferenc Kovacs wrote:
>>
>>> On Fri, Sep 21, 2012 at 1:05 PM, Ivan Enderlin @ Hoa <
>>> ivan.enderlin@hoa-project.net> wrote:
>>>
>>>   Hello,
>>>> If PHP receives a HTTP request with the method POST and with the header
>>>> Content-Type: application/x-www-form-**encoded, then, it automatically
>>>> parses the request body to populate an array in $_POST. If the
>>>> Content-Type
>>>> is different (e.g. text/plain or application/json), the request body is
>>>> reachable by reading php://input. Well, it is ok.
>>>>
>>>> But is there any plans to consider application/json by parsing the
>>>> request
>>>> body and populate the result in $_POST (with the help of json_decode()
>>>> maybe)?
>>>>
>>>> If so, I would like to propose a patch but I don't find in the source
>>>> code
>>>> where request body is caugth and parsed (for POST). Any ideas?
>>>> Maybe a RFC would also be welcome to complete my suggestion?
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>   please watch out to not reintroduce CVE-2011-4885, afair we discussed
>>> about
>>> that json_decode also vulnerable to the hash collision, but I don't
>>> remember seeing any fix committed to json_decode.
>>> depending on how would you extract the json encoded variables, this would
>>> make possible to bypass the protection of max_input_vars limits.
>>>
>> Laruence has opened a bug with some patches: https://bugs.php.net/bug.php?
>> **id=60655 <https://bugs.php.net/bug.php?id=60655>. What is the state of
>> this bug?
>>
>> I don't understand very well the hash collision problem. Any links?
>>
>>
> you should find everything googling for the CVE id(CVE-2011-4885).
> basically it was an inefficient handling of the colliding haskeys, which
> doesn't happen frequently by accident, but a malicious attacker with a
> small crafted request was able to send a bunch of input variables which
> will all collide, and triggering that slow codepath, which results in a DOS.
> see https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4885 and for the
> theory of the attack here
> http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003.pdf
Ok thanks, got it.

Well, Laruence? :-)

-- 
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/