Edit report at https://bugs.php.net/bug.php?id=65257&edit=1
ID: 65257 Updated by: yohg...@php.net 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: 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. Previous Comments: ------------------------------------------------------------------------ [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? ------------------------------------------------------------------------ [2013-07-13 14:31:24] masakielastic at gmail dot com Description: ------------ Although JSON_HEX_TAG, JSON_HEX_APOS, JSON_HEX_QUOT, JSON_HEX_AMP options were added in PHP 5.3 for preventing XSS attack, a lot of people don't specify these options. https://github.com/search?l=PHP&q=json_encode&ref=advsearch&type=Code The one of PHP's goal is to provide a secure way for creating web application without CMSes and frameworks. The one of mesures for the problem is providing new function with make these options default. Adding recommend opitons as a default also make sense. function json_secure_encode($value, $options = 0, $depth = 512) { // JSON_NOTUTF8_SUBSTITUTE // an option replacing ill-formd byte sequences with substitute characters // https://bugs.php.net/bug.php?id=65082 $options |= JSON_HEX_TAG | JSON_HEX_APOS | JSON_HEX_QUOT | JSON_HEX_AMP | JSON_NOTUTF8_SUBSTITUTE; return json_secure_encode($value, $options, $depth); } A shortcut for these options may be helpful a bit. if (!defined('JSON_QUOTES')) { define('JSON_QUOTES', JSON_HEX_TAG | JSON_HEX_APOS | JSON_HEX_AMP | JSON_HEX_QUOT); } The following RFC shows various functions for less options. Escaping RFC for PHP Core https://wiki.php.net/rfc/escaper Ruby on Rails provide json_escape via ERB::Util. http://api.rubyonrails.org/classes/ERB/Util.html OWAPS shows the guidelines for XSS attack. RULE #3.1 - HTML escape JSON values in an HTML context and read the data with JSON.parse https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Shee t#RULE_.233.1_- _HTML_escape_JSON_values_in_an_HTML_context_and_read_the_data_with_JSON.parse As a sidenote, the default HTTP headers of Rails include "X-Content-Type-Options: nosniff" for IE. http://edgeguides.rubyonrails.org/security.html#default-headers https://github.com/rails/docrails/blob/master/actionpack/lib/action_dispatch/rai ltie.rb#L20=L24 The following articles describe JSON-based XSS exploitation. http://blog.watchfire.com/wfblog/2011/10/json-based-xss-exploitation.html https://superevr.com/blog/2012/exploiting-xss-in-ajax-web-applications ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=65257&edit=1
