这是我关于绕过速率限制的一篇文章

我一直在努力关注速率限制及其安全机制。我已经阅读了很多关于绕过速率限制的文章，并在我的清单中收集了所有方法。

在他们的任何端点上，有两个负责防止速率限制攻击。

X-Recaptcha-Token header
X-Security-Token header

因此，这个 X-Recaptcha-Token header由验证码令牌组成，X-Security-Token 由一个 long 值组成，每次发出新请求时，这两个参数的值都会发生变化。

所以很可能，我们甚至不能发送超过 1 次相同的请求。

因此，如果我删除了“X-Recaptcha-Token”，它会显示一个错误“captcha token invalid or not found”。

这就是他们强大的速率限制安全机制。

在查看了一些返回包后，我发现有一个Header“X-Disabled-Recaptcha:0”。

我立即从请求中删除了之前的Header，并添加了值为“1”的“X-Disabled-Recaptcha”Header。

在发送此请求而不是收到“Recaptcha 令牌无效或未找到”的错误时，它显示了一个不同的错误，指出“安全令牌无效或已被使用”。

是的，你猜对了。我们能够绕过 recaptcha 令牌机制，但安全令牌仍然在阻止，我尝试了所有方法来绕过安全令牌检查，但没有任何效果。所以我只是认为它并不容易受到攻击，也没有办法绕过这种机制。

几天后，我再次打开那个 Burp 文件并开始观察所有端点。

我发现了一个负责生成该“安全令牌”的端点，并且没有仅针对该特定端点的速率限制机制。

现在，安全令牌的正常行为应该是新令牌一生成，旧令牌即使未使用也应立即过期。我手动复制了 10 个安全令牌并发送了标头为“X-Disabled-Recaptcha:1”的请求。

所有的请求都成功了。就这样，我绕过了这个机制。

我创建了一个简单的脚本来使用之前找到的端点创建 1000 个唯一的安全令牌。

将此令牌导入入侵者。添加Header头“X-Disabled-Recaptcha:0”并开始攻击。

最后，我告诉他们，我能够在他们所有的端点上绕过他们的机制，使他们大胆的声明漏洞，他们奖励我 1800 美元，即使它超出了范围。

推荐阅读：

实战 | 记一次条件竞争文件上传

618 | 2023年零基础+进阶系统化白帽黑客学习报名

实战 | 记一次赏金1.78万美金的Github未授权漏洞挖掘

实战｜记一次5657美金赏金的XSS漏洞挖掘经历

实战 | 记一次PII 数据泄露和1500 美元的赏金