一、PHP反序列化

1.1概述

在理解這個漏洞前,你需要先搞清楚php中serialize()，unserialize()這兩個函數(shù)。

序列化serialize()

序列化說通俗點(diǎn)就是把一個對象變成可以傳輸?shù)淖址?比如下面是一個對象:

class S{

public $test="pikachu";

}

$s=new S(); //創(chuàng)建一個對象

serialize($s); //把這個對象進(jìn)行序列化

序列化后得到的結(jié)果是這個樣子的:O:1:"S":1:{s:4:"test";s:7:"pikachu";}

O:代表object

1:代表對象名字長度為一個字符

S:對象的名稱

1:代表對象里面有一個變量

s:數(shù)據(jù)類型

4:變量名稱的長度

test:變量名稱

s:數(shù)據(jù)類型

7:變量值的長度

pikachu:變量值

反序列化unserialize()

就是把被序列化的字符串還原為對象,然后在接下來的代碼中繼續(xù)使用。

$u=unserialize("O:1:"S":1:{s:4:"test";s:7:"pikachu";}");

echo $u->test; //得到的結(jié)果為pikachu

序列化和反序列化本身沒有問題,但是如果反序列化的內(nèi)容是用戶可以控制的,且后臺不正當(dāng)?shù)氖褂昧薖HP中的魔法函數(shù),就會導(dǎo)致安全問題

常見的幾個魔法函數(shù):

__construct()當(dāng)一個對象創(chuàng)建時被調(diào)用

__destruct()當(dāng)一個對象銷毀時被調(diào)用

__toString()當(dāng)一個對象被當(dāng)作一個字符串使用

__sleep() 在對象在被序列化之前運(yùn)行

__wakeup將在序列化之后立即被調(diào)用

漏洞舉例:

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實(shí)驗(yàn)

查看源代碼(路徑如下)，這里有個接口可以接受一個反序列化的對象，對傳進(jìn)來的參數(shù)沒有進(jìn)行任何過濾

我們可以利用相似的代碼生成一個反序列化的字符串，反序列化一般通過代碼審計(jì)的方式發(fā)現(xiàn)

class S{

var $test = "";

}

echo ‘
‘;

$a = new S();

echo serialize($a);

?>

將這段代碼命名為unserialize.php，在瀏覽器的url中輸入路徑訪問它

彈框出來，我們點(diǎn)擊確定，點(diǎn)擊右鍵，查看頁面源代碼

將
后面的內(nèi)容復(fù)制下來，在下圖中輸入

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

這段代碼的反序列化的結(jié)果是一個 JS 的彈窗，我們提交后就能進(jìn)行 XSS 攻擊

二、XXE

2.1概述

XXE -"xml external entity injection"

既"xml外部實(shí)體注入漏洞"。

概括一下就是"攻擊者通過向服務(wù)器注入指定的xml實(shí)體內(nèi)容,從而讓服務(wù)器按照指定的配置進(jìn)行執(zhí)行,導(dǎo)致問題"

也就是說服務(wù)端接收和解析了來自用戶端的xml數(shù)據(jù),而又沒有做嚴(yán)格的安全控制,從而導(dǎo)致xml外部實(shí)體注入。

具體的關(guān)于xml實(shí)體的介紹,網(wǎng)絡(luò)上有很多,自己動手先查一下。

第一部分：XML聲明部分

第二部分：文檔類型定義 DTD

]>

第三部分：文檔元素

Dave

Tom

其中，DTD(Document Type Definition，文檔類型定義)，用來為 XML 文檔定義語法約束，可以是內(nèi)部申明也可以使引用外部DTD現(xiàn)在很多語言里面對應(yīng)的解析xml的函數(shù)默認(rèn)是禁止解析外部實(shí)體內(nèi)容的，從而也就直接避免了這個漏洞。

① 內(nèi)部申明DTD格式

元素申明]>

② 外部引用DTD格式

③ 引用公共DTD格式

識名" "公共DTD的URI">

外部實(shí)體引用 Payload

]>

&f;

現(xiàn)在很多語言里面對應(yīng)的解析xml的函數(shù)默認(rèn)是禁止解析外部實(shí)體內(nèi)容的,從而也就直接避免了這個漏洞。

以PHP為例,在PHP里面解析xml用的是libxml,其在≥2.9.0的版本中,默認(rèn)是禁止解析xml外部實(shí)體內(nèi)容的。

本章提供的案例中,為了模擬漏洞,通過手動指定LIBXML_NOENT選項(xiàng)開啟了xml外部實(shí)體解析。

2.2實(shí)驗(yàn)

打開pikachu平臺，我們先輸入一個payload

]>

&hacker;

它將我們定義的實(shí)體內(nèi)容打印在了前端

所以我們可以通過system關(guān)鍵字定義一個外部實(shí)體，可以讓他支持一些協(xié)議讀取外部數(shù)據(jù)，比如Linux中的etc/passwd 。

我用的是windows 所以只讀取一個簡單的文件了

payload：

]>

&f;

三、SSRF

3.1概述

SSRF(Server-Side Request Forgery:服務(wù)器端請求偽造)

其形成的原因大都是由于服務(wù)端提供了從其他服務(wù)器應(yīng)用獲取數(shù)據(jù)的功能,但又沒有對目標(biāo)地址做嚴(yán)格過濾與限制

導(dǎo)致攻擊者可以傳入任意的地址來讓后端服務(wù)器對其發(fā)起請求,并返回對該目標(biāo)地址請求的數(shù)據(jù)

數(shù)據(jù)流:攻擊者----->服務(wù)器---->目標(biāo)地址

根據(jù)后臺使用的函數(shù)的不同,對應(yīng)的影響和利用方法又有不一樣

PHP中下面函數(shù)的使用不當(dāng)會導(dǎo)致SSRF:

file_get_contents()

fsockopen()

curl_exec()

如果一定要通過后臺服務(wù)器遠(yuǎn)程去對用戶指定("或者預(yù)埋在前端的請求")的地址進(jìn)行資源請求,則請做好目標(biāo)地址的過濾。

你可以根據(jù)"SSRF"里面的項(xiàng)目來搞懂問題的原因

3.2 SSRF(curl)

點(diǎn)擊可以看到一首詩，在上方url中我們可以看到詩的來源

我們可以把 url 中的內(nèi)容改成同一網(wǎng)絡(luò)的其他服務(wù)器上地址和端口，探測內(nèi)網(wǎng)的其他信息，比如查看文件，使用下面地址查看地址為192.168.10.123的站點(diǎn)里的WWW文件里的一個記事本

查看后端代碼(路徑如下)? 如果沒有做好過濾，就可以通過curl這個方法獲取到內(nèi)網(wǎng)的其他服務(wù)器上的信息，也可以對網(wǎng)絡(luò)上的進(jìn)行讀取

3.3 SSRF(file_get_content)

發(fā)現(xiàn)和剛才一樣，我們查看下后端源碼(路徑如下)

與上面實(shí)驗(yàn)不同的是這個使用了file_get_contents

讀取PHP文件的源碼:php://filter/read=convert.base64-encode/resource=ssrf.php

內(nèi)網(wǎng)請求:http://x.x.x.x/xx.index

那么file_get_contents里面帶有php：// filter 我們用這個就可以來讀取php源碼

我們構(gòu)造這樣的url 192.168.10.246/pikachu-master/vul/ssrf/ssrf_fgc.php?file=php://filter/read=convert.base64-encode/resource=ssrf.php

我們將頁面上這段編碼使用base64進(jìn)行解碼

得到ssrf.php里的代碼? 這是ssrf概述那個頁面的代碼。

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

總結(jié)

以上是生活随笔為你收集整理的反序列化 php R类型,pikachu-PHP反序列化、XXE、SSFR的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。