此链接 ( http://software-security.sans.org/developer-how-to/developer-guide-csrf ) 告诉我，从 Visual Studio 2012 开始，Microsoft 添加了内置的跨站点请求伪造 (CSRF) 保护到新的 Web 表单应用程序项目。将新的 ASP .NET Web 窗体应用程序添加到您的解决方案并查看 Site.Master 代码隐藏页面。此解决方案将对从 Site.Master 页面继承的所有内容页面应用 CSRF 保护。
Visual Studio 2012 自动生成的代码会生成一个随机 GUID，然后将 GUID 存储到一个 HttpCookie 中，然后由不同的网页使用。在每个页面上，此 GUID 都分配给 Page.ViewStateUserKey 以便 ViewStateUserKey 可以保护 CSRF 攻击。条件是应用程序必须使用 SSL。
为什么cookie不需要加密？我知道该应用程序需要有 SSL。但是在 cookie 中存储纯文本的 GUID 安全性不好，是吗？
这是减轻 CSRF 攻击的一种非常标准的方法。您在 cookie 中设置一个值并通过 POST 数据确认该值。这背后的原因是，虽然很容易将请求发布到具有任何值的任何服务器，但获取任何 cookie 并不容易。同源策略将阻止您通过 JavaScript 执行此操作，除非您与要发送到的页面位于同一域中。如果您的 cookie 没有使用 HttpOnly 设置并且目标网站上存在 XSS 漏洞，那么这可能只会出现在攻击中，在这种情况下，无论如何，所有的赌注都是关闭的。同样，同源策略将阻止您在 iframe 中加载目标表单并通过 JavaScript 访问隐藏字段。
这里的安全值来自于无法获取（或设置）另一个域上的秘密 cookie 值，该值会随用户请求自动发送到该域。同样，整个应用程序的安全性可能非常依赖于此。如果没有这些同源保护，您的 cookie 将很容易被暴露，并且您的会话将很容易被劫持。
进行 CSRF 保护的一种常见方法实际上是使用会话 ID 作为 CSRF 令牌。这是一个存储在 cookie 中的随机值，所以它工作得很好。我相信，在 ASP.NET 中这样做的问题在于，如果您没有使用会话，或者您还没有在会话中设置任何数据（例如，在用户登录之前），会话 ID 将保留改变，这是不好的。随机 GUID 的工作原理相同。
SSL 在这里基本上是不相关的。如果攻击者可以访问您的 cookie，那么他无论如何都拥有冒充您所需的一切，从而消除了对 CSRF 的需求。值得注意的是，通过 HTTPS 传递的 cookie 是加密的，因为它们是 HTTP 标头的一部分。
cookie 不需要加密（除了 SSL），因为它只需要对可能试图用 CSRF 攻击用户的第三方保密。因为浏览器不会将 cookie 发送到设置 cookie 的域之外的站点，所以服务器需要在请求中提供 cookie 来验证是用户发出请求，而不是第三方。由于第三方无法为自己的域以外的域设置 cookie，并且 cookie 不会在其域之外提交给他们，因此如果用户是 CSRF 攻击的受害者，则用户无法提交所需的 cookie。
如果您仍然感兴趣，这个问题可能有助于更详细地解释这一点： How is using Synchronizer Token Pattern to prevent CSRF safe?