我正在尝试保护应用程序(php 和大量 JS)免受 CSRF 侵害。
我想使用 token 。
很多操作都是通过AJAX完成的，所以我必须在Javascript中传递 token 。 如果我想为每个 session 或每个页面加载生成 1 个 token ，这很简单 - 我生成新 token ，将其放在 DOM 中的某个位置，然后使用 Javascript 找到它并发送到处理端。
但是如果我想为每个操作使用新 token 怎么办？ 我正在考虑进行 ajax 调用来重新生成 token ，然后将结果传递到处理页面。
这会增加安全风险吗？ 我正在考虑用脚本引诱用户页面，该脚本会要求 token ，然后使用它来发出请求，但跨域 Javascript 再次被禁止。 可以用flash实现吗？
也许是另一种保护 ajax 调用免受 CSRF 影响的方法？
谢谢!
最佳答案
有多种技术，当它们一起使用时可以提供足够的 CSRF 保护。
唯一 token
对于大多数应用程序来说，单个特定于 session 的 token 就足够了。只需确保您的网站没有任何 XSS 漏洞，否则您使用的任何类型的 token 技术都是浪费。
AJAX 调用重新生成 token 是一个坏主意。谁来守护卫兵？如果 AJAX 调用本身容易受到 CSRF 的攻击，那就达不到目的了。使用 AJAX 的多个 token 通常是个坏主意。它强制您序列化您的请求，即一次只允许一个 AJAX 请求。如果您愿意忍受这一限制，您也许可以为第二个 AJAX 调用搭载 token 以响应第一个请求。
就我个人而言，我认为最好对关键交易的用户进行重新身份验证，并使用 session 特定 token 保护剩余交易。
自定义 HTTP header
您可以向每个请求添加自定义 HTTP header ，并检查其在服务器端的存在。实际的键/值不需要保密，服务器只需要确保它存在于传入请求中。
这种方法足以在较新版本的浏览器中保护 CSRF，但是如果您的用户使用旧版本的 Flash Player，也可以解决此问题。
检查引荐来源网址
检查 Referrer header 也有助于保护较新浏览器中的 CSRF。尽管在旧版本的 Flash 中可以欺骗该 header ，但不可能欺骗该 header 。因此，虽然它并非万无一失，但它仍然增加了一些保护。
解决验证码
强制用户解决验证码对于对抗 CSRF 也很有效。它非常不方便，但非常有效。即使您存在 XSS 漏洞，这可能也是唯一有效的 CSRF 保护。
摘要
- 使用基于 session 的 token ，但对高值(value)交易重新进行身份验证
- 添加自定义 http header ，并检查引荐来源网址。两者本身都不是万无一失的，但不要受伤
关于ajax - 反 CSRF token 和 Javascript，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3664044/