php代碼審計之重裝漏洞的簡單介紹

本文目錄一覽：

• 1、如何發現php wangye loudong
• 2、php漏洞與代碼審計過程中需要注意的幾點
• 3、php漏洞修復

如何發現php wangye loudong

0x01: 搜索所有的用戶可控變量（GET/POST/COOKIE/referer）

原因：所有用戶輸入都是有害的，代碼審計注重函數和變量，先看看在什麼地方會有輸入

可能出現的場景：

a) id=$_GET[‘id’];

可能存在的問題：

無過濾的SQL注入：

WooYun: chshcms 程氏CMS V3.0 注射（已在官方演示站測試）

1

$id=trim($_GET[“id”]);

//下面直接就進查詢語句了

1

if($db-query(“update “.Getdbname(‘dance’).” set CS_TID=”.$tid.” where cs_user='”.$cscms_name.”‘ and

當然，這是GET之後沒做過濾的情景

b) id=intval($_GET[‘id’]);

可能存在的問題：intval對字符型無用，字符型變量是怎麼處理的呢？

如果字符型的addslashes，注意數字型盲注（見c2分析）

c) $tid=XX_Request(“tid”);

使用自己定義的安全過濾函數處理變量，很常見，很多框架都提供了解決方案，不過自己包裝一個也是很常見的

可能存在的問題：

c1) 有沒有忘記使用這個處理函數？

WooYun: chshcms 程氏CMS V3.0 注射（已在官方演示站測試）

$tid=CS_Request(“tid”); //使用安全的CS_request addslash

$id=trim($_GET[“id”]); //呵呵呵，曲項向天歌，CS_Request哭了

其實還是上面那個例子，自己忘了用這函數過濾了

c2) 函數本身是否安全？

WooYun: (新)程氏舞曲CMS 三步GETSHELL（實例演示+源碼詳析）

$t_Val = $magic?trim($_GET[$pi_strName]):addslashes(trim($_GET[$pi_strName]));

使用了addslashes，這就意味着逃脫單引號難度加大，需要尋找沒有單引號保護的語句注入

addslashes只處理單引號和斜杠，因此無法過濾形如 134 and 1=1 這樣的注射語句，請自行百度無單引號盲注

在下面的語句中，$cscms_name就是有單引號保護的，而$id是沒有單引號保護的

$db-query(“update “.Getdbname(‘xiaoxi’).” set CS_DID=1 where CS_ID=”.$id.” and cs_usera='”.$cscms_name.”‘”);

所以id引發了盲注

c3) 過濾函數能否滿足業務邏輯的特殊需求？

負數訂單啦，自己修改自己的投票數啦，各種業務邏輯上的問題都有可能發生

非常可惜，這個我還沒撞見過，如果以後撞見再更新到文章里

d) 不要忘記我們能控制referer等變量

可能存在的問題：

雖然發現GET/POST都過濾處理了，但是referer和cookie容易被忽視

$_SERVER[“HTTP_REFERER”] 例子：

WooYun: MacCMS 6.x referer處理不當引發注射

很遺憾，這個截至今日還未公開，等公開了大家再去看吧

$_COOKIE[‘xxx’] 例子：

WooYun: TCCMS全版本COOKIE注入（已演示證明）

$sql=”select password from “.$_Obj-table.” where id=”.$_COOKIE[‘userId’];

情況和GET時是一樣的，不過注入時操作起來稍微麻煩些，SQLMAP教程我就不粘貼到這裡了，不會COOKIE注射的請百度

e) 還有其他的輸入變量，請各路高手帶着實例補充！

目前，我們了解了程序總體上是如何處理用戶輸入的

0x02：單獨搜索$_COOKIE，分析身份認證時的邏輯

原因：身份驗證屬於業務邏輯中「高危」的部分，大部分的高危漏洞都出在這裡

可能出現的場景：

a) 沒有cookie處理，直接全是session

那就等之後通讀代碼時直接去讀認證算法好啦

b) 認證算法中強度太弱（用可控的COOKIE算來算去），降低了偽造身份的難度

WooYun: (新)程氏舞曲CMS 三步GETSHELL（實例演示+源碼詳析）

第二步偽造身份時

elseif($_COOKIE[‘CS_Login’]!=md5($_COOKIE[‘CS_AdminID’].$_COOKIE[‘CS_AdminUserName’].$_COOKIE[‘CS_AdminPassWord’].$_COOKIE[‘CS_Quanx’])){

有什麼意義呢？COOKIE我們能控制，當然之後程序有別的驗證，這裡只是舉例，就這一句而言沒有意義

實際上漏洞里這個CMS這個算法，後面只是在認證時沒有用到安裝時admin寫死在config里的驗證碼而已，不過難度已經降下來了

c) 直接能繞過

如果情況b 沒有其他驗證了，那就繞過了

目前我們只是驗證了登陸時的邏輯，之後還需分析權限的縝密程度

0x03：搜索所有的文件操作函數，分析其邏輯

原因：文件操作函數屬於敏感函數，往往業務邏輯上的漏洞可能導致任意文件操作

可能出現的場景：

a) 任意文件下載

WooYun: appcms 最新版 1.3.708 任意文件下載

?php

if(isset($_GET[‘url’]) trim($_GET[‘url’]) != ” isset($_GET[‘type’])) {

$img_url = base64_decode($_GET[‘url’]);

$shffix = trim($_GET[‘type’]);

header(“Content-Type: image/{$shffix}”);

readfile($img_url);

} else {

die(‘image not find’);

}

?

PS：由於是業務邏輯上的問題，是沒辦法通過自動掃描發現的，而且針對SQL和HTML的過濾是起不到特大作用的

任意文件讀取的最大作用是讀config.php 和各種系統的敏感文件（如何爆物理目錄？請看0x04）

b) 任意文件寫入

WooYun: CSCMS V3.5 最新版 後台命令執行GETSHELL（源碼詳析）

任意文件寫入的最大應用就是寫馬了，最大障礙是繞過過濾的HTML字符比如： ，解決方式是大量應用base64

c) 任意文件刪除

很遺憾，還沒撞見過，要是撞見一個該多好

任意文件刪除的作用可以是刪除install.lock，然後重裝CMS

d) 其他操作，求補充

文件操作可以結合爆目錄

0x04：爆物理目錄

原因：上一小節我們可能能夠任意操作文件，但沒拿到網站的物理目錄地址，的確可以用黑盒不停地試圖讀取 c:\boot.ini 和 /etc/passwd 之類的來試圖判斷，但是這麼弄實在不可靠

怎麼辦：使用php vulnerability hunter 自動掃描就好了，這個確實可以偷懶用工具掃描，因為這個爆目錄危害實在太低了，必須配合其他漏洞才有危害，所以一般CMS都會有這種漏洞，我是說能掃描出來的漏洞

WooYun: appcms 最新版 1.3.708 任意文件下載

如果你不知道物理路徑，你可以試着用工具掃描一下，然後再讀取

0x05：搜索eval，preg_replace什麼的，看看有沒有命令執行

原因：能直接執行PHP代碼，也就是說可以寫一句話木馬了（file_put_contents），當然，要找可寫目錄

這地方我一直沒能找到例子，沒有親自實踐過，求各路高手帶實例提供幾個？

0x06：可以開始通讀代碼了，從index開始，注意的是數據的傳輸和輸出函數

原因：常見模式化的漏洞都不存在的話，就要分析整個系統了，因此需要完全而徹底地去做審計，這樣比繼續單獨搜索變量然後跟蹤更加省力一些

可能出現的場景：

a) 之前的過濾全白費了

WooYun: YXcms1.2.0版本 存儲式XSS（實站演示+源碼分析）

沒公開，等公開再更新文章，這是一個存儲式xss

b) 二次注入

由於二次開發中從數據庫里取出的值沒有過濾，導致注射，由於沒有直接從用戶輸入中獲得，所以之前步驟很難發現

哎呀，求各路高手提供個示例呀，我這個自己也沒有碰到過丫

c) 平行權限、任意投票、越權訪問 等等 等等 一大堆

0x07 總結

目前就知道這麼些，希望能對剛接觸PHP代碼審計漏洞挖掘的新手有點幫助，由於我也是剛開始學習PHP漏洞挖掘不久，希望大家能廣泛提供學習的建議以及思路，也請批評指正文章中不妥之處，更希望高手們能帶着示例來指導。

php漏洞與代碼審計過程中需要注意的幾點

1.xss + sql注入

其中佔大頭的自然是XSS與SQL注入，對於框架類型或者有公共文件的，建議在公共文件中統一做一次XSS和SQL注入的過濾。寫個過濾函數，可由如下所示：

$_REQUEST = filter_xss（$_REQUEST）；

$_GET = filter_xss（$_GET）；

$_POST = filter_xss（$_POST）；

$_COOKIE = filter_xss（$_COOKIE）；

$_POST = filter_sql（$_POST）；

$_GET = filter_sql（$_GET）；

$_COOKIE = filter_sql（$_COOKIE）；

$_REQUEST = filter_sql（$_REQUEST）；

這裡有一點需要說明，$_REQUEST雖然等於$_GET+$_POST,但他們是獨立的數組，也就是說假設改變了$_GET的值，但$_REQUEST的值還是原來的值，所以過濾時都不能落下，至於其他的如$_FILE之類的就可忽略了。

最簡單的filter_xss函數是htmlspecialchars（）

最簡單的filter_sql函數是mysql_real_escape_string（）

當然，誰都知道這種過濾filter_sql只能過濾字符型和搜索型的注入，對於數字型是沒有辦法的，但也說明做了這層過濾後，只需在後面注意數字型的SQL語句就可以了，遇到了加intval過濾就可以了，這就變得容易多了。

2. 命令執行

對於命令執行，可以從關鍵字入手，總共可分為3類

（1） php代碼執行 :eval等

（2）shell命令執行：exec、passthru、system、shell_exec等

（3） 文件處理：fwrite、fopen、mkdir等

對於這幾類需要注意其參數是否用戶可控。

3.上傳漏洞

對於上傳漏洞，也是重點關注的地方，要仔細分析它的處理流程，針對上傳的繞過方式是很多的，最保險的方式：在保存文件是採用文件名隨機命名和後綴白名單方式。其次要注意的一點是上傳文件的地方可能不止一處，不要有遺漏，可能會碰到這樣的情況，突然在某個目錄裏面包含了一個第三方的編輯器在裏面。

文件包含漏洞涉及的函數如include（） 、include_once（）、require（）、require_once（）、file_get_contents（）等

最常見的還是出在下載文件功能函數，例如download.php?file=///etc/passwd 這種類型中。

4. 權限繞過

權限繞過可分為兩類吧

（1）後台文件的未授權訪問。後台的文件沒有包含對session的驗證，就容易出現這樣的問題

（2）未作用戶隔離，例如mail.php?id=23顯示了你的信件，那麼換個ID, mail.php?id=24就查看到了別人的信件，編寫代碼是方便，把信件都存在一個數據表裡，id統一編號，前端展現時只需按id取出即可，但未作用戶隔離，判定歸屬，容易造成越權訪問。

這樣的例子是很常見的，給某銀行做評估是就經常發現這種漏洞。

5. 信息泄露

信息泄露算是比較低危的漏洞了，比如列目錄這種就屬於部署問題，而與代碼審計無關了，而像暴路徑、暴源碼這種是需要防止的。曾經遇到這樣的代碼

?php if（empty（$_GET[‘a’]）） {…} ?

表面上似乎沒問題，可是當請求變為 xx.php?a[]=1時，即參數變為數組的時候，就會發生錯誤以致路徑泄露，而用isset判斷則不會，當然一個個防太麻煩，建議在配置文件中關閉錯誤提示，或者在公共文件中加入如下代碼以關閉錯誤顯示功能：

?php error_reporting（0）；?

php漏洞修復

打開php配置文件，php.ini，然後在裏面搜索dll，把你下載的布丁照着格式複製一行就行了。比如你下載的補丁為abc.dll;就加一行extension=abc.dll