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