Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63218
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <505C5625.7090700@hoa-project.net>
References: <505C4A06.6040304@hoa-project.net>
	<CAH-PCH5BAb8v_OWhO1pv7bBUsxvun3=0u-YjO27ktWfU4ssJZQ@mail.gmail.com>
	<505C5625.7090700@hoa-project.net>
Date: Fri, 21 Sep 2012 14:08:06 +0200
Message-ID: <CAH-PCH7ohkh53iS0HEh6u+EsC0M+u_di8YDZCafV1rHuA1noww@mail.gmail.com>
To: ivan.enderlin@hoa-project.net
Cc: internals@lists.php.net, laruence@php.net
Content-Type: multipart/alternative; boundary=f46d042de69fb6605704ca3517c4
Subject: Re: [PHP-DEV] POST, content-type: application/json and json_decode
From: tyra3l@gmail.com (Ferenc Kovacs)

--f46d042de69fb6605704ca3517c4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 woul=
d
>> 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=3D60655 <https://bugs.php.net/bug.php?id=3D60655>. 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=3DCVE-2011-4885 and for the
theory of the attack here
http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003.pdf

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--f46d042de69fb6605704ca3517c4--