php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #65257 new function for preventing XSS attack
Submitted: 2013-07-13 14:31 UTC Modified: 2018-07-07 22:59 UTC
Votes:6
Avg. Score:4.3 ± 1.1
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:0 (0.0%)
From: masakielastic at gmail dot com Assigned:
Status: Suspended Package: JSON related
PHP Version: 5.5.0 OS:
Private report: No CVE-ID: None
View Developer Edit
 [2013-07-13 14:31 UTC] 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

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-07-26 21:23 UTC] yohgaki@php.net 
Sounds good to me. Anyone else have comments?
 [2013-07-26 22:31 UTC] yohgaki@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-27 11:13 UTC] nikic@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-30 02:13 UTC] yohgaki@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-08-04 12:14 UTC] 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-10-03 00:02 UTC] phpmpan at mpan dot pl 
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.
 [2018-07-07 22:59 UTC] cmb@php.net
-Status: Open +Status: Suspended
 [2018-07-07 22:59 UTC] cmb@php.net 
> JSON is plain javascript code and pasting it to javascript code
> part in HTML is valid.

Wouldn't that imply, that pasting plain “javascript code” into an
“javascript code part in HTML” would be valid? …

Anyhow, this feature request is obviously controversial, and as
such clearly demands discussion on internale@, and perhaps a
follow-up RFC.  For the time being, I'm suspending this ticket.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Apr 02 15:01:30 2025 UTC