我认为这是相当简单的事情。 ValidateAntiForgeryToken
是一个过滤器属性,我们可以将其应用于MVC控制器上的post方法。
它将检查通过调用__RequestVerificationToken
帮助器注入的隐藏表单字段@Html.AntiForgeryToken()
的值是否与Http-Cookie值匹配。所以很奇怪它似乎有效,但我现在在审查时不理解,因为值不匹配:
使用Google Dev工具,我会将以下标题发回到登录表单。我原本以为红色下划线的两个值匹配,但它们没有,但一切仍然“有效”。那么,ValidateAntiForgeryToken
如何工作,因为我认为在服务器上进行比较的值 - 实际上并不匹配?
答案 0 :(得分:4)
html表单字段中的值以及通过查看响应头中的cookie而显示的值是不同的,因为它们实际上是包含不同数量属性的序列化有效负载。
因此,当html表单字段__RequestVerificationToken中的某个地方存在请求令牌的值时,也存在所使用的加密盐的值。
响应头中的Http-Cookie可能包含该信息以及其他加密数据(如用户身份数据和角色),这些数据全部捆绑在一起然后序列化。
这就是为什么它们在使用嗅探工具/查看页面源等的客户端上看起来不同。它们是已经序列化的不同大小的数据包。 所以我们看到的不是令牌,而是包含令牌的序列化对象。
因此,虽然每个请求参数(__RequestVerificationToken表单字段和__RequestVerificationToken cookie)包含另一个的完全匹配,但我们为每个参数看到的可见字符串,根据我上传的图像将是不同的,因为这些字符串不是实际的标记,而是包含标记的对象的序列化输出。
直到将整个请求发回服务器并且服务器将我们在上图中看到的这些字符串反序列化为对象,我们才能获得一些可以比较匹配的原始属性。