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