大型语言模型，如ChatGPT、Gemini和Claude，正在重新定义人们获取信息和执行日常任务的方式。网络安全行业也不例外。团队正将LLM用于从安全运营中心自动化到防范网络钓鱼攻击、安全意识教育等方方面面。

LLM表现尤为突出的一个领域是帮助从业者分析应用程序的安全性——特别是在支持红队活动方面。基于LLM的工具和插件已经带来了益处。其中包括分析从Burp Suite或Zed Attack Proxy等测试应用导出的HTTP流信息（例如通过上下文菜单）的工具，以及位于代理链中、批量卸载请求和响应以供LLM审查的工具。

然而，即使没有专用工具，HTTP的人类可读性，加上其可预测的结构，使其特别适合进行LLM分析。不过，与任何新技术相关的事物一样，往往难以知道从何处以及如何开始。为此，我们来探讨几种在渗透测试中使用LLM的方法。

但首先，有几点需要快速注意：

注意服务条款和安全护栏。每个LLM对于允许的内容和可接受的用途可能有不同的规则。要了解这些限制，以确保你遵守它们。有些LLM设有安全护栏，即使你遵守规则也会限制使用。其他LLM可能会过滤它们认为在不同上下文中可能敏感的信息——例如，JSON Web令牌中的非认证字段。

下面详述的五个用例并非详尽无遗；这些并不是唯一潜在的部署方式。所包含的这些用例在大多数测试条件下普遍适用，并且因为它们能可靠地带来显著价值。你可能还有本文未涵盖的需求或情况。

1. 会话状态与登录流程

分析应用程序状态维护是利用LLM进行渗透测试的好方法。模型可以帮助建立状态（例如登录流程），以及用于维护状态的工件，其中包括安全断言标记语言断言、承载令牌、通用唯一标识符、JWT、会话Cookie和文档对象模型工件。

对人类来说，解码这些并不总是容易的。将原始请求和响应块（如请求头、请求/响应体）剪切并粘贴到登录请求中，可以提供相当多有用的信息。即使从业者不能直接剪切粘贴一个请求（例如，当登录交换涉及多个请求时），他们仍然可以在这里获得价值。ZAP、Burp和其他流行工具允许专业人员将这些导出为文本文件或HTTP存档文件，供LLM稍后分析。

一个重要提示：虽然大多数推理模型可以解包和分析即使是编码过的工件（例如URL编码、Base64编码或十六进制编码），但更复杂的数据结构和多层编码会增加LLM产生幻觉并提供不准确数据的可能性。这种现象在较小的和自托管的推理模型中尤为明显。

2. 逆向工程网站构成

登录和状态维护在此列表中排名第一，因为这是许多问题可能出现的地方。想想有多少OWASP Top 10（特别是其API Top 10）与认证、授权和状态相关。话虽如此，状态维护可能并不是最常执行的任务。这个荣誉归于识别网站架构和构建——这是每次渗透测试中所需的步骤，并且在许多情况下，每次测试中涉及多个组件。

LLM可以在这里发挥重要作用：定义特定网站如何构建的潜在组合非常多。网站可能混合使用不同的应用脚手架策略、中间件、PaaS、API、语言和其他因素。对于任何个体测试者，无论经验多么丰富，几乎不可能一眼就全部识别出来。测试者今天可能与基于React的前端和基于Scala的Play Framework后端打交道，明天则要处理一个在Django上重度使用GraphQL的Node应用。

逆向工程一个给定应用程序的构建方式、理解各部分如何组合，并研究其架构的具体问题，是一项大量的工作。这也是利用LLM来简化此任务的绝佳机会。

通过检索增强生成，向LLM提供请求和响应以及从网站抓取的数据（例如，HTTP流的捕获、Wget或Playwright的输出等）。这可以作为商业LLM项目文件的一部分，或者作为内部托管模型的本地数据文件的一部分。

3. 识别遗留组件

在渗透测试中使用LLM也有助于寻找应用程序中存在问题的、遗留的、易受攻击的或已停用的组件。以一个基于WordPress构建的网站为例。识别正在使用的插件和主题，并将其与易受攻击的版本进行交叉引用，可能很痛苦，即使使用WPScan等专用工具也是如此。

而这仅仅是WordPress。几乎每个页面都存在类似的潜在问题。旧版本的库，如jQuery、Angular或Handlebars——更不用说较小或特殊用途的库——可能带来重大的安全难题。LLM可以帮助识别那些过时的版本，更重要的是，那些可能为应用程序提供潜在攻击路径的版本。

LLM在这里特别有效，因为它们比人类更容易识别库的易受攻击版本，并且不需要显式的版本字符串，例如基于API中特定方法的调用方式的句法差异或使用已弃用的函数。LLM可能会看到对jQuery中.live()方法的调用，并正确指出这种用法已被弃用。因此，正在使用的版本可能容易受到基于live的跨站脚本攻击。LLM在几分钟内就能提供专业人士可能需要数小时研究——或者更糟，可能遗漏——的信息。

4. 逆向工程压缩代码

在应用程序领域，压缩代码引发的挫败感比其他任何问题都多。对于有时限的测试来说，解包和分析压缩代码是一个主要的时间消耗，许多测试者除非绝对必要，否则都会避免。即便如此，时间限制（例如，有小时数上限的测试）也可能妨碍彻底性。

虽然存在帮助解压和解包压缩代码的工具，但在许多情况下，扩展主要与间距有关。当变量和函数名称完全不透明时，仍然很难得到人能读懂的东西。LLM没有这种限制。它们可以帮助解包和理解压缩代码，这是其他方式难以完成的。例如，LLM可能会识别一个压缩函数，该函数解析JWT并返回user.admin而不检查签名——即使该函数被命名为q()且变量名称毫无意义。

请注意，大多数LLM，即使是较小的模型，对于标准库和框架都很准确。然而，对于仅在被分析应用中出现的自定义代码，它们更容易产生幻觉。为此，虽然LLM可以提供有益的基线数据，但如果逆向工程压缩代码是测试者正在进行的攻击场景的核心，请信任但要验证。

5. 有效载荷制作与变异

人类容易疲劳——尤其是在非工作时间进行测试窗口以及经过多个小时的持续测试后。工程师在制作有效载荷、为模糊测试构思种子以及执行其他测试程序时可能犯错。生成式LLM提供了一个替代方案。像“生成一个XSS有效载荷以绕过基于React的净化器，并在鼠标悬停时触发”这样的提示可以极大地帮助测试者验证可利用性。LLM也为探测注入用例（包括SQLi、LDAP注入和XML注入）以及XSS、路径遍历、JWT操纵和其他有效载荷提供帮助。

另一个重要提示：这类用例正好触及许多商业LLM通过其安全护栏所允许的边缘。预计会遇到很多阻碍，包括直接拒绝执行，除非测试者拥有本地托管的模型或企业级LLM层，允许他们定义自己的策略阈值。即使在LLM确实阻止响应的情况下，与LLM的创造者讨论方法（在抽象层面，如果不允许更具体的内容）以绕过过滤或编码机制，仍然具有相当大的潜在价值。

编者按：本文中的用例既可能被合法使用，也可能被非法使用。由您确保您的使用是合法的。在进行红队活动之前，请获得适当的许可和批准，并道德地处理所获得的信息。如果您不确定您的使用是否合法，请不要继续，直到您确认其合法性——例如，通过与您组织的法律顾问讨论并验证您的计划用途。