pentagridsec/pentagridresponseoverviewBurpSuite 响应概览扩展 - 通过对响应正文进行分组来发现异常响应
BurpSuite 响应概览扩展
作者：Tobias "floyd" Ospelt，@floyd_ch，http://www.floyd.ch
Pentagrid AG，https://www.pentagrid.ch
该扩展会根据相似性对所有响应正文进行分组，并显示一个摘要，每组显示一个请求/响应。该扩展允许测试人员从所有工具（扫描器、代理等）中获取被测网站响应的概览。它提供了一种额外的“半自动化检测方法”（与通常的基于响应、基于时间、基于交互等检测方法相比）。其中包含多种优化，主要是出于性能方面的考虑。“移除参数”功能会在比较之前从响应中移除被反射的请求参数。
到目前为止：
使用非常简单：
该扩展会在以下情况下分析 HTTP 响应：
当满足上述过滤条件时，传入的响应正文（来自所有 Burp 工具！）会与我们已创建的所有分组进行比较。一个分组由其第一个成员定义，我们会将其保留在内存中。如果我们正在处理的响应与该第一个成员有 95% 相似，则它属于该分组，并且只会增加“Group Size”计数器。这也意味着我们不会存储该响应。如果该响应与任何分组都不具有 95% 的相似性，则它会形成一个新分组，并且它是该分组的第一个成员。
我于 2010 年向 w3af 项目提出了这种允许你发现异常的响应概览的第一个版本（另见此处讨论：https://github.com/andresriancho/w3af/issues/17345），它是用 Python 编写的。它从未进入 w3af 主线，我不记得原因了。那时我学到了很多关于 Python difflib 的知识，并针对该用例优化了性能。我在 2019 年为 Burp 用 Python 编写了一个类似的扩展，并在为 modzero AG https://github.com/modzero/burp-ResponseClusterer 工作时再次学到了很多关于 Python difflib 的知识。然而，在某个时候我意识到该扩展可能会消耗 Burp 的一些性能，而我起初忽略了这一点。2021 年，该扩展完全失效，因为它无法再与较新的 Jython 版本一起运行；而在重新审视代码时，我意识到我编写了一个内存效率非常低的扩展。所以，这就是现在的情况：这是 2021 年用 Kotlin 编写的新扩展，具有新功能，并再次从 Python 的 difflib 和不同功能中学到了很多。我进行了性能改进，因为我意识到如果我们总是与相同的字符串进行比较（正如 Python 代码中已经实现的那样），某些计算是不必要的。Response Clusterer 已死，Response Overview 万岁。
理论上，默认设置可能会导致 Burp 的性能不那么理想。然而，这种情况极不可能发生。在一项测试中，所有响应都具有最大默认响应大小（约 1MB），并且必须相互比较，使用预计算的 bByteCount 优化（常规情况）时比较耗时最多 30ms，而没有此优化时最多 80ms（每个条目仅发生一次）。乘以最大分组数量（1000），这意味着在最坏情况下，这可能意味着最多 80 秒的处理时间。由于有单独的线程，这还可以承受，因为下一次比较最多只需要 30 秒。但是，哪个 Web 应用程序会有许多约 1MB 的不同响应呢？希望不要太多。另外别忘了，如果响应长度差异超过 2%，由于 veryQuickRatio 优化，相似性匹配几乎不耗时。
