Remove unparsable cruft from JSON responses

[p-m-j]

JSON responses from the Umbraco back office are returned with the following characters prefixing payloads )]}',

The tl;dr for why is because it is recommended in the angular.js documentation https://docs.angularjs.org/api/ng/service/$http#json-vulnerability-protection

The long version requires some history.

Before CORS was commonplace it was still desirable to load JSON from different origins but the same-origin policy would prevent cross domain requests except when loading external script files.

A technique was invented where one would pass the name of a callback method in a querystring whilst loading a JSON resource with a script element, the server would respond with javascript which would invoke the callback passing a payload.

<script>
function myCallback(response) {
    alert(response);
}
</script>
<script src="another-origin.com/some-json-resource?callback=myCallback" />

<! -- Server responds -->

myCallback({"some":"payload"});

OK great but what does this have to do with the issue at hand?

A vulnerability was found where one could trick a user into loading a page which would redefine built-in objects
for example Array and then load a JSON resource which wasn't intended for use with JSONP, the browser would load the resource passing along any authentication cookies and potentially leak private data when passing it to the constructor of the redefined array object.

As a quick fix it was suggested that developers should use the previously mentioned unparsable cruft to make ensure browsers refused to evaluate the response whilst adding to Ajax handling code to strip the characters for legitimate uses.

The ECMAScript specification has been updated to prevent redefining important built-ins and all modern browsers are safe from this historical attack vector ergo there is no longer a need to include the unparsable cruft.

[p-m-j]

Further reading for those interested

https://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/
https://johnresig.com/blog/re-securing-json/

[mattbrailsford]

Nice history lesson @p-m-j I vaguely knew the gruff was for security purposes but wasn't entirely sure why, and didn't know it had been fixed, so nice background 👍

My thought though is whether it's really worth doing right now given the back office rework stuff going on that most likely not going to have this anyway? Is there an immediate improvement to be had by doing this?

Also, I vaguely remember in some package at some point that I had to work around this for a specific use case so I do wonder if removing this might break some things.

[p-m-j]

Just a nice easy win for v10, benefit is anyone writing a c# api client doesn't have to remove the cruft.
Frontend will continue to work regardless as angular http client will work with or without the cruft in the response.

[mattbrailsford]

I guess the next question is how many people are writing c# api clients that need to connect to these API's? vs are there any currently active packages that have already implemented code to work around this?

[p-m-j]

Absolutely no idea, but I see no reason to continue adding the cruft indefinitely. It shouldn't be hard to update any clients to remove cruft when present and carry on when it's missing which you'd hope is what's already done.

[p-m-j]

WRT back office front end updates, there’s no ETA on changes and as yet we don’t know if it will require any changes to API’s so seems unnecessary to wait for a little spring cleaning.

[luis-cortina]

Related #11663
I would support removing this!!!

[p-m-j]

We will make this change in v10, afaik it's a one liner to resolve.