POST, content-type: application/json and json_decode View as Markdown

Hi,
Hi,

This may lead to a BC break.
If the post body contains a variable with the same name in the JSON, the
$_POST will be confusing.
Can you give me an example please?

--
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 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. What is the state of this bug?

I don't understand very well the hash collision problem. Any links?

--
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 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.
Hi !

Reading and parsing post data function is defined as a SAPI struct
function pointer.
You should look at sapi_module_struct definition
(http://lxr.php.net/xref/PHP_5_4/main/SAPI.h#251).

When a request comes in, sapi_activate() is called. It then calls
sapi_read_post_data() http://lxr.php.net/xref/PHP_5_4/main/SAPI.c#459
that itself invokes handlers.
Default handlers are defined here :
http://lxr.php.net/xref/PHP_5_4/main/php_content_types.c#29 and for
POST, by default, sapi_read_standard_form_data() is called (defined
here http://lxr.php.net/xref/PHP_5_4/main/SAPI.c#253)
This function is in fact just a bridge, it tells PHP to call
sapi.read_post() which is a function pointer defined by each SAPI.
Finally, later on, sapi.default_post_reader() is called (again, a
function pointer defined by each SAPI)

I agree it's not a very trivial part though :p
No it's clear.
Thanks for clarifying this!

--
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 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.
Hi !

Reading and parsing post data function is defined as a SAPI struct
function pointer.
You should look at sapi_module_struct definition
(http://lxr.php.net/xref/PHP_5_4/main/SAPI.h#251).

When a request comes in, sapi_activate() is called. It then calls
sapi_read_post_data() http://lxr.php.net/xref/PHP_5_4/main/SAPI.c#459
that itself invokes handlers.
Default handlers are defined here :
http://lxr.php.net/xref/PHP_5_4/main/php_content_types.c#29 and for
POST, by default, sapi_read_standard_form_data() is called (defined
here http://lxr.php.net/xref/PHP_5_4/main/SAPI.c#253)
This function is in fact just a bridge, it tells PHP to call
sapi.read_post() which is a function pointer defined by each SAPI.
Finally, later on, sapi.default_post_reader() is called (again, a
function pointer defined by each SAPI)
I have some questions. Julien told me in private that he didn't know,
hope other could reply.

By reading the code, I understand that each SAPI is responsible of
parsing the body of a POST request if it is
application/x-www-form-urlencoded. Am I right? In SAPI.c, I read that it
delegates this task to sapi_module.read_post by giving
SG(request_info).post_data (please, see main/SAPI.c#266).

It implies that if we would like to add the support of application/json,
then we have to do it for each SAPI? Not very nice :-/.

When I will locate the code to edit, I'm planning to use
php_json_decode_ex & co. (please, see ext/json/json.c#633), but the
hash collision risk is always present. In every case, json_decode() must
be protected again hash collision (please, see https://bugs.php.net/60655).

Thank you for your help,
Best regards.

--
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/

I think perhaps that's the wrong approach. It's valid JSON to have a
list literal at the top level as well,
Excuse my brief brain lapse. PHP arrays are fine for sequential data as
well, and you could also have any other JSON literal value in $_POST.

(Although, decoding objects to arrays would be inconvenient, I'd much
prefer to decode to objects, and doing that might be confusing
considering $_POST is usually an associative array...)

--
Andrew Faulds
http://ajf.me/

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)?
I think perhaps that's the wrong approach. It's valid JSON to have a
list literal at the top level as well, I think. Perhaps we should
introduce a new $_JSON variable or some such thing? $_BODY?
$_BODY === php://input.

--
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/