我正在构建一个使用大量ajax的应用程序。大多数反CSRF解决方案都围绕在视图状态中放置一些信息并在帖子上处理这些数据。但是，我无法访问ajax调用中的viewstate。
我计划生成GUID以在cookie和会话状态中插入令牌，在用户注销时使cookie过期，在每次请求时修改cookie令牌和会话状态，并使用httpmodule进行工作在转到Web服务或页面方法之前，通过比较会话中的内容与从客户端返回的内容。
这会使我的应用CSRF证明吗？
感谢。
答案 0 :(得分：9)
否。＆＃34;反CSRF＆＃34;和＆＃34; cookie＆＃34;不要一起去正如Thilo如此简明扼要地指出：
Cookie是让CSRF首先工作的原因......
良好的初步阅读是Cross-Site Request Forgery文章，它将CSRF的大部分内容与以下内容相加：
如果Bob的银行将其身份验证信息保存在Cookie中，并且Cookie未过期，则Bob浏览器尝试加载图片将提交带有Cookie的提款表单，从而在未经Bob批准的情况下授权交易。
问题是浏览器总是有＆＃34;有效的cookie＆＃34;。但是，GUID - 实际上只是a nonce - 可以通过其他方式返回传输到服务器......这实际上就是它在视图状态中的状态。
CSRF预防机制＃1（每个维基百科）：
在所有表单提交和副作用网址中要求使用特定于用户的秘密令牌会阻止CSRF;攻击者的网站无法在提交的内容中加入正确的令牌。
重要的是这个秘密（希望是为了避免重放攻击）是发送的数据（URI或内容）的一部分，而不是通过cookie传输。
快乐的编码。
考虑一种可以实现的方式：
让服务器在建立会话时生成一个nonce（并将其存储在会话数据中）。然后在每个AJAX请求上发送此nonce - 将作为URI的一部分或作为某些POST数据 *。
服务器服务器应仅基于此nonce接受/拒绝请求，并且它是否与存储在会话状态中的nonce匹配。 （会话状态可以通过cookie维护：它是通过不同的通道传输的nonce，它将阻止这个CSRF，假设nonce是秘密的。）
nonce可以通过多种方式传输到客户端，包括但不限于隐藏字段，JavaScript变量，直接链接操作，甚至cookie（只读！不用于验证！）。
*当然，有许多重叠的安全问题（和预防机制）在起作用，简单的XSS可以绕过最精细的反CSFR。考虑使用经过充分测试的框架可能值得考虑......