asp.net-mvc 防伪令牌盐有什么用？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1402770/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
what is the use of anti-forgery token salt?
提问by MemoryLeak
In ASP.NET MVC 1.0, there is a new feature for handling cross site request forgery security problem:
在 ASP.NET MVC 1.0 中，有一个处理跨站请求伪造安全问题的新功能：
<%= Html.AntiForgeryToken() %>
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc
}
I found the token generated in html form keep changing every time a new form is rendered.
我发现每次呈现新表单时，以 html 表单生成的令牌都会不断变化。
I want to know how these token is generated? And when use some software to scan this site, it will report another security problem: Session fixed. Why? Since the token keep changed, how can this problem come ?
我想知道这些令牌是如何生成的？并且当使用某些软件扫描该站点时，它会报告另一个安全问题：会话已修复。为什么？既然token一直在变，怎么会出现这个问题呢？
And there is another function, that is "salt" for the antiForgeryToken, but I really know what this used for, even through we don't use "salt" to generate the token, the token will changes all the time, so why have such function?
还有一个函数，就是“salt”的antiForgeryToken，但是我真的知道这是用来做什么的，即使我们不使用“salt”来生成令牌，令牌会一直变化，那么为什么会有这样的功能？
回答by russau
Lots of info on the AntiForgeryToken here: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/
这里有很多关于 AntiForgeryToken 的信息：http: //blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/
This is to prevent a Cross-Site Request Forgery (CSRF). It's pretty standard behavior to click 'Save' sumbit a form and perform some action on the server, i.e. save a user's details. How do you know the user submitting the form is the user they claim to be? In most cases you'd use some cookie or windows based auth.
这是为了防止跨站点请求伪造 (CSRF)。单击“保存”提交表单并在服务器上执行某些操作，即保存用户的详细信息，这是非常标准的行为。你怎么知道提交表单的用户是他们声称的用户？在大多数情况下，您会使用一些基于 cookie 或 Windows 的身份验证。
What if an attacker lures you to a site which submits exactly the same form in a little hidden IFRAME? Your cookies get submitted intact and the server doesn't see the request as any different to a legit request. (As gmail has discovered: http://www.gnucitizen.org/blog/google-gmail-e-mail-hiHyman-technique/)
如果攻击者引诱您访问一个站点，该站点在一个隐藏的 IFRAME 中提交完全相同的表单，该怎么办？您的 cookie 被完整提交，服务器不会将请求视为与合法请求有任何不同。（正如 gmail 发现的那样：http: //www.gnucitizen.org/blog/google-gmail-e-mail-hiHyman-technique/）
The anti-forgery token prevents this form of attack by creating a additional cookie token everytime a page is generated. The token is both in the form and the cookie, if the form and cookie don't match we have a CSRF attack (as the attacker wouldn't be able to read the anti-forgery token using the attack described above).
防伪令牌通过在每次生成页面时创建额外的 cookie 令牌来防止这种形式的攻击。令牌同时存在于表单和 cookie 中，如果表单和 cookie 不匹配，我们就会发起 CSRF 攻击（因为攻击者无法使用上述攻击读取防伪令牌）。
And what does the salt do, from the article above:
盐有什么作用，来自上面的文章：
Salt is just an arbitrary string. A different salt value means a different anti-forgery token will be generated. This means that even if an attacker manages to get hold of a valid token somehow, they can't reuse it in other parts of the application where a different salt value is required.
Salt 只是一个任意字符串。不同的盐值意味着将生成不同的防伪令牌。这意味着即使攻击者设法以某种方式获得有效令牌，他们也无法在需要不同盐值的应用程序的其他部分中重用它。
Update:How is the token generated? Download the source, and have a look at the AntiForgeryDataSerializer, AntiForgeryData classes.
更新：令牌是如何生成的？下载源代码，并查看 AntiForgeryDataSerializer、AntiForgeryData 类。
回答by Noon Silk
You've ask a few unrelated problems:
你问了几个不相关的问题：
- I don't know why your security software is reporting 'session fixed'. Try reading the documentation that comes with the report
- The anti-forgery token:
- 我不知道为什么您的安全软件报告“会话已修复”。尝试阅读报告附带的文档
- 防伪令牌：
This is used (presumably) to validate that each request is valid. So consider that someone tries to present a link to the page ?x=1, if the token is not also passed, the request will be rejected. Further, it (may) prevent duplicate posting of the same item. If you click 'post' twice, the token will likely change (each request), and this case will be detected via something like:
这用于（大概）验证每个请求是否有效。因此考虑到有人试图提供指向页面的链接?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
I think the term for this (the attack it protects) is called "CSRF" (Cross-Site Request Forgery), these days.
我认为这个术语（它保护的攻击）现在被称为“CSRF”（跨站点请求伪造）。
