序列化和反序列化
概述：
序列化serialize()
序列化说通俗点就是把一个对象变成可以传输的字符串,比如下面是一个对象：
class S{ public $test="pikachu"; } $s=new S(); //创建一个对象 serialize($s); //把这个对象进行序列化 序列化后得到的结果是这个样子的:O:1:"S":1:{s:4:"test";s:7:"pikachu";} O:代表object 1:代表对象名字长度为一个字符 S:对象的名称 1:代表对象里面有一个变量 s:数据类型 4:变量名称的长度 test:变量名称 s:数据类型 7:变量值的长度 pikachu:变量值
反序列化unserialize()
就是把被序列化的字符串还原为对象，然后在接下来的代码中继续使用。
$u=unserialize("O:1:"S":1:{s:4:"test";s:7:"pikachu";}"); echo $u->test; //得到的结果为pikachu
序列化和反序列化本身没有问题，但是如果反序列化的内容是用户可以控制的，且后台不正当的使用了PHP中的魔法函数,就会导致安全问题
__construct()当一个对象创建时被调用
漏洞举例：
class S{ var $test = "pikachu"; function __destruct(){ echo $this->test; } } $s = $_GET['test']; @$unser = unserialize($a); payload:O:1:"S":1:{s:4:"test";s:29:"<script>alert('xss')</script>";}
（摘自pikachu平台概述）
pikachu实验：
我们查看源码，这里有个接口可以接受一个反序列化的对象
我们在环境根目录下，建一个123.php文件，代码如下
<?php class S{ var $test = "<script>alert('xss')</script>"; } echo '<br>'; $a = new S(); echo serialize($a); ?>
然后通过浏览器访问这个文件，
我们F12打开控制台看源代码，复制 echo 的内容，得到payload：O:1:"S":1:{s:4:"test";s:29:"<script>alert('xss')</script>";}
把得到的payload提交了，反序列化的结果是一个 JS 的弹窗，我们提交后就能进行 XSS 攻击
XXE
概述：
XXE ——"xml external entity injection"既"xml外部实体注入漏洞"。
概括一下就是"攻击者通过向服务器注入指定的xml实体内容,从而让服务器按照指定的配置进行执行,导致问题"，也就是说服务端接收和解析了来自用户端的xml数据,而又没有做严格的安全控制,从而导致xml外部实体注入。
现在很多语言里面对应的解析xml的函数默认是禁止解析外部实体内容的,从而也就直接避免了这个漏洞。以PHP为例,在PHP里面解析xml用的是libxml,其在≥2.9.0的版本中,默认是禁止解析xml外部实体内容的。
XML语法结构大致如下：
第一部分：XML声明部分 <?xml version="1.0"?> 第二部分：文档类型定义 DTD <!DOCTYPE note[ <!--定义此文档是note类型的文档--> <!ENTITY entity-name SYSTEM "URI/URL"> <!--外部实体声明--> ]> 第三部分：文档元素 <note> <to>Dave</to> <from>Tom</from> <head>Reminder</head> <body>You are a good man</body> </note>
外部实体引用 Payload：
<?xml version="1.0"?> <!DOCTYPE ANY[ <!ENTITY f SYSTEM "file:///etc/passwd"> ]> <x>&f;</x>
我们开始看pikachu实验了。
本章提供的案例中，为了模拟漏洞，Pikachu平台手动指定 LIBXML_NOENT 选项开启了xml外部实体解析。在PHP里面解析xml用的是libxml，其在 ≥2.9.0 的版本中，默认是禁止解析xml外部实体内容的。
我们先提交一个正常的 xml 数据：
<?xml version = "1.0"?> <!DOCTYPE note [ <!ENTITY hacker "test"> ]> <name>&hacker;</name>
它将我们定义的实体内容打印在了前端：
如果我们提交下面这样的payload，就能看到服务器上的文件内容：
<?xml version = "1.0"?> <!DOCTYPE ANY [ <!ENTITY f SYSTEM "file:///C:/PhpStudy/PHPTutorial/WWW/pikachu/assets/css/ace.min.css"> ]> <x>&f;</x>
SSRF
概述：
SSRF（Server-Side Request Forgery，服务器端请求伪造）
其形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能，但又没有对目标地址做严格过滤与限制，导致攻击者可以传入任意的地址来让后端服务器对其发起请求，并返回对该目标地址请求的数据。即以存在SSRF漏洞的服务器为跳板取得其他应用服务器的信息。
数据流：攻击者 -----> 服务器 ----> 目标地址
根据后台使用的函数的不同,对应的影响和利用方法又有不一样
PHP中下面函数的使用不当会导致SSRF:
file_get_contents()
fsockopen()
curl_exec()
如果一定要通过后台服务器远程去对用户指定("或者预埋在前端的请求")的地址进行资源请求,则请做好目标地址的过滤。
SSRF(curl)：
我们进入平台发现是一个链接，里面是一首诗。
观察 url 发现它传递了一个 url 给后台，
我们观察一下源码：
首先接收到前台的URL，然后没有进行过滤就直接进行初始化，然后用curl_exec()，进行解析返回给了前端。
如果你在你的远端服务器上搭建的pikuchu，在这里你可以将URL地址改为内网的其他服务器上地址和端口，探测其他信息，比如端口开放情况，我这里测试机器没有联网就不演示了。
SSRF(file_get_content)：
我们先来观察一下源代码，file_get_content 可以对本地和远程的文件进行读取
还可以使用 filter 取得页面源码：http://192.168.35.132/pikachu/vul/ssrf/ssrf_fgc.php?file=php://filter/read=convert.base64-encode/resource=ssrf.php
再进行 base64 解码 就能得到页面源码：
http://tool.chinaz.com/Tools/Base64.aspx
