Is json_encode Sufficient XSS Protection?

Question

I have a stdClass object in PHP, something like

$o = new stdClass;
$o->foo = $bar

The variable $bar contains an untrusted string.

Is the following PHP template code sufficient XSS protection

<script type="text/javascript">
    var o = <?php echo json_encode($o); ?>;
</script>

My initial gut reaction is that is is safe, as encoding an object as JSON will ensure any potential javascript exploits will be rendered inert by being included as JSON string property objects. Something like this

$o = new stdClass;
$o->foo = "<script type=\"text/javascript\">alert(document.cookie)</script>";
?>
<script type="text/javascript">
    var o = <?php echo json_encode($o) ?>;    
</script>    

Resulting in output like this

<script type="text/javascript">
    var o = {"foo":"<script type=\"text\/javascript\">alert(document.cookie) <\/script>"};    
</script>    

If this is known unsafe, is there's a standard, mature way of serializing a simple stdClass object to a JSON string for use in a the <script/> portion of an HTML document.

In anticipation of the first quick answer, I realize that stripping out any HTML tags, or otherwise XSS filtering each element of the JSON object would work, but I'm looking for a concise way of doing this. Similar to how this

//$eBar = addslashes($bar);
$sql = sprintf("SELECT * FROM table WHERE foo = '%s'",mysql_real_escape_string($bar));

and this

$sql = $db->select('SELECT * from table where foo = ?', $bar);

are (in most contexts) functionally equivalent, but the later is considered better, more secure code since the end programmer user doesn't need to worry about escaping schemes.

Answer 1

Seems as through the best answer to this question lies in another question.

To sum up, PHP's JSON encoder escapes all non ASCII characters, so newlines/carriage returns can't be inserted to bollacks up the Javascript string portion of the JSON property. This may not be true of other JSON encoders.

However, passing in a raw string to JSON encode can lead to the usual litany of XSS attacks, the following combination of constants is suggested.

var v= <?php echo json_encode($value, JSON_HEX_QUOT|JSON_HEX_TAG|JSON_HEX_AMP|JSON_HEX_APOS); ?>;

or ensure the variable passed to json_encode is really an object.

Answer 2

XSS is very broad and it's actually impossible to know at any time whether untrusted data you are emitting is safe.

The answer is really that it depends on the situation. json_encode does no escaping on its own whatsoever -- you're only using it for serialization purposes. The escape function you want to use would be htmlspecialchars.

However, whether or not you even want to use htmlspecialchars depends. For example, will you insert the value of o.foo using innerHTML or textContent? The latter would lead to a double-escape, but the former would insert a script. What about if you were going to use eval (in JS)?

By the way addslashes is not functionally equivalent to mysql escaping.

I wouldn't mix JavaScript and PHP in this way to begin with, but that's another story.

Answer 3

this will work ;)

...?payload=<img%20src=x%20onerror=alert(document.cookie);>

with json_encode ...

<?php echo json_encode($_GET['payload']); ?>

;)

Answer 4

What I do is to evaluate the json object before assuming its safe. I think the method is evalJSON(true) in prototype and jquery has a similar implementation. I don't know much about xss standards with JSON but this helps me

Answer 5

As other answers have said; json_encode is not built for anti-xss protections. Unless you specifically encode the unsafe string (or sanitize properly) you're going to have a potential issue.

Furthermore, once that string is extracted from the JSON object, it is still potentially hazardous if injected into the page at any point. For example:

<?php $a->foo = "<script>alert(1)</script>"; ?>
var v = <?php echo json_encode($a); ?>

isn't likely to execute (although you can't be certain). But if you were to do:

$('#some-element').html(v.foo);

you would absolutely encounter a vulnerability.