ViewStateUserKey作为HttpCookie存储是否安全？

Question

这个链接(http://software-security.sans.org/developer-how-to/developer-guide-csrf)告诉我，从Visual 2012开始，微软将内置的跨站点请求伪造(CSRF)保护添加到新的web窗体应用程序项目中。向您的解决方案中添加一个新的.NET Web应用程序，并查看页面后面的Site.Master代码。此解决方案将对从Site.Master页面继承的所有内容页应用CSRF保护。

Visual 2012自动生成的代码生成随机GUID，然后将GUID存储到HttpCookie中，然后由不同的网页使用该GUID。在每个页面上，这个GUID被分配给Page.ViewStateUserKey，以便ViewStateUserKey能够保护CSRF攻击。条件是应用程序必须使用SSL。

为什么cookie不需要加密？，我知道应用程序需要使用SSL。但是GUID将纯文本存储在cookie中并不是很好的安全性，对吗？

Answer 1

这是防止CSRF攻击的一个相当标准的方法。在cookie中设置一个值，并通过POST数据确认该值。这背后的原因是，虽然可以轻松地为任何具有任何值的服务器创建一个POSTed请求，但获得任何cookie并不容易。同源政策将阻止您通过JavaScript执行此操作，除非您位于与发送到的页面相同的域上。如果您的cookies不是用HttpOnly设置的，并且目标网站上存在XSS漏洞，那么可能只有在攻击中才会发生这种情况，在这种情况下，所有的投注都会被取消。同样，相同的起源策略将阻止您在iframe中加载目标表单并通过JavaScript访问隐藏字段。

此处的安全性值来自无法在另一个域上获取(或设置)秘密cookie值，该值将与用户的请求一起自动发送到该域。同样，整个应用程序的安全性可能非常依赖于此。如果没有这些相同的源保护，您的cookie将很容易被公开，您的会话将很容易实现可劫持。

实现CSRF保护的一种常见方法实际上是使用会话ID作为CSRF令牌。它是存储在cookie中的随机值，所以它工作得很好。我相信，在ASP.NET中这样做的问题是，如果您不使用会话，或者您还没有在会话中设置任何数据(例如，在用户登录之前)，会话ID将继续更改，这是不好的。随机的GUID也是一样的。

SSL在这里基本上是不相关的。如果攻击者可以访问您的cookie，那么他就拥有了所有需要模拟您的东西，从而消除了对CSRF的需求。值得注意的是，通过HTTPS传递的cookie是加密的，因为它们是HTTP头的一部分。

Answer 2

cookie不需要加密(SSL除外)，因为它只需要对试图使用CSRF攻击用户的第三方保密。因为浏览器不会将cookie发送到设置cookie的域以外的站点，所以服务器只需要向请求提供cookie，就可以验证是用户发出请求，而不是第三方。由于第三方不能为他们自己的域之外的域设置cookie，并且cookie没有提交到他们的域之外，所以如果用户是CSRF攻击的受害者，用户就不可能提交所需的cookie。

如果您仍然感兴趣，这个问题可能有助于更详细地解释这一点：如何使用同步器令牌模式来防止CSRF安全？