反 CSRF 令牌和 Javascript

Question

我正在尝试保护应用程序（php 和大量 JS）免受 CSRF 的影响。

我想使用令牌。

很多操作都是用 AJAX 完成的，所以我必须在 Javascript 中传递令牌。 如果我想为每个会话或每个页面加载生成 1 个令牌，这很简单 - 我生成新令牌，将其放在 DOM 中的某个位置，然后使用 Javascript 找到它并发送到处理端。

但是，如果我想对每个操作都使用新令牌怎么办？ 我正在考虑进行 ajax 调用以重新生成令牌，然后将结果传递给处理页面。

这会增加安全风险吗？ 我正在考虑用脚本来引诱用户页面，该脚本会要求令牌，然后使用它来发出请求，但随后再次禁止跨域 Javascript。 可以用flash做吗？

也许是另一种保护 ajax 调用免受 CSRF 影响的方法？

谢谢！

Answer 1

有几种技术，当它们一起使用时，可以提供足够的 CSRF 保护。

唯一令牌

对于大多数应用程序来说，一个单一的、特定于会话的令牌就足够了。只需确保您的网站没有任何 XSS 漏洞，否则您使用的任何类型的令牌技术都是浪费。

重新生成令牌的 AJAX 调用是个坏主意。谁来守卫守卫？如果 AJAX 调用本身容易受到 CSRF 的攻击，那么它就有点违背了目的。使用 AJAX 的多个令牌通常是个坏主意。它迫使您序列化您的请求，即一次只允许一个 AJAX 请求。如果您愿意接受该限制，您也许可以为第二个 AJAX 调用搭载令牌以响应第一个请求。

就个人而言，我认为最好对关键交易重新验证用户身份，并使用特定于会话的令牌保护剩余交易。

自定义 HTTP 标头

您可以为每个请求添加自定义 HTTP 标头，并在服务器端检查它的存在。实际的键/值不需要保密，服务器只需要确保它存在于传入的请求中。

这种方法足以在较新版本的浏览器中保护 CSRF，但是如果您的用户使用旧版本的 Flash Player，它也可以解决此问题。

检查推荐人

检查 Referrer 标头也有助于在较新的浏览器中保护 CSRF。尽管在旧版本的 Flash 中可以欺骗此标头，但它不可能欺骗此标头。所以，虽然它不是万无一失的，但它仍然增加了一些保护。

解决验证码

强制用户解决验证码对 CSRF 也是有效的。它非常不方便，但非常有效。即使您有 XSS 漏洞，这可能是唯一有效的 CSRF 保护。

总结

1. 使用基于会话的令牌，但对高价值交易重新进行身份验证
2. 添加自定义 http 标头，并检查引荐来源网址。两者本身都不是万无一失的，但不要伤害