注*其实MVC的方法有点复杂，到这里我们可以看出，JSON劫持漏洞是要以在受豁者的浏览器上执行JSON返回对象为前提的，其实Google使用了一种更加聪明的方法，通过添加“死循环”命令，防止黑客运行这段脚本，可参见这篇文章： 为什么谷歌的JSON响应以while(1);开头？ 

检查首部（Http-Header）怎么样？

一些人可能会有疑问：“为什么不在响应一个GET请求之前，用一个特殊的首部对JSON服务进行检查？就像X-Requested- With:XMLHttpRequest或者Content-Type:application/json”。我认为这可能是个过渡，因为大多数的客户端 库会发送一种或两种Header，但是浏览器响应脚本标签的GET请求不这样。

问题是：在过去某个时候，用户可能会发出合法的JSON GET请求，在这种情况下，这个漏洞可能会隐藏在用户浏览器的正常请求之间。也是在此种情况下，当浏览器发出GET请求，这种请求可能会缓存在浏览器和代 理服务器的缓冲区。我们可以尝试着设置No-Cache header，这样，我们信任浏览器和所有的代理服务器能够正确地实现高速缓存并且信任用户也不会被意外地覆盖。

当然，如果我们用SSL提供JSON文本，这个特定的缓存问题将会很容易被解决。

注*这里我们可以看到防范方法这三：不要cache你的ajax请求，不过目前似乎所有的js库默认都是不cache的。

真正的问题在哪里？

Mozilla Developer Center发表的一篇文章中写道：对象和数组初始化设定项在赋值时不应该调用setters方法。这一点我同意。尽管有评论认为：也许浏览器真的不应该执行脚本。

但是在一天结束的时候，分派责任并不能使你的网站更加安全。这些浏览器的怪癖毛病将会时不时地出现。我们作为网站的开发者需要解决这些问题。 Chrome2.0.172.31和Firefox3.0.11也有这个软肋。IE8没有这个问题，因为它不支持这种方法，我也没有在IE7或者IE6中 试验过。

在我看来，在当前的客户端库下，安全访问JSON的默认方式应该是POST，并且我们应该选择GET,而不是其他方式。您觉得呢？您所了解的其他平台是怎么解决这个问题的呢？我很想听听大家的想法。

原文  haacked.com