在GET请求中出现CSRF（Cross-Site Request Forgery）攻击的原因是，攻击者可以在他们的页面中包含以下脚本：$.get('http://vulnerable.example.com/json')。然而，由于同源策略，攻击者域中的JavaScript无法读取响应。同源策略会检查域、协议和端口是否匹配，如果不匹配，JavaScript在尝试读取响应时会遇到安全错误。例如，当尝试从另一个域中访问IFrame时，Chrome会给出以下警告 - 这正是保护JavaScript响应的机制：

Uncaught SecurityError: Failed to read the 'contentDocument' property from 'HTMLIFrameElement': blocked a frame with origin "http://evil.com" from accessing a frame with origin "http://vulnerable.example.com". Protocols, domains, and ports must match.

因此，总结起来，POST请求必须使用CSRF令牌，因为即使无法读取响应，POST请求仍然会被执行；而GET请求通常不会引起担忧，因为无法读取响应且它们是非破坏性的。曾经有关于JSON劫持的问题，但要追溯到Firefox 3才能找到受此漏洞影响的浏览器。详见Is JSON Hijacking still an issue in modern browsers?。

CSRF（跨站请求伪造）的预防对于GET请求的问题产生的原因是，如果攻击者能够接收到服务器对受害者请求的响应（响应将传输到受害者的浏览器，但不会传输给攻击者），那么攻击者有可能从CSRF的GET请求中获得利益。然而，在典型的CSRF场景中，攻击者无法访问响应，因为响应是从服务器传输到受害者的Web浏览器（而不是传输给攻击者）。通常的意图是引起某种状态变化，比如发起支付、发送电子邮件等，这通常是由客户端发起的使用PUT、POST、PATCH或DELETE等方法的HTTP请求。

“攻击者无法访问响应，因为响应是从服务器传输到受害者的Web浏览器” - 攻击者可以在页面上包含恶意JavaScript来将信息传输回攻击者，不是吗？

在纯粹的CSRF漏洞中，攻击者无法在页面上包含JavaScript。然而，如果攻击者能够利用跨站脚本攻击（与CSRF不同），那么他只需发起同步XHR（XMLHttpRequest）来执行任何他想要的GET请求，所以CSRF漏洞在这种情况下就不重要了。

根据上述内容，为了预防GET请求的CSRF，可以考虑以下解决方法：

1. 在服务器端对GET请求进行令牌验证，确保请求是合法的。这可以通过在请求中包含一个令牌，然后在服务器端验证该令牌来实现。如果令牌验证失败，服务器将拒绝执行请求。

2. 对于敏感操作，可以要求用户进行身份验证，例如要求输入密码或发送验证码。这样即使攻击者能够发起GET请求，也无法执行敏感操作。

3. 使用安全的编码实践，确保没有任何安全漏洞可以被攻击者利用。例如，避免使用动态生成的URL或未经过验证的输入来构建GET请求。

4. 定期更新和修补服务器和应用程序的漏洞，以防止攻击者利用已知的安全漏洞。

通过以上方法，可以有效预防GET请求的CSRF漏洞，保护Web应用程序的安全性。