一、PHP反序列化

1.1概述

在理解这个漏洞前,你需要先搞清楚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:"";}

1.2实验

查看源代码(路径如下)，这里有个接口可以接受一个反序列化的对象，对传进来的参数没有进行任何过滤

我们可以利用相似的代码生成一个反序列化的字符串，反序列化一般通过代码审计的方式发现

class S{

var $test = "";

}

echo ‘
‘;

$a = new S();

echo serialize($a);

?>

将这段代码命名为unserialize.php，在浏览器的url中输入路径访问它

弹框出来，我们点击确定，点击右键，查看页面源代码

将
后面的内容复制下来，在下图中输入

O:1:"S":1:{s:4:"test";s:29:"";}

这段代码的反序列化的结果是一个 JS 的弹窗，我们提交后就能进行 XSS 攻击

二、XXE

2.1概述

XXE -"xml external entity injection"

既"xml外部实体注入漏洞"。

概括一下就是"攻击者通过向服务器注入指定的xml实体内容,从而让服务器按照指定的配置进行执行,导致问题"

也就是说服务端接收和解析了来自用户端的xml数据,而又没有做严格的安全控制,从而导致xml外部实体注入。

具体的关于xml实体的介绍,网络上有很多,自己动手先查一下。

第一部分：XML声明部分

第二部分：文档类型定义 DTD

]>

第三部分：文档元素

Dave

Tom

其中，DTD(Document Type Definition，文档类型定义)，用来为 XML 文档定义语法约束，可以是内部申明也可以使引用外部DTD现在很多语言里面对应的解析xml的函数默认是禁止解析外部实体内容的，从而也就直接避免了这个漏洞。

① 内部申明DTD格式

元素申明]>

② 外部引用DTD格式

③ 引用公共DTD格式

识名" "公共DTD的URI">

外部实体引用 Payload

]>

&f;

现在很多语言里面对应的解析xml的函数默认是禁止解析外部实体内容的,从而也就直接避免了这个漏洞。

以PHP为例,在PHP里面解析xml用的是libxml,其在≥2.9.0的版本中,默认是禁止解析xml外部实体内容的。

本章提供的案例中,为了模拟漏洞,通过手动指定LIBXML_NOENT选项开启了xml外部实体解析。

2.2实验

打开pikachu平台，我们先输入一个payload

]>

&hacker;

它将我们定义的实体内容打印在了前端

所以我们可以通过system关键字定义一个外部实体，可以让他支持一些协议读取外部数据，比如Linux中的etc/passwd 。

我用的是windows 所以只读取一个简单的文件了

payload：

]>

&f;

三、SSRF

3.1概述

SSRF(Server-Side Request Forgery:服务器端请求伪造)

其形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能,但又没有对目标地址做严格过滤与限制

导致攻击者可以传入任意的地址来让后端服务器对其发起请求,并返回对该目标地址请求的数据

数据流:攻击者----->服务器---->目标地址

根据后台使用的函数的不同,对应的影响和利用方法又有不一样

PHP中下面函数的使用不当会导致SSRF:

file_get_contents()

fsockopen()

curl_exec()

如果一定要通过后台服务器远程去对用户指定("或者预埋在前端的请求")的地址进行资源请求,则请做好目标地址的过滤。

你可以根据"SSRF"里面的项目来搞懂问题的原因

3.2 SSRF(curl)

点击可以看到一首诗，在上方url中我们可以看到诗的来源

我们可以把 url 中的内容改成同一网络的其他服务器上地址和端口，探测内网的其他信息，比如查看文件，使用下面地址查看地址为192.168.10.123的站点里的WWW文件里的一个记事本

查看后端代码(路径如下)  如果没有做好过滤，就可以通过curl这个方法获取到内网的其他服务器上的信息，也可以对网络上的进行读取

3.3 SSRF(file_get_content)

发现和刚才一样，我们查看下后端源码(路径如下)

与上面实验不同的是这个使用了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.10.246/pikachu-master/vul/ssrf/ssrf_fgc.php?file=php://filter/read=convert.base64-encode/resource=ssrf.php

我们将页面上这段编码使用base64进行解码

得到ssrf.php里的代码  这是ssrf概述那个页面的代码。

原文：https://www.cnblogs.com/heiwa-0924/p/12622293.html