Problems with avoiding JSON hijacking with MVC3's AntiForgeryToken, or similar token validation

This technique was pioneered by Jeremiah Grossman. This was only an issue because the returned json also contains javascript which could be included into a page via a <script> tag. Most json responses cannot be abused this way because the same-origin policy forbids javascript from fetching the results. To patch this issue Google used an unparseable cuft.

This paper summarizes a variety of reasonable defenses.

Including an unpredictable token in the URL is indeed a reasonable way to defend against the threat. (See Section 3 of the paper for mention of this.) One reasonable way to deliver it to the server is as a parameter. The token might be a copy of the session cookie, or a secret value that's known to the server and cannot be predicted by an attacker. The techniques for implementing this are probably very similar to those for defending against CSRF.

I think HTTP vs HTTPS is an orthogonal issue; I don't see any relevance here.