我正在尝试从CSRF保护应用程序（php和许多JS）。
我想使用令牌。
很多操作都是用AJAX完成的，所以我必须在Javascript中传递令牌。 如果我想为每个会话或每页加载生成1个令牌，那么它很简单 - 我生成新令牌，将其放在DOM中，然后使用Javascript找到它并发送到处理端。
但是，如果我想为每个操作使用新令牌呢？ 我正在考虑做一个ajax调用来重新生成令牌，然后将结果传递给处理页面。
这会增加安全风险吗？ 我正在考虑引诱用户使用脚本来寻求令牌，然后使用它来发出请求，然后再次跨域Javascript被禁止。 它可以用闪光灯完成吗？
也许另一种保护来自CSRF的ajax调用的方法？
谢谢！
答案 0 :(得分：27)
有几种技术在一起使用时可提供足够的CSRF保护。
唯一标记
单个特定于会话的令牌足以满足大多数应用程序的要求。只需确保您的网站没有任何XSS漏洞，否则您使用的任何令牌技术都是浪费。
重新生成令牌的AJAX调用是一个坏主意。谁会守卫守卫？如果AJAX调用本身容易受到CSRF的影响，那就有点失败了。使用AJAX的多个令牌通常是个坏主意。它会强制您序列化您的请求，即一次只允许一个AJAX请求。如果你愿意接受这个限制，你可以为第二个AJAX调用搭载令牌以响应第一个请求。
就个人而言，我认为最好为关键交易重新验证用户身份，并使用会话特定令牌保护剩余交易。
自定义HTTP标头
您可以为每个请求添加自定义HTTP标头，并检查其在服务器端的存在。实际的密钥/值不需要是保密的，服务器只需要确保它存在于传入的请求中。
这种方法足以在较新版本的浏览器中保护CSRF，但如果您的用户使用的是旧版本的Flash Player，则可能会解决此问题。
检查推荐人
检查Referrer标头也可以在较新的浏览器中保护CSRF。它不可能欺骗这个标题，虽然它可以在旧版本的Flash中使用。因此，虽然它不是万无一失的，但它仍然会增加一些保护。
解决验证码
强制用户解决验证码对CSRF也有效。它不方便，但非常有效。即使您有XSS漏洞，这也许是唯一有效的CSRF保护。
<强>摘要