如何构建自定义扫描器实现Web安全研究自动化
在这篇文章中，我将分享我开发自定义自动化工具的方法，以帮助研究被低估的攻击类别，并（希望）推动Web安全的边界。作为一个实际例子，我将基于我的研究《粉碎状态机：Web竞态条件的真正潜力》进行构建。如果你还没有看过，这个演讲的DEFCON录音现在已经可用，可能值得一看。
识别机会
你认为有可能创建一个可以自动检测Web竞态条件的扫描器吗？我最初否定了这个想法，因为我发现的竞态条件需要触发复杂的、多步骤的经过身份验证的网站交互，并发现细微的副作用。
在这项研究过程中，我注意到竞态条件经常成群出现。它们从不稳定的库和框架中冒出来，所以如果你在一个网站中发现了一个，很可能还有其他潜伏在附近。这意味着即使检测到的竞态本身是无害的，自动检测竞态条件也可能是有价值的。
我决定基于我对这个主题的熟悉程度、以单包攻击形式的新工具，以及一个测试平台，意味着我可以在一天或两天内尝试这个概念，这个想法值得探索。
避免过度承诺
当尝试自动化某些棘手的事情时，一个常见的陷阱是尝试自动化太多，最终无法实现任何有用的东西。为了避免这种情况，我喜欢检查我的手动测试方法，并确定我可以合理自动化的最小、最早的步骤。以下是我用于竞态条件的手动测试过程：
由于“预测”阶段只是关于效率，我们可以跳过这个阶段，简单地尝试自动化“探测”阶段。这个阶段的目标是使用一批并发请求来触发“异常”，并证明一个端点可能有一个子状态。
拥抱意外
我编写了代码，先顺序发送一个请求十次，然后使用单包攻击在1毫秒内重新发送十次。我预计在一个容易发生竞态的网站上，并发请求可能会触发50X错误响应。
在这一点上，我本可以通过仅针对看起来动态的端点，并仅报告带有50X代码的响应来提高效率并减少误报。然而，最好的研究发现往往来自意外的结果。这意味着避免将你的期望写入代码中是很重要的。我故意为意外结果留出空间，通过测试所有观察到的请求，无论它们是为了什么，并报告状态代码的任何差异。
当涉及到研究时，我宁愿有误报也不愿有漏报。
使迭代变得容易
这种方法在开始时不可避免地会导致大量的误报，因此使迭代改进变得无痛是至关重要的。
我在Burp Suite扩展中实现了这一点，并作为一个测试平台，我使用了一个项目文件，其中包含来自约30,000个有漏洞赏金计划的网站的主页和资源。有关此设置的更多详细信息，请查看《破解镜头》。
对于完整的运行，我只需选择代理中的所有请求，右键单击，然后启动扫描。它优先处理较短的域名，因此高调目标的结果往往会很快出现。
自动化你的分类
我通常手动分类一小部分发现，然后分析我的分类过程并自动化它。在处理结果时，我发现自己：
- 忽略关键请求只是超时的发现
- 忽略带有429状态代码的发现，因为这些只是速率限制
- 忽略带有502/503的发现，因为这些表示后端超时
- 在并发批次后尝试额外的顺序请求
- 添加缓存破坏器以过滤出缓存行为
在我的扫描检查中实施这个过滤过程并重新运行后，我留下了一些有希望的发现：
- 各种奇怪的50X和307代码
- 一个Web服务器，当你使用单包攻击时，会发出一个神秘的“501 Not Implemented”响应，声称它不支持GET请求。
- 一个网站，触发对后端系统的服务器端请求以用于SSO目的。单包攻击使后端过载并触发了一个错误消息，披露了完整的URL。
- 另一个服务器，当受到同步请求时，间歇性地发出400 Bad Request响应。这很有趣，因为它表明它们的请求解析中可能存在竞态条件，这可能使desync攻击成为可能。
不幸的是，除了深入的手动调查之外，这些都没有给我留下明确的前进路线，而在我目标会议（Nullcon Goa）之前我没有时间进行。
滥用小工具
我需要的是一个能够检测明显危险行为的方法。
但是，你能从网站的主页直接检测到什么危险的竞态条件？嗯，我不时看到应用程序和缓存混淆的报告，要么将响应发送给错误的人，要么提供原始内存。当然，最臭名昭著的例子是Cloudbleed。
我们如何判断是否收到了针对其他人的响应？作为人类，这很容易，而LLM可能以糟糕的性能为代价来判断，但对于粗糙的、正则表达式级别的自动化来说，这是一个棘手的问题。
这就是小工具的用武之地。小工具是某些网站上存在的有用功能，使漏洞检测更容易。我们可以依靠小工具来快速轻松地探索一个概念是否值得投入更多时间。依赖小工具进行漏洞检测会导致很多漏报，但在研究的早期阶段，为了开发速度，这种权衡是值得的。
相当多的网站嵌入有关用户请求的数据，以便将其暴露给客户端JavaScript。这通常包括用户的IP地址，以及URL和User-Agent等请求属性。在包含这种类型小工具的网站上，我可以通过在每个请求中放置一个唯一的“canary”参数，然后分析每个响应以查看它是否包含来自不同请求的canary，来检测竞态信息泄漏漏洞。
这种方法最初标记了很多网站，但大多数只是通过无键查询字符串进行缓存中毒。
通过一些更多的代码调整过滤掉缓存中毒和其他“canary存储”行为后，一些真正的发现仍然存在。最好的例子是某个网站，由于竞态条件，你可以通过重复获取主页来获取实时用户正在访问的URL：
|
|
这对Nullcon来说是完美的；我拼凑了几张幻灯片，并在Backslash Powered Scanner中发布了扫描检查。你可以通过BApp商店安装它，并在Github上浏览代码。
总结
正如我们所看到的，面向研究的扫描与构建普通扫描器有很大不同，因此在将此类建议交叉应用到其他用例时请小心。
如果你想尝试自定义自动化，Burp Suite中的新BChecks功能旨在使这更加容易访问。
如果你觉得这有用，你可能也会喜欢演讲《狩猎难以捉摸的漏洞：发现别人遗漏的缺陷》，我从不同的角度研究了研究自动化。
在我的下一篇文章中，我将继续竞态条件的主题，并超越HTTP/2探索哪些其他协议支持单包攻击。