Bug #68546 [PATCH]: json_decode() Fatal error: Cannot access property started with '\0'

Edit report at https://bugs.php.net/bug.php?id=68546&edit=1 ID: 68546 Patch added by: cmb@php.net Reported by: j dot tvr at centrum dot cz Summary: json_decode() Fatal error: Cannot access property started with '\0' Status: Re-Opened Type: Bug Package: JSON related PHP Version: 5.6.3 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: json-0 Revision: 1432774448 URL: https://bugs.php.net/patch-display.php?bug=68546&patch=json-0&revision=1432774448 Previous Comments: ------------------------------------------------------------------------ [2015-05-27 23:50:17] j dot tvr at centrum dot cz json_decode should return FALSE because the input can not be decoded to object, but MUST NOT trigger fatal error. Imagine an API which accepts arbitrary JSON from HTTP request. User should never be able to force PHP to trigger fatal error. ------------------------------------------------------------------------ [2015-05-27 22:24:31] cmb@php.net This issue is not particularly related to JSON. It is, as requinix pointed out, related to the fact, that an object property must not start with a null byte: <http://3v4l.org/oEMRC>. Presumably, this restriction is there for a good reason. Anyhow, letting json_decode() with $assoc=false accept such input would require the Zend object implementation to change (at least if the property should be accessible, what seems to be the very point). Actually, I don't consider this to be a bug in json_decode(). The (proposed) standard, RFC 7159, states: | A JSON parser MUST accept all texts that conform to the JSON | grammar. json_decode() does, AFAIK, when the $assoc parameter is false. ------------------------------------------------------------------------ [2014-12-05 03:08:30] yohgaki@php.net I'm not sure current implementation, but RFC 7259 defines "string" as http://tools.ietf.org/html/rfc7159#page-5 string = quotation-mark *char quotation-mark char = unescaped / escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 / ; t tab U+0009 %x75 4HEXDIG ) ; uXXXX U+XXXX escape = %x5C ; \ quotation-mark = %x22 ; " unescaped = %x20-21 / %x23-5B / %x5D-10FFFF Anything other than this spec should result in error. i.e. NULL It would be depended on underlying library, though. ------------------------------------------------------------------------ [2014-12-05 03:00:32] yohgaki@php.net <?php var_dump(json_decode('{"a": 1}')); var_dump(json_decode('{"1": 1}')); var_dump(json_decode('{a: 1, "a": 1}')); // invalid JSON var_dump(json_decode('{"a\u0000b: 1}')); // invalid JSON ?> http://3v4l.org/nncBo E_WARNING may be too much. Just returning NULL seems to be enough and leave users to handle errors. ------------------------------------------------------------------------ [2014-12-05 02:41:45] yohgaki@php.net http://3v4l.org/imJSu I agree that this should not result in E_ERROR. Ignoring offensive data and raise E_WARNING is nicer. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=68546 -- Edit this bug report at https://bugs.php.net/bug.php?id=68546&edit=1