这是我关于绕过速率限制的一篇文章
我一直在努力关注速率限制及其安全机制。我已经阅读了很多关于绕过速率限制的文章,并在我的清单中收集了所有方法。
在他们的任何端点上,有两个负责防止速率限制攻击。
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”并开始攻击。