背景和目标

在网络安全领域，漏洞检测是一项至关重要且复杂的工作。随着Web应用规模的扩大和攻击手段的多样化，传统的人工检测方式已难以应对日益增长的安全需求。传统Web安全扫描器依赖预设规则库和模式匹配，难以应对新型漏洞及复杂业务逻辑中的隐性风险，且易产生误报和漏报；人工测试虽能深入分析漏洞，但受限于人力成本高、执行周期长，面对海量代码和频繁更新的应用时效率低下。

而大语言模型（LLM）凭借其强大的上下文理解能力，可快速解析业务逻辑、生成针对性测试用例，并模拟多维度攻击路径，显著提升漏洞发现的覆盖率与准确性。通过LLM辅助自动化测试，不仅能弥补传统工具的局限性，还能加速人工复核流程，成为应对现代Web安全挑战的必要补充。

本文以web安全渗透利器集成mcp server为基础来进行了此项探索与实践，介绍一种基于cline的自动化漏洞检测方案，通过其MCP Server服务，实现AI模型对BurpSuite工具的智能调度与控制，从而完成高效的Web应用漏洞自动化检测。

环境搭建

本项目原理大致是：

• 直接以sse集成MCP Server到burpSuite插件的方式，cline通过sse方式连接MCP Server。
• cline通过mcp tools获取到Proxy模块的历史流量信息后调用大模型研判原始流量里面的query参数、body参数等可能存在web漏洞的地方尽可能插入足够多的payload，然后再次调用mcp tools发送出去。
• 大模型在调用mcp tools获取到修改后的流量的response信息后和原始流量的response作对比，智能化研判当前测试的接口是否存在web安全漏洞。

环境前置条件

下面是运行环境的基本条件：

• burpSuite Pro最新版：因为新版本的burpSuite才能支持插件新版本的MontoyaApi
• MCP Kotlin sdk：https://github.com/modelcontextprotocol/kotlin-sdk.git

运行环境

按照下面操作步骤即可：

• 在编写的Kotlin MCP Server的项目根目录下面执行mvn clean package编译目标jar包。
• 在burp的Extensions模块加载此jar包，同时在插件的UI上面点击StartServer来启动MCP Server。
• 在cline客户端上面通过Remote Servers里面加载此MCP Server，默认地址是http://127.0.0.1:9999/sse

实践操作

本次笔者这里以web安全漏洞sql注入为举例进行探索。

明确告诉大模型三个步骤：

• 首先需要获取所有的历史流量信息；
• 按照历史流量信息依次顺序分析流量信息里面的参数是否可能存在sql注入漏洞，如果可能存在，那么就会在所有可能存在漏洞的地方插入payload再调用工具发送修改后的http报文来进行安全测试；
• 最后根据修改后的http报文的响应来最终判断是否存在安全漏洞，并调用mcp tools上报安全漏洞信息；

这三个操作步骤分别是：

大模型在获取到burp的所有历史流量信息以后，智能判断流量里面可能存在漏洞的参数并且替换：

修改了http请求里面的body同时添加了payload，然后调用工具发送到burp执行请求：

大模型在获取到修改后的http报文发送后返回的响应，会根据响应开判断是否存在安全漏洞，并再次调用mcp tools上报此次安全测试是否存在安全漏洞：

同时大模型会自动根据response的变化来决定是否需要继续和更换更多的payload进行继续调用tools进行测试：

笔者将所有的流量都转到了burp插件上面，我们可以看到大模型插入payload后修改的流量信息：

从上面图片可以看到，大模型已经成功在流量里面它认为存在sql注入的参数里面都插入了payload，包括了url里面的query参数，还有body里面的参数。

当然，前面的几个步骤的Approve都有用户的点击参与，实际上这里通过在cline上面设置可以完成做到Auto Approve来实现100%自动化。

困难与挑战

在本次实践中遇到了一些问题以及应对的挑战，主要有下面几点：

大模型LLM API的token限制

在我的另外一篇文章里面其实已经提到这个token限制的问题，在这里再次遇到。我理解这是一个需要大模型实际解决的问题，因为在实际的http报文分析过程中，很容易超出65536 token的限制：

比如我在让大模型调用获取burpSuite的所有历史记录的mcp tool时候就出现了（如果这个时候burpSuite的历史记录足够多，或者存在超大型Content-Length）。这个时候的解决办法就需要下面2点：

• 大模型API调用突破65536 token的限制。
• 优化mcp tools，这也是目前比较好实现的：

fun httpRequestResponseFilter(history:List<ProxyHttpRequestResponse>): List<HttpRequestResponse> {
    val responseExcludePatterns = listOf("^image/.*", "^application/pdf.*","^text/css.*")
    val historyNew = history.filter {
        val hasResponse = it.hasResponse()
        val hasContentType = hasResponse && it.response().hasHeader("Content-Type")
        // 条件 1: 无 Response → 保留
        if (!hasResponse) return@filter true
        // 条件 2: 有 Response 但无 Content-Type → 保留
        if (!hasContentType) return@filter true
        // 条件 3: 有 Content-Type → 过滤匹配的正则表达式
        val contentType = it.response().headerValue("Content-Type")!!
        !responseExcludePatterns.any { pattern ->
            contentType.matches(Regex(pattern))
        }
    }.map {
        HttpRequestResponse.httpRequestResponse(
            it.request(),
            it.response(),
            it.annotations()
        )
    }
    return historyNew
}

大模型在原始HTTP报文插入payload格式问题

大模型在原始HTTP报文插入payload的时候，有时候出现了格式混乱为非法http报文导致web服务端无法正常解析和响应。

这个case是因为在cline上看到一个web服务端响应无法识别的错误，如下图所示：

因为此mcp server已经有UI页面，经过排查在burp上面看一下报文明显红框少了一个空格导致HTTP报文格式不对：

解决办法就是让大模型学习一下HTTP报文的格式，然后重新调用mcp tools 发现OK：

大模型准确调用tools问题

这里主要有2类问题：大模型正确调用tools 和大模型正确顺序执行tools。

首先第一个大模型MCP的共性问题。此问题出现在大模型调用mcp tools失败或者返回的结果不符合预期的时候，大模型和客户端会存在温度问题：

在我再次提示错误以后，大模型自作主张的添加一个名叫includeDetails的参数：

再次提示：

终于执行成功：

从目前的实际操作来看，解决方案是尽可能的在调用tools之前需要尽量精确的提示词，以及在对tools的编码的时候对inputSchema、description尽量准确描述。

第二个正确顺序执行tools的问题表现为在前面的提示词中，理想情况是大模型在调用一次安全漏洞检测tool后，会顺序执行安全漏洞上报tool。但是非常不幸的是在我把整个流程都开启Auto Approve后发现安全漏洞检测tool执行了10次，但是安全漏洞上报tool只执行了2次。也就是说大模型并没有在每次做了安全检测后都上报本次payload是否存在安全漏洞。

此问题的解决办法目前是强化提示词，例如：

调用burp-kotlin-mcp-server的工具获取所有的http消息的历史记录，同时分析每个请求是否可能存在sql注入漏洞，如果可能存在，在尽可能的生成足够多和不同的的payload以后原始的请求里面插入payload以后直接返回修改后的请求,当然如果payload是插入到url的query参数里面那么必须进行url编码，并将请求通过burp-kotlin-mcp-server的工具发送回去。同时在接收到修改后的http报文的响应后根据想要判断是否存在安全漏洞，并调用工具上报是否存在对应的安全漏洞。这个过程需要循环执行，直到根据响应可以判断存在安全漏洞。

需要强调的时候，每次执行漏洞检测工具后，都要顺序执行漏洞上报工具。

HTTP报文二次加密问题

在实际测试过程中发现部分流量里面的参数都经过了二次加密，那么大模型在为这些参数插入payload之前就必须要要进行二次加解密，但是实际上大模型并不知道加解密算法以及秘钥等信息导致无法正确的插入payload。

此目前暂时还未进行探索和解决，遗留中......

优势与不足

从文章的前面部分可以看到大模型MCP在web漏洞挖掘方案的优势和不足都还是比较鲜明的。

优势总体来说：MCP 智能体可以调用工具、发起 API 请求、处理数据、并运行面向用户的工作流。

• 相比传统扫描器，大模型可以一次性在报文多个地方（包括URL里面的query参数，body里面的参数等大模型认为存在漏洞的地方）插入足够多的payload。
• 相比传统扫描器，受限于研发或者作者对安全的理解payload总是有限。大模型在学习和训练的工程中相比传统扫描器，大模型收集的payload足够多。
• 相比传统扫描器，大模型可以智能根据响应的不同来判断是否攻击成功。

不足点以及待需要改进点在前面的困难与挑战中其实已经详细分析过，这里不再做过多介绍。

这里还有一点，因为大模型需要理解输入和输出，在速度上面相比传统扫描器要慢一些。大模型的每一个payload执行的完整流程都需要5s左右，相比传统扫描器实在太慢。

进一步拓展

在实际的日常工作中，进一步探索在历史流量中发现web安全漏洞。

• 在日常攻防演练中如果存在大量资产则可以使用AI+burp对资产进行指纹识别和历史漏洞探测+弱口令检测，省去一大笔时间，非常方便实用。
• 目前想到能够比较好落地的web安全漏洞类型主要存在于越权、sql注入等可以直接从响应里面做判断的漏洞模型场景。

来源  |  阿里云开发者公众号

作者  |  胡波