Re: POST, content-type: application/json and json_decode
| From: | Ivan Enderlin @ Hoa | Date: | Fri, 21 Sep 2012 12:10:16 +0000 |
| Subject: | Re: POST, content-type: application/json and json_decode | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-63219@lists.php.net to get a copy of this message | ||
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: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/On 21/09/12 13:44, Ferenc Kovacs wrote: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.On Fri, Sep 21, 2012 at 1:05 PM, Ivan Enderlin @ Hoa < ivan.enderlin@hoa-project.net> wrote: Hello,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?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 discussedabout 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.