艾体宝方案 | 从AI模型到云生态：构建系统化的企业AI安全管理体系【系列文章（4）】
随着人工智能（AI）技术的不断进步和广泛应用，AI已经渗透到金融、医疗、制造、自动驾驶等多个行业。尽管AI带来了巨大的创新和效率提升，但随着其应用范围的扩大，AI的安全性问题也逐渐暴露出来。AI应用安全不仅仅局限于算法模型的本身，更多的是涉及数据隐私、对抗攻击、模型滥用、合规性问题以及垂直行业应用中的特殊风险。因此，企业需要全面识别并应对这些AI应用中的潜在风险，构建健全的AI安全管理体系。一、AI应用安全的核心挑战AI应用的安全风险源自多个层面，既包括算法层面的风险，也涉及数据、系统、法律等多维度的安全隐患。1.1 AI模型算法滥用风险随着AI生成内容的普及，模型算法的滥用已成为迫切需要解决的安全隐患。特别是在生成式AI领域，AI模型可能被用来生成虚假信息、深度伪造内容等，直接影响社会舆论，甚至对企业造成直接经济损失。虚假有害信息的传播：生成的AI内容可能被恶意用于传播虚假信息、误导公众、制造恐慌或进行欺诈活动。例如，某些不法分子利用AI生成的新闻报道或虚假视频，制造社会不稳定因素。多模态深度伪造的风险：深度伪造技术融合了视频、音频、文本等多模态内容，生成高度逼真的虚假信息。这类攻击不仅可能带来经济损失，还会破坏公众的信任基础，影响法律和社会规范的实施。模型透明性不足：AI应用在实际运行中，许多模型尤其是复杂的深度学习模型，往往缺乏足够的透明度，用户无法理解模型的决策过程。这种“黑箱”性质不仅增加了用户的使用风险，也使得当出现错误决策时，问题难以被迅速定位和解决。1.2 AI应用开发安全风险AI应用开发不仅仅是技术问题，还涉及硬件、软件以及协同环境的整合，这就使得AI开发中的安全风险更加复杂和多样化。端侧AI安全风险：在边缘计算环境中，由于端侧设备的硬件限制，AI模型可能需要进行压缩或优化，这样的处理虽然可以提升运行效率，但也可能导致模型的鲁棒性和安全性下降，出现性能下降或“安全税”现象。此外，端侧部署通常要求在设备端实现实时推理，并依赖云边协同架构进行模型更新和任务调度，这也带来了异构硬件兼容性和网络延迟等潜在风险。智能体的安全风险：AI智能体是由AI模型驱动的自主系统，能够执行复杂任务。随着AI智能体与外部环境的不断交互，智能体的安全风险也在增加。攻击者可能通过篡改协议或利用自主决策链路的不可预测性，导致智能体做出错误决策，从而产生安全漏洞。具身智能的安全隐患：具身智能涉及到现实世界中的物理行动，其安全风险不容忽视。传感器设备可能泄露个人信息，具身智能体的物理行为可能被恶意攻击者控制，从而导致人身伤害或财产损失。例如，服务机器人操作不当，或自动驾驶汽车发生事故，都是具身智能安全风险的典型表现。智能物联网（AIoT）安全：智能物联网设备融合了AI算法与物联网的物理特性，部署在受限的边缘环境中，面临着传感器噪声、物理攻击、以及复杂环境干扰等问题。与传统物联网设备相比，AIoT还面临着AI特有的安全威胁，如对抗样本攻击、训练数据投毒和模型窃取等问题。1.3 AI垂直行业应用的安全风险AI技术在垂直行业的应用，虽然带来了行业的革新，但也带来了独特的安全风险。不同的行业面临的AI应用安全问题各具特点。AI在医疗行业的安全风险：AI在医疗领域的应用极大地提高了诊断效率和精确度，但也伴随着巨大的技术与伦理风险。训练数据的偏差、系统漏洞可能导致医疗设备发生错误，甚至误诊。此外，AI系统在处理敏感的患者信息时，若未采取充分的加密与权限管理，可能会导致患者隐私泄露，进而带来法律与伦理上的问题。AI在新闻领域的滥用风险：随着AI生成内容技术的普及，新闻行业面临着虚假新闻传播的风险。某些不法分子可能利用AI模型生成虚假报道、伪造证据，借此操纵舆论或进行诈骗活动。如何确保生成内容的真实性与可信度，成为新闻行业亟待解决的安全挑战。AI在金融行业的安全风险：金融行业的AI应用包括身份验证、交易监控等多个方面，面临着深度伪造技术带来的身份验证问题。攻击者通过深度伪造技术伪造身份信息，可能突破金融机构的身份核查系统，实施盗刷或恶意注册等欺诈行为，造成极大的经济损失。AI在编程领域的安全风险：AI辅助编程不仅提高了开发效率，但也带来了代码安全隐患。AI生成的代码可能存在常见漏洞（如SQL注入、跨站脚本攻击等），同时AI生成的代码缺乏架构设计，可能导致后期维护困难。由于过度依赖AI生成的代码，开发人员可能减少了必要的人工审查，从而放大了潜在的安全风险。二、AI应用安全的解决方案与应对措施针对上述AI应用中的安全风险，企业需要采取多维度的防护措施，构建全方位的AI安全管理体系。2.1 提高模型的鲁棒性和透明性为了应对AI模型的滥用风险，企业应加大对AI模型的鲁棒性和透明度的建设。例如，采用对抗训练增强模型的抗干扰能力，采用可解释性AI（XAI）技术提升模型的透明度，帮助用户理解决策过程，从而降低不当信任的风险。2.2 强化数据保护与隐私管理在AI应用过程中，数据是最核心的资产之一。企业应实施数据加密、访问控制、数据脱敏等技术，确保数据的隐私性和安全性。此外，企业应遵守相关的法律法规，如GDPR等，确保数据使用的合法合规。2.3 强化安全检测与监控企业需要在AI模型开发与应用过程中加入安全检测与监控机制，实时发现潜在的安全隐患。例如，利用自动化工具扫描AI模型的依赖组件，识别潜在漏洞，及时修复，并部署AI安全监控系统，实时监控模型的运行状态和异常行为。2.4 建立合规性框架AI应用不仅要在技术上保障安全，还需要满足法律法规的合规性要求。企业应构建全面的AI合规性框架，制定AI应用的合规性审查标准，确保AI技术在法律法规框架下运行。三、艾体宝Mend价值Mend通过其全面的软件组成分析（SCA）与依赖治理功能，在模型安全方面发挥了关键作用，帮助企业应对AI模型开发、训练、部署和维护过程中面临的安全挑战。具体价值体现在以下几个方面：3.1 识别和治理AI应用依赖中的安全风险AI应用往往依赖于多个开源库和第三方组件，而这些组件可能带有安全隐患。Mend通过自动化的SCA工具，能够深入识别和分析AI应用中所依赖的开源库及第三方组件，实时扫描每个依赖组件的安全风险。无论是AI平台、训练框架、容器镜像，还是MLOps流水线中的每一层，Mend都能够精确检测出潜在的漏洞、许可证问题和版本不兼容等安全风险。企业可以借助Mend的实时扫描功能，提前识别并解决这些隐患，避免将不安全的依赖组件引入AI应用，从而减少因依赖漏洞带来的应用安全风险。3.2 构建透明的SBOM体系，确保合规性AI应用不仅需要从技术层面防护，还必须符合相关的合规要求。Mend帮助企业构建和管理全面的安全SBOM（软件物料清单）体系，生成覆盖整个AI应用栈的SBOM清单。这一清单为合规审计、漏洞报告和监管备案提供了透明和准确的数据支持。通过Mend的SBOM工具，企业能够清晰地掌握AI应用中每个组件的来源、版本及其安全状况，从而确保模型和应用的安全性与合规性，避免因信息不透明而引发的法律和合规问题。通过这种全面的管理，Mend帮助企业在复杂的合规环境中确保AI应用的合法性与合规性。3.3 防范对抗攻击与漏洞利用Mend通过对AI模型进行真实的红队模拟交互，模拟攻击者的行为，测试模型对恶意输入、提示词注入以及其他对抗攻击的防御能力。Mend通过模拟各种可能的攻击情境，实际验证模型在面对各种恶意输入时的响应能力和稳定性。通过这种方式，Mend能够识别出潜在的安全漏洞，并提供针对性的防御策略，帮助企业提前发现并修复可能被攻击者利用的弱点。
【论文分享】从噪声到信号：如何在千万级软件包中精准定位漏洞影响？
一、引言：软件供应链安全的”狼来了”困境想象这样一个场景：你是一名开发者，每天打开 CI/CD 系统，迎接你的是数百条安全警报——”检测到依赖包存在高危漏洞，请立即修复！” 但当你花费大量时间逐一排查后却发现，绝大多数警报都是虚惊一场：那些所谓的”漏洞代码” 根本就没有被你的应用调用。这种”警报疲劳”已成为软件供应链安全领域的痛点，也是众多安全检测工具难以实际落地应用的重要原因。这正是奇安信技术研究院和清华大学研究团队在 NDSS 2026 会议上发表的论文所要解决的核心问题。论文题目为《From Noise to Signal: Precisely Identify Affected Packages of Known Vulnerabilities in npm Ecosystem》，作者为蒲应元（奇安信星图实验室），应凌云博士（奇安信星图实验室）和谷雅聪博士（清华大学）。这项研究针对全球最大的开源软件生态系统——npm（拥有超过 300 万个包，2024 年处理了约 4.5 万亿次请求），提出了一套基于函数调用关系的细粒度漏洞传播关系识别方法和分析框架。论文分析结果表明，传统工具所产生的漏洞警告中，高达 68.28% 都是”噪声”，即漏洞代码实际上根本无法被触达。二、问题的本质：为什么传统方法会产生如此高的误报？npm生态系统的复杂性源于其极度碎片化的包依赖结构。已有研究显示，约四分之一的npm包版本依赖于存在已知漏洞的包。以 pac-resolver为例，这个每周下载量达 300 万次的 npm 包曾曝出高危远程代码执行漏洞，导致 GitHub 上超过 28.5 万个公共仓库可能面临风险。但问题的关键在于：依赖存在漏洞的包，不等于你的应用真的受到影响。当前主流的软件成分分析（SCA）工具，如npm audit、GitHub Dependabot等，都采用包级别的分析方法。它们的逻辑很简单：如果你的依赖树中存在包A的v1.0版本，并且包A的v1.0版本存在漏洞，则发出警报提醒你的应用受到影响。 但这种粗粒度分析忽略了三个关键问题：未使用的依赖：你的 package.json 声明了依赖，但代码中从未引入（require/import）该包的任何模块；浅层的 API 使用：即使引入了包，可能只使用了其中若干个函数，而漏洞函数根本未被调用；传递性衰减：通过多层依赖传递时，每一跳的使用范围都在缩小。理论上，函数级可达性分析是最佳解决方案——只有当存在从应用入口到漏洞函数的调用路径时，才认为应用真正可能受到影响。但在 npm 生态实施函数级分析面临三大技术挑战：首先是可扩展性挑战：传统方法需要为每个项目构建完整的调用图（Call Graph），也包含其所有依赖，对于复杂项目，依赖数量可达数百甚至上千个包。每次分析都要从头开始，计算成本呈指数级增长。其次是 JavaScript 的动态特性带来的程序分析挑战。极其灵活的语法特性为静态分析制造了诸多盲区：代码中广泛存在的动态属性访问（利用变量而非字面量调用函数）、将函数作为参数传递的高阶函数机制（回调），以及允许在运行时动态修改对象原型链的特性，都让静态分析器难以在运行前确定具体的调用目标和完整的控制流，从而极易导致依赖分析链路的断裂或缺失。具体代码示例如下：// 动态属性访问 obj[propName](); // propName是变量，静态分析难以确定调用目标 // 高阶函数 function process(callback) { callback(); // 不知道传入的是哪个函数 } // 原型链动态修改 ，增加了分析的不确定性 Object.prototype.newMethod = function() { ... }; 最后，JavaScript 语言模块系统的复杂性进一步加剧了分析难度：CommonJS (require)和 ESM (import/export) 不同的模块机制、module.exports对象可在运行时修改，以及require()的参数可以是动态表达式 ，这些都进一步加剧了分析难度。三、VulTracer的核心设计和解决方案面对这些挑战，我们设计并实现了 VulTracer 这个分析框架。它的核心洞察在于：npm包一旦发布就不可变，因此可以为每个包预计算可复用的分析结果。这开启了”分析一次，复用多次”的新范式。VulTracer 将传统的整体式分析分解为三个独立阶段，核心设计和架构如上图所示。以下将详细介绍每一个部分的设计逻辑和细节。3.1 富语义图生成 (RSG Generation)首先，VulTracer 利用程序静态分析技术，为每一个包构建了一个富语义图（Rich Semantic Graph, RSG）。这张图不仅看清了包内部的函数调用脉络，更关键的是，它显式地刻画了包的“边界”——哪些函数被暴露给了外部，又有哪些地方调用了外部依赖。传统的调用图（Call Graph）只记录”谁调用了谁”，而RSG设计了一个多层次的图结构，完整保留包的边界信息，图中的实体结构和详细定义如 下图 DEF1 所示，包含了三类不同的顶点集合和边集合。3.2 接口契约提取 (Interface Contract Extraction)虽然 RSG 保留了包的全部内部细节，但如何让独立分析的包能够正确”对接”？这就涉及到了提取形式化的接口契约。VulTracer 从这张复杂的图中提取出了一份简洁的形式化接口契约（Interface Contract）。这就像是给每个软件模块定义了标准的“插头”和“插座”，契约中清晰地记录了 API 的导出方式（Export Manifold）和导入方式（Import Manifest）。这一步至关重要，它充当了一道“语义防火墙”，屏蔽了复杂的内部实现细节，只保留了交互所需的关键信息。具体的定义如下图DEF2 所示。3.3 拓扑排序驱动的按需组合式合成 (Compositional Synthesis)最后，当需要检测某个具体项目时，VulTracer 不再需要深究源代码，而是像拼乐高积木一样，根据依赖关系，将预先计算好的 RSG 和契约进行组合式合成（Compositional Synthesis）形成一个新的生态级调用图 (ECG)。并且该 ECG 可根据任意真实项目的依赖关系按需组装。这种设计使得分析速度和扩展性得到了质的飞跃——在处理复杂的真实依赖图时，VulTracer 的成功率高达 99.41%，而对比的工具Jelly仅为 37.37%。四、生态级实证研究：揭示漏洞传播的真相在这项工作中，我们利用 VulTracer 对整个 npm 生态进行了史上最大规模的函数级漏洞传播影响分析。4.1 数据集构建首先我们构建了两个核心的数据集：npm 生态数据集： 包含了 3,267,273个唯一npm包 以及其 34,685,976 个不同版本 。同时解析并构建了整个生态中超过9亿条的依赖关系。漏洞数据集：我们采用双维度选择策略，确保选择的漏洞样本既有代表性又有多样性。一是高影响力漏洞，从 2024 年下载量排行 TOP 10 的软件包 lodash, debug, semver, minimatch 这四个核心库中，找到了影响他们的6个CVE漏洞，每个软件包都有数十万直接依赖包，并且漏洞影响了超过百万的下游软件包。二是多样性维度，对齐 2024 CWE-Top-25 的类型，覆盖注入(CWE-79)、原型污染(CWE-1321)等21个不同类型的 CVE 漏洞，代表不同的攻击向量。最终我们的研究涵盖了27个CVE，涉及9,868,514条潜在传播路径。4.2 单跳分析：分析衰减的根本原因我们首先聚焦于d₁ → d₀的单跳关系，这样可以排除多跳传播的复杂因素，精确归因。在我们的研究中建立了三层漏洞传播条件：仅引入模块 (C_mod)、调用任意函数 (C_func)、调用漏洞函数 (C_vuln_func)。定义如下图所示：只有 C_mod ∧ C_func ∧ C_vuln_func 同时为真，才认为漏洞真正传播。最终单跳的分析结果如下表所示。我们发现平均 22.80% 的直接依赖包声明了依赖，但从未导入任何模块（C_mod失败）。以 lodash 为例：存在 396,112 个声明依赖的包，但是有 131,933个”僵尸依赖” (33.31%)。这13万多个包背上了”有漏洞”的标签，但实际上完全不受影响。同时我们还发现，npm 第三方库的 API 设计决定传播率。同样的对于 lodash 这样一个综合工具库，拥有242个函数，但漏洞函数 template 只占所有调用的0.30%，排名第49位，详细分析如下图所示。说明这个函数的下游使用率并不高。与之相反的是 debug 库，它功能单一专注于调试，其核心功能函数就是其主函数，导致直接依赖者的受影响比例高达 71.77%。4.3 多跳分析：揭示传递性衰减规律单跳分析揭示了初始衰减，但漏洞会通过传递依赖传播多远？我们追踪了完整的传播路径。在分析中，我们追踪了9,868,514条潜在传播路径，涉及1,663,634个包版本。 最终不同漏洞的传播结果如下表所示。在表格数据中， 以 CVE-2022-3517 (minimatch) 为例，数据揭示了粗粒度分析带来的严重误报问题。包级别分析报告了 497,595 条潜在传播路径，涉及 286,731 个受影响的包版本。然而，经由 VulTracer 的函数级可达性分析，确证受影响的包版本仅为 22,557 个。从全局统计维度来看，函数级分析所识别的受影响库数量平均仅为包级别分析结果的 31.72% 。这一数据统计表明，现有包级别依赖扫描工具产生的警报中，约 68.28% 属于漏洞代码不可达的误报（False Positives）。最后，在上图也更进一步可视化了漏洞传播随依赖链路深度的衰减过程，分别从两个不同的视角来进行呈现。图（a）展示了每一跳（Hop）中新增受影响包数量的分布情况。对比显示，函数级别（红色曲线）的传播在 3 跳之后呈现出急剧的衰减趋势，与包级别（蓝色曲线）的长尾分布形成显著差异。这证实了真实的漏洞影响范围会随着依赖深度的增加而迅速减弱。而图 （b） 展示了传播过程中的累积概率分布情况进一步佐证了这一“浅层效应”：函数级传播曲线迅速收敛并达到平台期，数据显示 96.59% 的真实受影响包均收敛在 4 跳 的范围内。这意味着，尽管依赖图谱可能具有较深的层级结构，但具有实际威胁的漏洞传播主要局限于浅层依赖网络中。五、结论：从噪声中提取信号面对日益复杂的开源生态，我们的研究证明，传统的“版本比对”模式已经难以为继。由现有包级别工具识别出的潜在风险中，高达 68.28% 的漏洞代码实际上从未被调用 。换言之，近七成的“受影响”项目其实是安全的，并不需要火急火燎地去修复。这种高误报率不仅制造了巨大的“噪声”，更导致了严重的警报疲劳，反而掩盖了真正的威胁。因此，转向更细粒度的函数级可达性分析已是行业必经之路。通过 VulTracer，我们可以从噪声中提取出那 30% 的真实信号。这不仅能让开发者从无效的运维工作中解脱出来，更能让安全团队聚焦于真正具有可利用性的威胁。这才是让供应链安全治理走出困境、迈向精准防御的未来方向 。学术动态, 技术报告供应链安全, 论文分享 2026年1月6日2026年1月6日
补齐SDLC最后一块拼图：LLM 在应用安全中的实践探索
导语随着 DevSecOps 的不断推进，应用安全已被广泛纳入SDLC的各个阶段。然而，在代码扫描、依赖分析、漏洞检测等能力逐步成熟的同时，一个长期存在却难以解决的问题始终横亘在安全工程实践中：安全工具“能发现问题”，却难以判断问题是否真实、是否可利用、是否值得优先处理。大量规则驱动的扫描结果不仅带来了高误报率，也持续消耗着研发与安全团队的精力。近年来随着大语言模型（LLM）的快速发展，为这一困境提供了新的可能。不同于传统规则或静态特征匹配，LLM 在语义理解、上下文推理和条件组合分析方面展现出独特优势，使其具备参与安全“判断层”的潜力。将 LLM 引入 SDLC，不再只是生成代码或辅助文档，而是尝试参与到安全结果的理解、验证与决策之中。本文结合实际应用安全建设经验，围绕 LLM 在 SDLC 中的落地实践展开，重点探讨其在硬编码、SCA、漏洞挖掘等场景中的应用方式与工程化思路。SDLC 应用安全流程SDLC名词解释 SAST（静态应用安全测试）通过对源代码或编译产物进行静态分析，在不运行系统的情况下发现潜在的安全缺陷，如 SQL 注入、XSS、不安全函数调用和硬编码敏感信息等，适合在开发阶段提前发现问题。 SCA（软件成分分析）聚焦于项目中使用的第三方开源组件，识别依赖库及其传递依赖中已知的安全漏洞、风险版本和许可证问题，帮助团队降低因外部组件引入的安全风险。 DAST（动态应用安全测试）在系统运行状态下，从攻击者视角对应用进行测试，通过捕获流量包修改参数重放，模拟真实攻击行为验证系统是否存在可被实际利用的漏洞，如注入攻击、未授权访问等 硬编码（Hard Coding），是指在程序中直接把固定的值写死在源码里，而不是通过配置文件、环境变量等方式获取，比如下面这些情况，都属于硬编码：用户名、密码、token或加密密钥等 为什么我们需要SDLC？产品一句话需求 → 开发自己理解 → 按照个人习惯去开发 → 功能上线后出现大量漏洞 → 被外部利用造成损失而SDLC要做的就是把漏洞扼杀于摇篮之中，而不是靠后期凭经验渗透测试发现。但目前传统的SDLC存在大量告警/误报，推送大量工单给研发会导致业务间摩擦度增加，因此理想情况是把真正需要修复的工单交给研发处理硬编码规则下引入AI判断，减少误报问题背景：目前硬编码扫描是根据规则的正则匹配，存在一定的局限性和误报整体流程结合硬编码规则 + AI 判断保留高召回，同时降低误报率硬编码规则先行使用固定规则（正则、逻辑判断）先筛掉明显非风险项，让 AI 只处理模糊/不确定案例AI 判断做辅助只对硬编码规则未覆盖、可疑的候选项输出风险判断，输出结果可附置信度或分类标签置信度 + 白名单控制AI 输出带置信度，低于阈值直接忽略，对常见合法值、默认值设置白名单提示词 promot通过定位文件的位置，结合上下文判断实际风险等级，把AI分析结果输出你是一个资深应用安全专家，精通代码安全、凭证泄露、真实攻击利用分析。 现在给你一个【疑似硬编码凭证】的扫描结果，请你进行【可利用性研判】。 输入信息如下（JSON）： %s 请严格按以下维度进行分析： 1. 该硬编码是否为真实敏感凭证 2. 是否存在被外部攻击者利用的可能 3. 是否依赖运行环境 4. 泄露后的安全影响 5. 修复建议 请以 JSON 格式输出分析结果 模型输入字段释义 字段 释义 match 匹配到的硬编码内容（部分脱敏显示） rule key类型 path 硬编码所在的完整文件路径 branch 分支 code 上下5行代码 增加输出长度，避免截断"extra_body": map[string]interface{}{ "think_mode": true, "max_output_tokens": 1024, 实现效果如果是走正常的流程，secret_value会被 generic-api-key规则名字标记严重程度为medium开启AI分析选项后，通过定位文件的位置，结合上下文交给ai分析，AI判断实际危害程度为低在代码中发现硬编码的敏感信息'DEMO_SECRET'，其值为'secret_value'。根据规则'generic-api-key'，这可能是一个API密钥或其他类型的敏感凭证。该变量位于'E:\SDLC平台\backend\uploads\demo.py_scan\demo.txt'文件中，并且注释表明它看起来像一个Key，但无实际用途。由于这是一个测试环境中的示例代码，风险相对较低。 掩码输出硬编码片段代码中存在：const apiKey = "sk_live_9f83a0b7..."AI分析后会直接原样输出，给出完整的佐证片段，这样是不符合数据安全合规要求的，就会产生 二次扩散风险。正确掩码后的做法，AI 只需知道这是一个硬编码密钥const apiKey = "*MASKED_SECRET*"实现效果通过 AI 研判对硬编码、潜在风险及非生产路径问题进行自动识别与筛选，各产品待修复量平均下降约52.8%价值体现：在保证安全覆盖率的前提下，AI 自动化研判显著提升效率，降低人工排查压力，推动安全研判进入智能化阶段 AI 判断为 False：AI 判定为误报，可直接关闭 AI 判断为 True 但 NonLive：问题真实但不在生产路径，可降低风险等级处理 AI 研判后待修复：确认真实且影响生产，需进入修复流程 SCA可利用性与真实风险判断从官方文档 https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components 描述可看到，涉及版本都需要更新到对应补丁但从甲方安全运营的角度会存在以下这些问题：1.大版本的更新会存在项目兼容性问题，不好推进2.涉及仓库数量较多，如果全部同时进行整改将会是极大的工作量如果我们深入分析后会发现，并不是在版本范围内就存在漏洞，还需要额外的条件满足才能利用客户端请求 Server Action ↓ 执行 Server Action (接收用户输入) ↓ react-server-dom-webpack 序列化响应 ↓ 【漏洞点】反序列化时未正确验证输入 ↓ 恶意 payload 被执行 → RCE 必要利用条件 条件 是否必须 说明 App Router ✅ 必须 提供 RSC / Flight 机制 Server Actions ✅ 必须 提供反序列化入口 用户可控输入 ✅ 必须 构造恶意 payload 整体流程 核心思路：证明SCA漏洞代码是否被业务代码真实调用，如果不可达那么这个SCA漏洞在该仓库就不可利用 调用链路：业务代码中是否存在外部可控输入→ 漏洞组件危险函数的真实可达路径 HTTP 请求 (scaHandler) -- 输入CVE编号 ↓ CVE 分析 (runSCACVEAnalysis) ├─ 步骤 2.1: Google 搜索受影响版本 ├─ 步骤 2.2: Qwen 识别依赖组件搜索官网信息 ├─ 步骤 2.3: 搜索引擎寻找对应PoC ├─ 步骤 2.4: Qwen 提取结构化信息 └─ 步骤 2.5: Claude 最终安全分析 ↓ 仓库分析（可选） ├─ 方法一: 依赖分析 (analyzeRepositoryVulnerability) └─ 方法二: 锚点分析 (analyzeRepositoryWithAnchor) google搜索引擎调用调用google进行联网搜索，局限性 key限制每天100个https://console.cloud.google.com/apis/credentials凭证-创建凭证启用custom search apihttps://programmablesearchengine.google.com/controlpanel/create在这个地方可以定义调用的搜索引擎优化阶段1：多个源进行信息整合导致出错初步阶段测试发现，Qwen去重整理逻辑导致结果出现缺失因此后续直接选用官方源，保证结果数据的准确性官方情报来源 序号 来源机构 描述 链接 1 美国国家漏洞数据库 (NVD) 官方 CVE 条目，包含漏洞详情、受影响版本、CWE、CVSS 等信息 https://nvd.nist.gov 2 CVE 官方记录 (CVE.org) 官方 CVE ID 登记与记录 https://www.cve.org 3 React 官方安全公告 (React Team / Meta) 官方漏洞公告及修复版本说明 https://react.dev 4 加拿大网络安全中心 (Cyber Centre) 官方安全公告、漏洞说明 https://www.cyber.gc.ca 5 Google Cloud 官方博客 官方补丁指引及响应措施 https://cloud.google.com 优化阶段2：未关联间接受影响组件导致结果不准在漏洞受影响的范围很多都只提及了react组件，但是有其他间接依赖组件如next也会受到影响，因此在爬取网站内容需要把这部分信息也整理进来虽然应用使用了受影响的 React 版本（19.0.0）并启用了 React Server Components 功能，但 React Server Components 的漏洞版本范围是 19.0.0-19.2.0，而当前仓库使用的是 react-server-dom-webpack 19.0.0。关键问题是该仓库使用的是 Next.js 16.0.6，而 CVE-2025-55182 主要影响独立的 React Server Components 实现，Next.js 有自己的 Server Components 实现机制，不直接受此 CVE 影响。条件1不满足，因此漏洞不可利用 优化阶段3：规范性提示词输入这里有三个关键点：将「CVE 知识」作为输入，而不是让 LLM 自行理解 不依赖模型对 CVE 的主观理解或记忆 由安全侧明确提供：漏洞成因和可利用条件链（Exploit Preconditions） 避免模型自由发挥导致的误报或信息污染 在目标代码仓库中，验证漏洞可利用条件是否成立 不做漏洞解读 不做风险定级臆断 不基于版本号直接下结论 将每个 CVE 拆解为一组必须同时满足的利用条件 逐条在仓库中进行验证：任一关键条件不满足 → 漏洞不可达，不构成真实风险 代码结构、依赖使用情况及配置与对外暴露面 最终提示词你是一名资深应用安全分析师。请基于我提供的 SCA 扫描结果，对发现的第三方组件漏洞进行【汇总型安全分析输出】，输出需包含以下部分（使用简体中文）： 1. 漏洞基本信息 - 受影响组件 / 编程语言 / 版本 - CVE 编号 - 漏洞类型 2. 漏洞原理说明 - 从安全分析视角解释漏洞成因 - 重点描述漏洞触发机制（如反序列化、解析、路由处理等） - 对未公开的内部实现需明确说明"细节未披露"，避免推测 3. 影响评估 - 可造成的安全影响（如拒绝服务、信息泄露等） - 对业务连续性、系统稳定性和可用性的潜在影响 4. 攻击前置条件 - 环境条件（框架、运行模式、功能开启情况等） - 依赖条件（受影响的第三方组件） - 攻击者权限要求（是否需要认证、是否可远程触发） 5. 涉及模块或组件范围 - 受影响的框架模块或依赖包名称 - 若具体函数或代码位置未公开，需明确说明 - **必须列出所有依赖关系**：如果漏洞影响底层组件，必须说明哪些上层框架/库可能间接受影响，包括具体的组件名称和受影响版本范围 6. 可利用性与 EXP 情况说明 - 是否存在已公开的 PoC / EXP - EXP 的公开来源类型（如 GitHub、安全研究博客等） - 利用复杂度与稳定性评估（概念验证 / 可重复利用 / 条件受限） - 输出poc/exp 7. 修复与缓解建议 - 官方推荐的修复方式（安全版本升级 / 官方补丁） - 可选的临时缓解措施（如限制接口访问、WAF、防护策略等） 8. 验证与复现说明（高层级） - 给出验证思路而非攻击步骤 - 描述在存在漏洞情况下的典型现象（如服务挂起、资源异常） 9. 信息来源说明 - 明确标注信息来源类型（NVD、官方博客、安全公告、PoC 仓库等） - 不编造或推测来源 - **重要**：references 字段必须包含完整的 URL（以 http:// 或 https:// 开头），例如： - 正确：https://github.com/msanft/CVE-2025-55182 - 错误：github: msanft/CVE-2025-55182 或 github.com/msanft/CVE-2025-55182 - 如果搜索结果中有链接，必须提取完整的 URL 格式 输出风格要求： - 安全评估报告风格 - 用词克制、客观、中立 - 不渲染攻击效果，不放大风险，不自主推测 - 优先使用官方来源信息，避免"未确认"或"可疑"的评估 漏洞分析示例1：CVE-2025-55182受影响的系统情况app-router-vulnerable/app/api/action/route.ts'use server' export async function testAction(formData: FormData) { const data = Object.fromEntries(formData) return { message: 'Server action executed', data: data } } 使用 App Router 并启用了 Server Actions 的应用系统，受CVE-2025-55182影响 ✅ 使用 app/ 目录（App Router 结构） ✅ 接收 FormData 作为参数 ✅ 使用 react-server-dom-webpack 进行序列化/反序列化 不受影响的系统情况 ❌使用 pages/ 目录（Pages Router 结构） ❌不使用 Server Actions ❌不依赖 React Flight Protocol 序列化 使用 Pages Router 的 Next.js 应用，即使引入同样处于受影响范围内的版本，也不受 CVE-2025-55184 漏洞影响，ai分析结果符合预期漏洞分析示例2：CVE-2021-44228受影响的系统情况环境情况： Log4j 版本：2.14.1 （漏洞影响范围内）⚠️ JNDI：✅ 允许 网络：✅ 可访问 LDAP / RMI 综上所述，满足漏洞触发条件，因此AI研判该仓库受影响不受影响的系统情况环境情况： Log4j 版本：2.14.1（漏洞影响范围内）⚠️ JNDI：❌ 被禁用 网络：❌ 无法访问外部 LDAP 虽然在漏洞版本内，但是-Dcom.sun.jndi.ldap.object.trustURLCodebase=false ，因为${jndi:...} 被禁用不会被解析AI 分析判断仓库不受影响，符合预期模型费用对比及选择根据官方获取定价数据：https://platform.claude.com/docs/en/about-claude/pricing?utm_source=chatgpt.com在选择前首先我们要定义模型好坏的标准，从数据表现出发而不是个人主观经验判断如果追求 准确率 可以选择claude-sonnet-4@20250514，追求 性价比 但又有不错的准确率可以选择gemini-2.5-flash 项目 3 5 6 7 8 使用模型 gemini-2.5-pro claude-sonnet-4@20250514 claude-haiku-4-5 Qwen2.5-Coder-14B gemini-2.5-flash 准确率 95% 100% 87.50% 75% 87.50% 单个 CVE 分析平均费用（USD） 0.33 0.69 0.19 -- 0.08 白盒代码审计存在的难点 代码文件很长 需要多文件上下文结合分析 需要精确定位行号、变量流、调用链 上述这些问题都会导致大量的token消耗，其他chat型大多数每一轮 = 重新塞一堆代码进 prompt模型选择Cursor 最大优势：通过索引 + 增量上下文，节约 token 消耗，适合多轮、持续审计最关键的一点是，他是按照提问次数来计费的，它把一次提问变成了一次完整的白盒审计任务执行 维度 / AI ChatGPT (Web/API) Claude Gemini GitHub Copilot Cursor 上下文获取方式 手动粘贴文件 手动粘贴 / 长上下文 手动粘贴 IDE 补全 自动索引 + AST 重复 token 消耗 高 高 中 中 极低 多轮审计成本 指数级上升 高 高 中 平稳 / 增量消耗 跨文件调用分析 手动复制 手动复制 中 弱 自动关联 白盒审计推荐度 ⭐⭐⭐ ⭐⭐⭐ ⭐⭐ ⭐ ⭐⭐⭐⭐⭐ 提示词promot明确任务定位让 LLM 清楚自己在做什么，而不是默认行为（如写总结、生成报告），避免 LLM 自动归纳/总结导致丢失重要信息差异。你不是在写安全报告，而是在做“证据整理（evidence collection）”。 你的目标是保留信息差异，而不是消除差异。 使用“反总结”指令通常 LLM 会倾向总结、归纳，在 prompt 中明确要求保留原始信息、对比差异、不要归类。请逐条保留所有原始输入中的差异信息，不要合并或总结条目。 每条信息保持独立输出。 明确输出结构指定输出格式，避免每次输出不统一，便于后续自动化分析/汇总。请按照以下 JSON 格式输出： [ {"source": "文件A", "line": 23, "content": "..."}, {"source": "文件B", "line": 45, "content": "..."} ] 强化“证据导向”提示 LLM 输出时只保留事实，不做主观判断。只提取事实性内容，不要加入主观评论或判断。 标明来源和行号。 分步任务处理对于复杂信息，分步任务处理比一次性要求总结更稳妥，避免分析中断停止，输出更结构化、更精确第一步：提取每个输入文件的独立事件。 第二步：标记事件的时间戳和来源。 第三步：保留所有差异，不进行合并。 根据框架语言输入前置知识不同的语言审计的方法和思路不一样，在让AI分析代码时候需要提供一些前置知识，这能让 AI 更精确地聚焦在“可能的风险点”，而不是泛泛地猜测像SQL注入，不同语言的sink点也不完全相同 语言 方法 / 函数 示例代码 / SQL Golang (*gorm.io/gorm).Where db.Where(StringData).First(&data) Golang (*github.com/jmoiron/sqlx.DB).Queryx db.Queryx(query, params) Java mybatis like select * from users where username like '%${name}%' Java mybatis order by select * from users order by ${orderby} Java mybatis-plus apply wrapper.eq("id", id).apply("username=" + name); Python pymysql execute sql = "select * from users where username = '%s'" % (name) Node.js mysql query sql = "select * from users where username = ${name}" 在Shiro和Spring Security中，可以配置哪些API不需要进行权限校验 在Shiro中，可以使用Shiro的过滤器链（Filter Chain）来配置不需要进行权限校验的API 在Spring Security中，可通过继承WebSecurityConfigurerAdapter类并重写其中的configure()方法，配置不需要进行权限校验的API 像上述的内容可作为前置知识给AI输入，增加其分析的准确性1. web.xml / Spring 配置分析 找出其中配置的可直接前台访问的 .jsp、.do、.action、.html、.json、.servlet 等接口路径。 指明配置项与访问路径的对应关系： web.xml → <servlet-mapping>、<url-pattern> @Controller、@RestController、@RequestMapping 等注解标注的接口 检查是否存在匿名访问的接口（无登录/权限验证拦截）。 检查 Filter、Interceptor、SecurityConfig、WebSecurityConfigurerAdapter 等中是否存在鉴权绕过配置。 2. classes / lib / jar 源码分析 对比 WEB-INF/classes 下的 .class 文件与反编译后的 .java 文件。 对 lib 下的 .jar 文件进行反编译，检查是否包含业务逻辑代码。 逐一分析对应的 Controller、Service、DAO、Repository 层实现： 对应的请求路径（前台/后台） 涉及的外部依赖或第三方库（如 HttpClient、JdbcTemplate、Hibernate 等） 标注潜在的高危点：未校验的用户输入、外部命令调用、文件上传写入、动态 SQL 拼接等。 3. 识别调用链路 标识所有暴露给前端或外部调用者的接口（如 REST API、RPC Endpoint、Controller 方法、Servlet）。 确定入口函数是否为用户完全可控（如 request.getParameter()、@RequestParam、@RequestBody）。 检查系统是否已接入统一认证（如 Spring Security / JWT / OAuth2 / Session）。 深入分析完整调用链： Controller → Service → Repository → 外部系统 判断入口是否存在强约束： 用户归属验证 签名、时间戳、防重放机制 输出是否可以绕过认证或越权。 4. 重点模块审计（前台与后台分开） 重点排查以下常见的漏洞类型： 漏洞类型 漏洞Sink点（常见函数 / 类） 审计描述 SQL 注入 Statement.executeQuery(), Statement.executeUpdate(), JdbcTemplate.queryForList(), createNativeQuery(), EntityManager.createQuery() 检查点：SQL 是否通过字符串拼接、+、String.format、concat 等方式插入用户输入（如 Request 参数）。优先关注 MyBatis 自定义 SQL 与原生 JDBC 使用场景。 命令执行（RCE） Runtime.getRuntime().exec(), ProcessBuilder.start(), ShellUtils.exec() 检查点：是否拼接用户输入到命令中，或允许上传执行脚本。 文件上传 / 任意文件写入 MultipartFile.transferTo(), FileOutputStream.write(), Files.write(), FileUtils.copyInputStreamToFile() 检查点：是否校验扩展名、MIME、目录路径；是否防止 .jsp、.jspx、.java 等脚本文件上传。 反序列化 ObjectInputStream.readObject(), JSON.parseObject(), Yaml.load(), XStream.fromXML() 检查点：是否对外部输入执行反序列化；是否使用存在漏洞的库（如 fastjson < 1.2.83, Jackson 未加白名单）。 任意文件读取 Files.readAllBytes(), FileInputStream, IOUtils.toString(), response.getOutputStream().write() 检查点：是否直接读取用户指定路径；是否存在目录遍历绕过。 路径遍历 new File(), Paths.get(), ServletContext.getRealPath(), File.delete() 检查点：是否存在 ../ 等拼接导致目录逃逸。 XXE（XML 外部实体） DocumentBuilderFactory.newInstance(), SAXParserFactory.newInstance(), XmlMapper.readValue() 检查点：是否关闭外部实体解析；是否解析来自不可信来源的 XML。 SSRF HttpURLConnection, HttpClient.get(), RestTemplate.getForObject(), URL.openConnection() 检查点：是否允许用户指定 URL 并由服务器发请求；是否存在内网访问风险。 XSS response.getWriter().write(), 模板引擎输出 (<%= ... %>, Thymeleaf, Freemarker) 检查点：是否未进行 HTML/JS 输出转义。 认证绕过 / 越权 缺少 @PreAuthorize、@Secured、Session 检查或过滤器逻辑错误 检查点：检查接口访问控制逻辑，是否能直接调用他人资源。 5. 输出结构（每个发现需包含以下部分） 每个发现必须包含以下字段： 风险点名称 漏洞类型 + 影响接口 + 文件路径 漏洞成因 简述代码逻辑错误或输入未过滤的原因。 在net系统中，首先对dll进行反编译，然后让AI去关联路由和实现方法### 审计和输出要求： 1. **web.config 分析** - 找出其中配置的可直接前台访问的 `.ashx``.aspx` asmx ascx 文件。 - 指明配置项与访问路径的对应关系。 2. **bin 目录源码分析** - 逐一对应 `bin` 下的 `.dll` 与其反编译出来的 `.cs` 文件。 - 分析对应的 `.ashx` 或 `.aspx` 、ascx asmx方法实现。 - 如果代码中存在潜在的高危点，需要重点标注 3. 识别调用链路 * (本文件内的路由/XXX 根据情况调整) 函数是暴露给前端或外部调用者的接口（如 API/RPC/Controller），其 request 对象是完全用户可控的 * 当前系统默认已接入统一认证中间件（如 JWT / Session / OAuth2），调用该函数的用户通常已登录 * 需要分析完整的调用链路，包括所有被调用的 Service 层、Repository 层和外部依赖 * 需要判断入口处有强约束（如强校验 user 归属/租户隔离/签名+时效+重放防护） 分析接口是通过什么鉴权的，尝试进行绕过，深入分析所有前台可访问的文件并挖掘漏洞 在项目中搜索所有 ASMX 接口，重点关注是否可匿名调用的未授权端点，并给出利用的wsdl方式和数据包 4.漏洞Sink点 | 漏洞类型 | 漏洞Sink点 | 审计描述 | | ------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | | **SQL 注入** | `ExecuteNonQuery()`, `ExecuteReader()`, `ExecuteScalar()`, `SqlDataAdapter.Fill()`, `ExecuteSqlCommand()`, `ExecuteSqlRaw()`, `CreateSQLQuery()`, `connection.Query()` | **检查点**：查找 SQL 语句是否通过字符串拼接或格式化（`+`, `String.Format`, `$""`）将 `Request/Query/Form/Cookie` 等直接插入。 | | **命令执行（RCE）** | `Process.Start()`, `ProcessStartInfo.FileName`, `ProcessStartInfo.Arguments` | **检查点**：是否把用户输入拼接到命令或传给 shell/PowerShell， `FileName` 与 `Arguments` 是否来自外部 | | **文件上传 / 任意文件写入** | `SaveAs()`, `WriteAllBytes()`, `WriteAllText()`, `FileStream.Write()` | **检查点**：是否校验扩展名、MIME、内容类型、文件名（路径分隔符）、以及保存目录权限；是否防止覆盖已有文件，上传可执行脚本（`.aspx`/`.ashx`）getshell | | **反序列化** | `BinaryFormatter.Deserialize()`, `SoapFormatter.Deserialize()`, `JsonConvert.DeserializeObject()`, `LosFormatter.Deserialize()` | **检查点**：反序列化是否对不可信输入（Request、Cookie、ViewState、文件等）执行；是否使用不安全的序列化库（BinaryFormatter、SoapFormatter） | | **任意文件读取** | `File.ReadAllBytes()`, `File.ReadAllText()`, `Response.WriteFile()`, `Response.TransmitFile()`, `File()` | **检查点**：是否将用户参数直接作为文件路径输出或读取；是否存在未做路径合法化的文件下载接口。 | | **路径遍历** | `Server.MapPath()`, `Path.Combine()`, `File.Delete()`, `Directory.GetFiles()` | **检查点**：路径拼接是否包含未过滤的用户输入；`Path.Combine` 后是否做规范化校验。 | | **XXE（XML External Entity）** | `XmlDocument.LoadXml()`, `XmlDocument.Load()`, `XmlReader.Create()`, `DataSet.ReadXml()` | **检查点**：XML 解析是否启用了外部实体解析（DTD）；是否解析来自不受信任来源的 XML。 | | **SSRF**/远程文件下载 | `WebClient.DownloadString()`, `HttpClient.GetAsync()`, `WebRequest.Create()`, `HttpClient.PostAsync()` WebClient.DownloadFile()、HttpClient.GetStreamAsync()、HttpClient.GetByteArrayAsync()、WebRequest.GetResponseStream() | **检查点**：是否允许用户指定 URL 并由服务器发起请求；是否对目标地址做白名单或内部地址检测。 | 5. **输出结构**（每个发现都要包含以下部分） - 风险点名称 - 漏洞成因（为什么可能触发） - 攻击面分析（攻击者可能会怎么尝试） - 关键代码片段（只展示相关函数或方法） 黑盒漏洞挖掘个人观点目前市面上大量工具打着AI 自动化漏洞挖掘、智能分析攻击链路的旗号，看似很酷炫但本质上是在用通用 Agent 架构包装传统扫描器。大多数通过 MCP 将模型与各类工具（发包、爬虫、指纹识别等）连接起来，试图让 AI 自主探索、组合工具、推导攻击路径，看起来“智能”“自动化”，但在真实黑盒安全场景中，这条路线存在根本性的工程与成本问题。MCP会不断尝试调用工具，然后根据结果修正答案，这样的操作会导致token消耗爆炸产生高额的费用，整体ROI其实为负因此我认为，AI 在黑盒场景下的正确打开方式，不是无限制 Agent + MCP 调工具，而是针对场景去挖掘漏洞目前对于SSRF、SQL注入这些探测已经很成熟了，因此我觉得未来方向应该着重于逻辑漏洞挖掘1.黑盒安全不是“探索型问题”，而是“验证型问题”黑盒漏洞挖掘的核心并不在于“能不能想到攻击手法”，而在于： 请求是否真实命中业务路径 返回数据是否具备越权或敏感属性 漏洞是否可稳定复现、可被证明成立 2.MCP 在黑盒场景下看起来智能，后期成本指数级失控，最终只能靠人工兜底很多黑盒 MCP 服务在 Demo 中看起来效果不错，但问题往往出现在规模化运行之后： 请求数不可预测，模型为了提高“理解度”，会自然倾向于多次发包、多角度验证，但每一次都是真实成本。 工具调用链不可收敛， MCP 允许模型自由组合工具，但攻击链并不等于漏洞成立，复杂路径只会带来更多误报。 误报无法自动止损， AI 很容易给出“疑似漏洞”的判断，而这些“疑似”最终都需要人工复现，成本极高。 3.黑盒 AI 必须是“场景化裁判”，而不是“自由探索者”真正可落地的黑盒 AI，不是让模型“自己决定下一步做什么”，而是先由人或规则系统把问题压缩成一个最小可验证场景。也就是说： 场景先被定义（如 IDOR、越权、未授权访问、信息泄露） 输入、对照条件、请求模板全部固定 模型只负责判断结果是否成立 IDOR越权流程设计目前对于IDOR越权需要对多个参数进行构造和分析，会耗费大量的时间精力，因此我觉得AI赋能这个场景具有比较大的可塑性实现效果1.处理成标准的输入格式，burp导出数据包，右键选择save items自动解析处理成规范输入格式，在demo目录生成随机文件夹用于后续分析2.根据数据包中参数让ai判断是否存在可遍历性，可遍历性参数生成测试用例【AI分析判定规则】 ✔ 认为“可遍历”的参数： - 纯数字：1、12、12345 - 明显自增 ID：orderId、userId、uid、id、page - 数字 + 简单前缀后缀（如：10001、20002） ✘ 认为“不可遍历”的参数： - 高随机字符串 - 明显 UUID / hash / token - 大小写字母 + 数字混合、长度较长的字符串 例如：hjk2bvadn、A9xPqL0Zk 仅对“可遍历参数”继续后续步骤。 3.调用net/http库进行发包根据PII、参数分析等规则划分为高中低风险4.结束在前端展示，输出消耗token费用和耗时输出风险参数及测试用例数据包promot提示词你是一名专业的 Web 安全测试与越权漏洞挖掘专家，请严格按照以下步骤对给定的数据包列表进行越权分析，不要跳步，不要假设结果。 【输入】 我将提供一批 HTTP 数据包（GET / POST 请求），每个数据包包含： - 请求方法 - URL - 请求参数（GET 参数或 POST body） - 原始响应状态码 - 原始响应内容长度 【分析目标】 判断接口是否可能存在 越权漏洞（IDOR / BOLA / 水平越权 / 垂直越权）。 -------------------------------------------------- 【分析步骤】 第一步：参数提取 1. 如果是 GET 请求： - 提取 URL 中的所有参数，例如： /api/xxx?aaa=1&bbb=abc 2. 如果是 POST 请求： - 提取 body 中的参数，例如： ccc=1&ddd=3 - JSON、form、x-www-form-urlencoded 均需解析 -------------------------------------------------- 第二步：参数可遍历性判断 对每一个参数的值进行可遍历性分析： 【判定规则】 ✔ 认为“可遍历”的参数： - 纯数字：1、12、12345 - 明显自增 ID：orderId、userId、uid、id、page - 数字 + 简单前缀后缀（如：10001、20002） ✘ 认为“不可遍历”的参数： - 高随机字符串 - 明显 UUID / hash / token - 大小写字母 + 数字混合、长度较长的字符串 例如：hjk2bvadn、A9xPqL0Zk 仅对“可遍历参数”继续后续步骤。 -------------------------------------------------- 第三步：控制变量法修改参数 对每一个可遍历参数，单独进行修改，其他参数保持完全不变。 修改每一个参数生成一个测试用例，与原数据包进行对比 【修改规则】 - 数字参数：+1 或 -1 例如： 12345 → 12346 - 每次只修改一个参数 - 不同时修改多个参数 -------------------------------------------------- 第四步：响应对比分析 对比【原始请求】与【修改参数后的请求】的响应： 重点关注： 1. HTTP 状态码 2. 响应内容长度 3. 响应语义是否发生变化 -------------------------------------------------- 第五步：越权判定逻辑（核心） 【疑似存在越权漏洞】 满足以下所有条件： - 修改参数后返回 HTTP 状态码为 200 - 响应内容长度发生明显变化 - 未命中任何权限拒绝关键字 → 判定为：⚠️ 疑似存在越权漏洞（需要人工进一步确认） 【判定为不存在越权漏洞】 满足任意一个条件： - 返回 HTTP 状态码为 403 - 或响应内容命中以下任一权限拒绝关键字（大小写不敏感）： (?i)permission\s*denied (?i)access\s*denied (?i)\bforbidden\b (?i)unauthorized (?i)not\s*authorized (?i)not\s*allowed (?i)no\s*permission (?i)permission\s*required (?i)insufficient\s*permission (?i)insufficient\s*permissions (?i)insufficient\s*privilege (?i)insufficient\s*privileges (?i)authentication\s*failed (?i)authentication\s*required (?i)login\s*required (?i)not\s*logged\s*in (?i)session\s*expired (?i)invalid\s*session (?i)invalid\s*token (?i)token\s*expired (?i)token\s*invalid (?i)missing\s*token (?i)jwt\s*expired (?i)jwt\s*invalid (?i)role\s*not\s*allowed (?i)role\s*denied (?i)authorization\s*failed (?i)permission\s*check\s*failed (?i)access\s*control\s*deny (?i)rbac\s*deny (?i)policy\s*denied (?i)policy\s*reject (?i)resource\s*access\s*denied (?i)resource\s*not\s*owned (?i)not\s*your\s*resource (?i)resource\s*not\s*(found|exist) (?i)record\s*not\s*(found|exist) (?i)request\s*blocked (?i)request\s*denied (?i)security\s*policy\s*violation (?i)access\s*blocked (?i)\b403\b → 判定为：✅ 当前参数未发现越权漏洞 -------------------------------------------------- 第六步：结果输出格式（必须遵守） 对每一个接口输出以下内容： - 接口路径 - 请求方法 - 可遍历参数列表 - 被修改的参数及修改方式 - 原始响应状态码 / 长度 - 修改后响应状态码 / 长度 - 判定结论： - 「疑似越权漏洞」 - 或「未发现越权」 如无法判断，明确说明原因，不要猜测。 模型费用对比及选择通过多轮测试，在生成测试样例和判断PII数据准确率方面，各模型性能差异性不大，因此优先选择价格更便宜的模型model测试下来，gpt-4.1-nano兼顾速度和费用优先选择，小任务可以选择Qwen 模型 描述 单接口消耗（USD） 单接口消耗（RMB） 推荐指数 gpt-5-nano 付费最便宜，主要是慢，一个请求需要等待3-5秒，不建议 $0.82 美分 $0.057 人民币 ⭐⭐ gpt-4.1-nano 成本略高于 5-nano，但判断更稳，速度快，推荐 $0.91 美分 0.064元人民币 ⭐⭐⭐⭐⭐ Qwen 免费，速度快，但是限频1分钟60次，容易429超时，数量少可选择 — — ⭐⭐⭐ 浏览插件自动化点击触发API现在基于API测试越权已经实现了，要想实现全自动化挖洞还需要尽可能全的数据包，在甲方场景我们可以通过捕获流量重放去实现在渗透攻防的场景下，如果需要人工一个个点击显得有点呆了，因此决定开发一个浏览器插件自动化触发button事件点击和提交表单https://github.com/Pizz33/Xiadian_browser智能元素识别通过 isElementVisible() 函数进行识别button等点击元素function findClickableElements() { const selectors = [ 'button:not([disabled])', 'a[href]:not([href="#"]):not([href="javascript:void(0)"])', 'input[type="submit"]:not([disabled])', 'input[type="button"]:not([disabled])', '[role="button"]:not([disabled])', '[onclick]', '.btn:not([disabled])', '.button:not([disabled])', '[class*="button"]:not([disabled])', '[class*="btn"]:not([disabled])' ] 动态内容监听const observer = new MutationObserver(() => { if (isRunning) { } }) observer.observe(document.body, { childList: true, // 监听子节点变化 subtree: true }) 脚本注入与消息传递 延迟等待机制，确保脚本完全加载后再发送消息 通过 chrome.tabs.sendMessage 实现跨模块通信 startBtn.addEventListener('click', async () => { const value = parseInt(inputValue.value) || 1 console.log('[Popup] 开始按钮被点击，输入值:', value) // 重置统计 updateStats(0, 0) // 保存状态 if (chrome.storage && chrome.storage.local) { chrome.storage.local.set({ isRunning: true, inputValue: value }) } 主处理流程 定时执行机制：使用 setInterval 每 2 秒执行一次，控制操作频率 去重处理：使用 Set 数据结构记录已处理元素，避免重复操作 逐个处理按钮：每次只处理一个可点击元素，避免操作过快导致页面异常 function processPage() { if (!isRunning) { console.log('[自动点击助手] 未运行，跳过处理') return } // 1. 查找所有可点击的元素 const clickableElements = findClickableElements() // 2. 查找所有输入框 const inputElements = findInputElements() console.log('[自动点击助手] 找到输入框:', inputElements.length, '个') // 3. 处理输入框（遍历所有未处理的） inputElements.forEach((input, index) => { if (!processedElements.has(input)) { console.log(`[自动点击助手] 处理输入框 ${index + 1}:`, input) fillInput(input) processedElements.add(input) filledCount++ updateStats() } }) // 4. 处理可点击元素（每次只点击一个，避免过快） if (clickableElements.length > 0) { const unprocessedElements = clickableElements.filter(el => !processedElements.has(el)) if (unprocessedElements.length > 0) { const element = unprocessedElements[0] console.log('[自动点击助手] 准备点击元素:', element) clickElement(element) processedElements.add(element) clickedCount++ updateStats() } } } 流程设计优化在满足我们的需求后，我们还可以对流程进行调整节省消耗 每个文件夹独立调用AI分析 ---> 统一收集所有参数，一次性AI分析 AI调用次数 = API文件夹数量 ---> AI调用次数 = 1（参数分析）+ N（PII命中时的响应分析） 测试用例生成 ---> AI测试用例直接生成（+1/-1），不调用AI 处理顺序：串行处理每个文件夹 ---> 处理顺序：并行处理多个文件夹 详细对比 阶段 旧流程耗时 新流程耗时 优化比例 参数收集 10秒 8秒 20%↓ AI参数分析 100秒（100次调用） 3秒（1次调用） 97%↓ 测试用例生成 50秒（AI生成） 1秒（直接生成） 98%↓ 测试用例验证 120秒 100秒 17%↓ AI响应分析 20秒（50次调用） 8秒（20次调用） 60%↓ 总计 300秒 120秒 60%↓ Token消耗对比 类型 旧流程 新流程 节省 参数分析Token 150K 2K 98.7%↓ 响应分析Token 50K 20K 60%↓ 总计 200K 22K 89%↓