如何防止自动 AJAX 攻击

Question

如何防止用户自动发帖/垃圾邮件？

这是我的做法，每个页面请求都有新的 php 会话，它有其自身的局限性，没有多选项卡。

我为每个页面使用了新会话来防御 CSRF 和自动攻击。假设我们有一个使用 AJAX 发布线程的论坛，并通过 PHP SESSION 进行验证。

add_answer.php?id=123

<?php
if(!is_ajax()){// function that determines whether the request is from ajax (http header stuff)
$_SESSION['token'] = md5(rand());
}
//some ajax request to ajax.php?id=123
?>

ajax.php?id=123

<?php
if($_SESSION['token'] == $_GET['token']){
echo 'MYSQL INSERT stuff';
}else{
echo 'Invalid Request';
}
?>

一切正常，直到用户在另一个选项卡上打开 page.php?id=456，ajax 在 ajax.php?id=123 这与我问的另一个问题相关。他们建议始终只使用一个会话哈希，直到他/她注销 - 然后才会重新生成会话。如果令牌是同一个用户，则可以简单地绕过它并进行自动攻击。对此有什么想法吗？

无论如何，您的方法如何防止自动 AJAX 攻击？

PS：

1. 不要用验证码折磨用户。
2. 谷歌未能向我展示对此有用的东西。
3. 将此视为一个挑战。
4. 或者至少对专家的答案进行投票，您认为这是做到这一点的绝妙方法

Answer 1

听起来您反对只要浏览器打开就让会话保持打开状态是自动攻击的问题。不幸的是，在每个页面加载时刷新令牌只能阻止最业余的攻击者。

首先，我假设我们正在讨论专门针对您的网站的攻击。 （如果我们谈论的是那些只是四处游荡并提交各种表格的机器人，这不仅不会阻止他们，而且还有更好、更简单的方法来做到这一点。）如果是这样的话，我的目标是我的网站，这就是我的机器人会做的事情：

1. 加载表单页面。
2. 读取表单页面上的令牌。
3. 使用该令牌提交自动请求。
4. 转到步骤 1。

（或者，如果我对您的系统进行了足够的调查，我会意识到，如果我在每个请求中包含“这是 AJAX”标头，我可以永远保留一个令牌。或者我会意识到该令牌是我的会话 ID，并发送我自己的 PHPSESSID cookie。）

这种在每次页面加载时更改令牌的方法绝对无法阻止那些真正想要攻击你们所有人的人太糟糕了。因此，由于代币对自动化没有影响，所以重点关注它对 CSRF 的影响。

从阻止 CSRF 的角度来看，创建一个令牌并维护它直到用户关闭浏览器似乎就完成了所有目标。简单的 CSRF 攻击被击败，用户能够打开多个选项卡。

TL;DR：在每个请求上刷新一次令牌并不会提高安全性。追求可用性并在每个会话中执行一个令牌。

---

但是！如果您非常担心重复的表单提交（无论是意外还是其他原因），这个问题仍然可以轻松解决。答案很简单：将两个令牌用于两个不同的工作。

第一个令牌将保持不变，直到浏览器会话结束。该令牌的存在是为了防止 CSRF 攻击。该用户使用此令牌提交的任何内容都将被接受。

第二个令牌将为加载的每个表单唯一生成，并将存储在打开表单令牌的用户会话数据的列表中。该Token具有唯一性，一旦使用即失效。该用户使用此令牌提交的内容将被接受一次且仅一次。

这样，如果我打开表单 A 的选项卡和表单 B 的选项卡，每个选项卡都会有我个人的反 CSRF 令牌（已处理 CSRF）和我的一次性表单令牌（已处理表单重新提交）。这两个问题均得到解决，且不会对用户体验产生任何不良影响。

当然，您可能会认为对于这样一个简单的功能来说，实现起来太多了。无论如何，我认为是这样。无论如何，如果你想要的话，就存在一个可靠的解决方案。

Answer 2

如果您试图阻止某个客户端对您进行 DoS，一种不常见但可行的策略是包含 hashcash请求中的令牌（已经有 PHP 和 JavaScript 实现）。

为了防止破坏选项卡式浏览和后退按钮，理想情况下，您希望 hashcash 令牌的质询包含每个会话的防伪令牌和为每个请求新生成的唯一性部分。如果您的令牌成本较高，为了尽量减少对可用性的影响，请在消耗完前一个令牌后立即开始预先计算页面中的下一个令牌。

这样做会限制客户端生成有效请求的速率，因为每个 hashcash 令牌只能使用一次（这意味着您需要保留附加到会话的有效的、已用过的 hashcash 令牌的缓存，以防止无休止的重用单个令牌的数量），它们无法在会话开始之前计算（因为随机的防伪值），并且生成每个新的有效令牌需要花费大量的 CPU 时间，但只需要很少的时间来验证一个。

虽然这并不妨碍 AJAX API 本身的自动化，但它确实限制了 API 的大量使用。

Answer 3

如何防止用户自动发布帖子/垃圾邮件？

这可能可以通过与常规请求相同的方式解决。每页加载一个令牌并停止新选项卡可能有点矫枉过正。当然，每个表单的时间敏感令牌可以在一定程度上减轻 CSRF 攻击。但除此之外，最好定义并实现提交策略引擎，而不是限制用户体验。

冒着对每个人来说听起来浮夸或贬低的风险：网站通常使用基于积分的奖励系统，例如“业力”或“徽章”。这样的系统实际上增加了用户体验，因为提交内容变成了用户的一种游戏。他们通常可能会限制仅向受信任的用户发布提交内容的能力，或者限制在给定时间范围内的最大数量。查看 SO 的系统以获得良好的用例。

一个非常基本的答案，只是演示一些常见的站点策略：

• 如果用户在过去 y 分钟内的帖子数量超过了 x 数量，则拒绝数据库插入并显示“抱歉，自上次帖子以来太早了”警告。这可以通过在允许插入新记录之前查询数据库在给定的最近时间段内的用户帖子计数来实现。
• 如果用户没有一定的业力阈值 - 例如，新用户或反复被标记为垃圾邮件发送者的用户 - 拒绝数据库写入并显示“抱歉，你在这里呆的时间不够长”或“抱歉，你也发垃圾邮件”很多”警告。这可以通过在允许插入新记录之前在数据库中查询用户的“业力”总数来实现，该“业力”在单独的表或站点模块中进行管理。
• 如果网站很小且易于管理，仅可由一两个用户管理，请首先审查和批准所有新用户请求和帖子。这可以通过在移动到实时表之前在单独的表中保存新条目以供审查，或者通过在主表上设置“已批准”标志列来实现。

此外，可以对每个用户保留策略违规计数，如果在给定时间段内超过特定点，您可以选择在特定时间段内自动禁止他们。如果您愿意，可以通过拒绝与该用户相关的所有数据库写入来实施该禁令。

关于“http header stuff”的注释，标头仅用于对客户端请求的内容进行最佳猜测和礼貌。它们与伪造饼干一样困难，而伪造饼干只需要点击鼠标即可。老实说，我个人不会有任何其他方式。