Jump to content

Do you need to use JSON.parse?


Drongo_III

Recommended Posts

Hello

 

This may seem like a silly question but if you never ask you never know...

 

Lets say I json encode a php array. When I echo out the encoded json string into a JS variable it looks something like this in the resultant markup:

var arr = ["cow - Copy (10).jpg","cow - Copy (2).jpg"];

So in this instance the string I've echoed out is equivalent to a JS array and I can use it straight away.

 

My questions:

 

1) Is it valid to do what I've done above?

2) Since I can use the array right away is there any need to JSON.parse?

3) When would you use JSON.parse?

 

Thanks,

 

Drongo

Link to comment
Share on other sites

Never, I repeat, never just dump some PHP value into a JavaScript context. This will almost inevitably end in a cross-site scripting vulnerability.

 

The best way to pass a PHP value to JavaScript is Ajax: Within your JavaScript you make an HTTP request to the PHP script, parse the JSON response with JSON.parse() and then use the data. Modern JavaScript frameworks like jQuery can do this automatically:

$.getJSON('path/to/your/script.php', function (response_data) {
	// response_data is the array from your PHP script
});
Link to comment
Share on other sites

What makes you think that they are safe?

 

JSON encoders have absolutely nothing to do with XSS protection. They create JSON documents, nothing more, nothing less. If you think that JSON itself is somehow inherently safe, you're wrong:

<?php

$json = '["</script><script>alert(123);</script>"]';

?>
<script>
	var x = <?= $json ?>;
</script>

The “</script>” within the JSON string terminates the script element and allows the user to manipulate the HTML markup.

 

Occasionally a JSON encoder does have a kind of “magic quotes” feature to help developers who aren't aware of the problem. PHP currently has it as well. But relying on that is a very, very bad idea – just like the actual “magic quotes”.

Link to comment
Share on other sites

Once again: JSON-encoding has absolutely nothing to do with XSS protection. Nothing. Zero. It's not the job of a JSON encoder to fix your XSS vulnerabilities. Any kind of protection is just an implemention detail which may change at any time.

 

Yes, PHP currently has a “magic quotes” feature in its JSON encoder (as I already said), because the core developers are well aware that PHP programmers don't really understand XSS. So you may sometimes get away with insecure code, just like you may sometimes get away with SQL injection vulnerabilities if magic_quotes_gpc is on.

 

So should we just write insecure code and rely on “magic quotes” to fix it for us? Good lord, no. As a developer, it's your job to take care of the security. Why is this so hard to understand? Why are we having this discussion over and over again?

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.