一、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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。