原文地址:http://drops.wooyun.org/tips/838

最近研究PHP漏洞的挖掘，總結了一些我挖到的漏洞，整理了一下思路，求各路神人補充、批評、指導~

本文所有示例均來自我在烏云上已由廠商允許公開的漏洞

由于是實例的分析，基礎知識請百度，就不全都粘貼到前面了

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

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

可能出現的場景：

a) id=$_GET['id'];

可能存在的問題：

無過濾的SQL注入：

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

#!php
$id=trim($_GET["id"]);??  

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

#!php
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漏洞挖掘不久，希望大家能廣泛提供學習的建議以及思路，也請批評指正文章中不妥之處，更希望高手們能帶著示例來指導。