Bug #68546 [ReO]: 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 Updated by: yohgaki@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: Just an additional comment on this. PostgreSQL even made "\0" a invalid/unacceptable character for JSONB type. http://www.postgresql.org/docs/9.4/static/datatype-json.html PHP has rules on variable names. It's good to enforce the rule to JSON data parsed by PHP's standard JSON library. IMHO. Previous Comments: ------------------------------------------------------------------------ [2015-05-28 00:55:31] cmb@php.net There are worse things possible than a fatal error if arbitrary user input is passed to inappropriate functions. Then again, it doesn't seem to be hard to check for this particular condition and to return NULL (what is the customary error return value for json_decode) and to set the error state to JSON_ERROR_CTRL_CHAR (a new constant might be more approriate), so that it can be retrieved with json_last_error. I've attached a respective patch for PHP 5 (PHP 7 would have to be catered to differently). ------------------------------------------------------------------------ [2015-05-28 00:54:08] cmb@php.net 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 ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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