Edit report at https://bugs.php.net/bug.php?id=65257&edit=1
ID: 65257 Comment by: phpmpan at mpan dot pl Reported by: masakielastic at gmail dot com Summary: new function for preventing XSS attack Status: Open Type: Feature/Change Request Package: JSON related PHP Version: 5.5.0 Block user comment: N Private report: N New Comment: When I see this proposal, voices in my head start singing "welcome back, magic_quotes" ;). I would consider putting a proper warning in the documentation to be a much more appropiate solution. Now this issue may be simply overlooked, because such parameters like $options are often considered "optional things I'll probably not need now". However, if the issue is described and someone still doesn't see the risk or can't deal with it properly, then the author will create many security holes in the application anyway. Also, if a new function is added, please don't use word "secure" in its name. Such names make more harm that good, when inexperienced coders come across them. Name it, for example, "json_js_encode" and describe it as one that emits a valid ECMAScript code that limits (not stops!) XSS attacks. Previous Comments: ------------------------------------------------------------------------ [2013-08-04 12:14:39] j dot tvr at centrum dot cz Could you provide an example of XSS injection caused by json_encode which could not be resolved by proper usage of htmlspecialchars? Side note: JSON is not subset of JavaScript due to U+2028 and U+2029 (http://timelessrepo.com/json-isnt-a-javascript-subset). Although json_encode without JSON_UNESCAPED_UNICODE flag does generate a JS subset. ------------------------------------------------------------------------ [2013-07-30 02:13:51] yohg...@php.net JSON is plain javascript code and pasting it to javascript code part in HTML is valid. Therefore, ",',<,>,\ and others may allow injections. PHP would better support all RFC4627 escape and set the most secure method as the default, IMHO. ------------------------------------------------------------------------ [2013-07-27 11:13:11] ni...@php.net I don't really understand this issue (and also why the JSON_HEX_* flags were necessary in the first place). If you are going to embed JSON into HTML, why not use the usual htmlspecialchars function? Why do we have to implement HTML escaping functionality inside json_encode? Both things seem very distinct to me. ------------------------------------------------------------------------ [2013-07-26 22:31:00] yohg...@php.net Alternatively, we may introduce JSON_UNICODE and make it default. Unicode escape is defined in FRC4627. e.g. \uD834\uDD1E This would be most secure way of escaping unicode. The disadvantage is increased data size. ------------------------------------------------------------------------ [2013-07-26 21:23:07] yohg...@php.net Sounds good to me. Anyone else have comments? ------------------------------------------------------------------------ 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=65257 -- Edit this bug report at https://bugs.php.net/bug.php?id=65257&edit=1
