在 ASP.NET MVC 1.0 中，有一个处理跨站请求伪造安全问题的新特性：
<%= Html.AntiForgeryToken() %>
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc
}
我发现每次呈现新表单时，以 html 表单生成的令牌都会不断变化。
我想知道这些令牌是如何生成的？并且当使用某些软件扫描这个站点时，它会报告另一个安全问题：会话已修复。为什么？既然token一直在变，怎么会出现这个问题呢？
还有另外一个功能，就是antiForgeryToken的“salt”，但是我真的知道这是做什么用的，即使我们不使用“salt”来生成token，token也会改变所有的时间，为什么要有这样的功能？
【问题讨论】：
标签： asp.net-mvc security csrf session-fixation
你问了一些不相关的问题：
这用于（大概）验证每个请求是否有效。所以考虑有人试图提供指向页面?x=1的链接，如果令牌也没有通过，请求将被拒绝。此外，它（可能）防止重复发布相同的项目。如果您单击“发布”两次，令牌可能会更改（每个请求），并且这种情况将通过以下方式检测到：
Session["nextToken"] = token;
WriteToken(token);
...
if( !Request["nextToken"] == Session["nextToken"] ){
...
}
// note: order in code is slightly different, you must take the token
// before regenerating it, obviously
我认为这个术语（它保护的攻击）现在被称为“CSRF”（跨站点请求伪造）。
【讨论】：
这里有很多关于 AntiForgeryToken 的信息：http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/
这是为了防止跨站请求伪造 (CSRF)。单击“保存”并在服务器上执行一些操作是非常标准的行为，即保存用户的详细信息。你怎么知道提交表单的用户是他们声称的用户？在大多数情况下，您会使用一些基于 cookie 或 windows 的身份验证。
如果攻击者引诱您访问在一个隐藏的 IFRAME 中提交完全相同表单的网站，该怎么办？您的 cookie 会完整提交，服务器不会将请求视为与合法请求有任何不同。 （正如 gmail 发现的那样：http://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/）
防伪令牌通过在每次生成页面时创建一个额外的 cookie 令牌来防止这种形式的攻击。令牌在表单和 cookie 中，如果表单和 cookie 不匹配，我们就会受到 CSRF 攻击（因为攻击者无法使用上述攻击读取防伪令牌）。
从上面的文章来看，盐有什么作用：
Salt 只是一个任意字符串。不同的盐值意味着将生成不同的防伪令牌。这意味着即使攻击者设法以某种方式获取了有效令牌，他们也无法在应用程序的其他需要不同盐值的部分重用它。
更新：令牌是如何生成的？下载source，并查看 AntiForgeryDataSerializer、AntiForgeryData 类。
【讨论】：