php抓取網(wǎng)頁(yè)數據插入數據庫 CMS真的安全嗎？洞鑒PHPCMS

　　什么是PHPCMS

　　說(shuō)到PHPCMS，就不得不先提一提CMS。CMS全稱(chēng)“Content Management System”，意為“內容管理系統”，內容管理系統是一種位于WEB 前端（Web 服務(wù)器）和后端辦公系統或流程（內容創(chuàng )作、編輯）之間的軟件系統。內容的創(chuàng )作人員、編輯人員、發(fā)布人員使用內容管理系統來(lái)提交、修改、審批、發(fā)布內容。

　　這里指的“內容”可能包括文件、表格、圖片、數據庫中的數據甚至視頻等一切你想要發(fā)布到Internet、Intranet以及Extranet網(wǎng)站的信息。內容管理還可選地提供內容抓取工具，將第三方信息來(lái)源，比如將文本文件、HTML網(wǎng)頁(yè)、Web服務(wù)、關(guān)系數據庫等的內容自動(dòng)抓取，并經(jīng)分析處理后放到自身的內容庫中。

　　隨著(zhù)個(gè)性化的發(fā)展，內容管理還輔助WEB前端將內容以個(gè)性化的方式提供給內容使用者，即提供個(gè)性化的門(mén)戶(hù)框架，以基于WEB技術(shù)將內容更好地推送到用戶(hù)的瀏覽器端。

　　PHPCMS由國內80后知名創(chuàng )業(yè)者鐘勝輝于2005年創(chuàng )辦，是國內知名內容管理系統，它是一款基于 PHP 技術(shù)和 AJAX 技術(shù)的企業(yè)級網(wǎng)站內容管理系統，旨在幫助用戶(hù)解決日益復雜與重要的 Web 內容的創(chuàng )建、維護、發(fā)布和應用。

　　PHPCMS的創(chuàng )立趕上了CMS蓬勃發(fā)展的時(shí)期，而且它將模塊化開(kāi)發(fā)方式做為功能開(kāi)發(fā)形式，框架易于功能擴展，代碼維護，優(yōu)秀的二次開(kāi)發(fā)能力，可滿(mǎn)足所有網(wǎng)站的應用需求，所以迅速占領(lǐng)了國內的內容管理系統領(lǐng)域的大片領(lǐng)土。

　　從2005年P(guān)HPCMS第一版創(chuàng )立，到2007年推出PHPCMS 2007版本，再到2008年年底推出了PHPCMS 2008版本，四年三大版本均贏(yíng)得了市場(chǎng)好評，最終在2010年盛大在線(xiàn)收購PHPCMS后，PHPCMS推出了主線(xiàn)產(chǎn)品PHPCMS V9版本，到2017年5月推出了最新的V9.6.3版本，PHPCMS仍為現在國內領(lǐng)先的內容管理系統，是各大站長(cháng)建站的首選。

　　根據全網(wǎng)數據統計，使用PHPCMS的網(wǎng)站多達4萬(wàn)多個(gè)，其中大部分集中在國內，共有約3萬(wàn)余個(gè)，占使用量的75%以上，同時(shí)，PHPCMS在教育行業(yè)約有上千個(gè)網(wǎng)站使用，在政府部門(mén)的網(wǎng)站中，也有上百個(gè)網(wǎng)站使用，其他則用于商業(yè)用途，具體分布如下圖：

　　從圖中可以看出，PHPCMS的使用范圍較廣，其中在政府部門(mén)中不乏市縣級政府這樣的客戶(hù)；教育行業(yè)內，也不乏國內大學(xué)的校級、院系官網(wǎng)使用PHPCMS作為其發(fā)布信息的官方主頁(yè)；商業(yè)用途中，PHPCMS也備受中小型企業(yè)的青睞。

　　PHPCMS的版本更新迭代速度以及功能齊全等特性也為其快速擴張提供發(fā)展基礎。但是，PHPCMS安全嗎？

　　PHPCMS安全嗎？

　　根據千里目實(shí)驗室漏洞庫的統計，PHPCMS從創(chuàng )辦到如今近十三年，產(chǎn)品三大版本的漏洞總量高達100余個(gè)，其中核心版本PHPCMS2008系列、PHPCMS V9系列高危漏洞近40個(gè)，在40個(gè)漏洞之中，全網(wǎng)公布的高可利用性漏洞個(gè)數也高達兩位數，其中尤其PHPCMS V9最多，所以，PHPCMS的安全性一直備受廣大用戶(hù)的質(zhì)疑。

　　經(jīng)過(guò)對PHPCMS高危漏洞的分析整理以及統計，PHPCMS的高危漏洞類(lèi)型主要有以下五類(lèi)：SQL注入類(lèi)、命令執行類(lèi)、任意文件上傳類(lèi)、任意文件下載類(lèi)、任意文件讀取類(lèi)。其中SQL注入問(wèn)題是最為嚴重的一類(lèi)，不管數量還是威脅性都是其中最高的，5類(lèi)漏洞的數量具體分布占比如下圖。接下來(lái)按照這些漏洞中威脅性最高的五類(lèi)漏洞來(lái)介紹PHPCMS的經(jīng)典漏洞，以及漏洞間的共性和漏洞成因。

　　2.1 SQL注入漏洞

　　PHPCMS框架層面分析

　　PHPCMS的核心版本中，PHPCMS v9的SQL注入問(wèn)題比PHPCMS 2008要嚴重很多，這是為什么？

　　首先從PHPCMS的框架上分析了這個(gè)問(wèn)題的原因。PHPCMS2008中對GPC變量的處理， 是在

　　include/common.inc.php中使用$db->escape($_GET)對輸入變量進(jìn)行轉義，實(shí)質(zhì)上是調用了

　　mysql_real_escape_string，PHP手冊上對這個(gè)函數的描述：

　　string mysql_real_escape_string ( string $unescaped_string [, resource $link_identifier ] )

　　#本函數將 unescaped_string中的特殊字符轉義，并考慮到連接的當前字符集，因此可以安全用于 mysql_query()

　　也就是說(shuō)PHPCMS 2008中使用mysql_real_escape_string對輸入變量進(jìn)行處理，是可以達到防注入效果的，PHPCMS2008中這樣的處理方式是比較安全的，但是也有其不合理的一面，原因在于：入口中對所有變量進(jìn)行mysql_real_escape_string處理，顯然并不是所有變量需要入庫，這樣處理必須影響性能（連接mysql->發(fā)送變量至mysql server ->mysql server轉義->返回給PHP程序）。

　　而PHPCMS V9在入口文件phpcms/libs/classes/param.class.php中采用以下方式：

　　$_POST = new_addslashes($_POST);

　　$_GET = new_addslashes($_GET);

　　$_REQUEST = new_addslashes($_REQUEST);

　　$_COOKIE = new_addslashes($_COOKIE);

　　new_addslashes其實(shí)就是調用了PHP內置的addslashes對GPC變量添加轉義斜線(xiàn)，這就相當于php.ini中打開(kāi)了magic_quotes_gpc選項，PHP手冊中對magic_quotes_gpc的處理有以下描述：

　　Warning

　　This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.

　　從PHP 5.4.0開(kāi)始，已經(jīng)不支持magic_quotes_gpc了，這是為什么？

　　(1)性能：由于并不是每一段被轉義的數據都要插入數據庫的，如果所有進(jìn)入 PHP 的數據都被轉義的話(huà)，那么會(huì )對程序的執行效率產(chǎn)生一定的影響。

　　(2)方便性：由于不是所有數據都需要轉義，在不需要轉義的地方看到轉義的數據就很煩。比如說(shuō)通過(guò)表單發(fā)送郵件，結果看到一大堆的 \'。

　　(3)安全問(wèn)題：事實(shí)上addslashes或開(kāi)啟magic_quotes_gpc并不能完全杜絕SQL注入。因為addslashes對有些特殊字符后跟上'（單引號）并不會(huì )加把這個(gè)'變成/'，如：0xbf27的字就不會(huì )，所以縗' OR 1 limit 1/* 這個(gè)就存在。

　　針對這個(gè)問(wèn)題，PDO擴展而生，它主要解決兩個(gè)問(wèn)題：批量查詢(xún)時(shí)使用prepare提升查詢(xún)性能，使用參數化查詢(xún)從根本上杜絕SQL注入，但是PHPCMS V9的phpcms\libs\classes\param.class.php依舊使用以下代碼,所這就是造成PHPCMS中SQL注入如此之多的根本原因。：

　　private $route_config = '';

　　public function __construct() {

　　if(!get_magic_quotes_gpc()) {

　　$_POST = new_addslashes($_POST);

　　$_GET = new_addslashes($_GET);

　　$_REQUEST = new_addslashes($_REQUEST);

　　$_COOKIE = new_addslashes($_COOKIE);

　　PHPCMS漏洞層面分析

　　從具體的漏洞來(lái)看，PHPCMS代碼中出現的SQL注入點(diǎn)主要有三種情況：

　　

　　第一種情況，即外部可控參數未進(jìn)行任何過(guò)濾，這種問(wèn)題是因為系統設計人員代碼設計的不嚴謹導致。其中最經(jīng)典的PHPCMS v9 前臺用戶(hù)登錄處SQL注入漏洞產(chǎn)生即是因為這個(gè)原因：用戶(hù)在登錄頁(yè)面輸入用戶(hù)名與密碼，在\phpcms\modules\member\index.php的login方法中，username使用的is_username進(jìn)行了過(guò)濾而password沒(méi)有做任何處理。

　　$username = isset($_POST['username']) && is_username($_POST['username']) ?

　　trim($_POST['username']) : showmessage(L('username_empty'), HTTP_REFERER);

　　$password = isset($_POST['password']) && trim($_POST['password']) ?

　　trim($_POST['password']) : showmessage(L('password_empty'), HTTP_REFERER);

　　$cookietime = intval($_POST['cookietime']);

　　$synloginstr = ''; //同步登陸js代碼

　　所以，Password就成為了一個(gè)注入點(diǎn)。輸入的username以及password被傳到phpsso模塊中進(jìn)行認證，而phpsso模塊并沒(méi)有解析過(guò)濾用戶(hù)名與密碼就直接進(jìn)行認證，認證后直接將信息返回到登錄頁(yè)面的login方法中。

　　第二種情況也是SQL注入中的經(jīng)典情形，即代碼中處理外部輸入數據的時(shí)候使用了urldecode()函數。比如單引號被 urlencode 兩次以后是 %2527，然后 POST。PHP 內部在生成全局變量 $_POST 的時(shí)候會(huì )先 urldecode，得到 %27，然后 PHP 會(huì )檢查 Magic Quotes 的設置，但是無(wú)論是否開(kāi)啟 Magic Quotes，%27 都不會(huì )被 addslashes，因為這時(shí)根本沒(méi)有單引號。

　　但是這時(shí)如果你在 PHP 代碼中畫(huà)蛇添足的加上 urldecode，%27就變成單引號了，這樣就成功繞過(guò)了，這種情況出現的根源在于之前分析的PHPCMS使用magic_quotes_gpc這種方式來(lái)處理外部數據。

　　PHPCMS V9 WAP SQL注入漏洞即是因為這種情況：

　　function comment_list() {

　　$WAP = $this->wap;

　　$TYPE = $this->types;

　　$comment = pc_base::load_app_class('comment','comment');

　　pc_base::load_app_func('global','comment');

　　$typeid = intval($_GET['typeid']);

　　$GLOBALS['siteid'] = max($this->siteid,1);

　　$commentid = isset($_GET['commentid']) && trim(urldecode($_GET['commentid'])) ?

　　trim(urldecode($_GET['commentid'])) : exit('參數錯誤');

　　list($modules, $contentid, $siteid) = decode_commentid($commentid);

　　list($module, $catid) = explode('_', $modules);

　　$comment_setting_db = pc_base::load_model('comment_setting_model');

　　$setting = $comment_setting_db->get_one(array('siteid'=>$this->siteid));

　　這段代碼中在處理外部可控參數commentid的時(shí)候，使用了urldecode()函數，最終可以采用%2527的方式來(lái)進(jìn)行過(guò)濾繞過(guò)。

　　PHPCMS db->table_name = $this->db->db_tablepre.$MODEL[$modelid]['tablename'];

　　$this->db->table_name = $tablename.'_data';

　　$rs = $this->db->get_one(array('id'=>$id)); //id傳入sql查詢(xún)語(yǔ)句

　　在函數中，代碼通過(guò)GET獲取'a_k'值，并調用sys_auth函數進(jìn)行解密，然后使用parse_str()來(lái)解析解密后的$a_k參數，將字符串解析到變量中，并同時(shí)解碼。在parse_str()解析的過(guò)程中，就將之前構造好的SQL注入paylaod賦值到各個(gè)參數，并且繞過(guò)了所有限制。

　　這個(gè)漏洞利用還有另一個(gè)關(guān)口，就是需要將payload使用sys_auth加密，同樣，PHPCMS一個(gè)任意文件下載漏洞也是這個(gè)原理：構造payload—>sys_auth加密—>帶入到phpcms\modules\content\

　　down.php文件init函數中—>進(jìn)行解碼并parse_str()解析，payload通過(guò)這種方式可以繞過(guò)所有過(guò)濾關(guān)口，最終成功觸發(fā)。

　　從之上的分析可知，所有的SQL注入漏洞其根源都在magic_quotes_gpc方法上。但是除了框架之外，如此多的SQL注入問(wèn)題就在于程序員對待代碼邏輯的不嚴謹，缺少對外部可控參數的過(guò)濾或者說(shuō)是缺少完全的過(guò)濾驗證過(guò)程，PHP是很靈活的語(yǔ)言，其代碼的邏輯嚴謹程度即代表著(zhù)它的安全性高低！

　　命令執行漏洞

　　命令執行是一類(lèi)威脅性非常大的漏洞類(lèi)型，大多數“一鍋端”（能夠getshell，控制全站）漏洞都是命令執行漏洞。由之前的漏洞數量分布可知，命令執行問(wèn)題的數量?jì)H次于SQL注入，但是它的嚴重程度可能更甚于SQL注入漏洞。

　　PHPCMS框架中的命令執行漏洞大部分都是由于一個(gè)函數，即global.func.php中的string2array()函數，函數代碼如下：

　　/**

　　* 將字符串轉換為數組

　　*

　　* @param string $data 字符串

　　* @return array 返回數組格式，如果，data為空，則返回空數組

　　*/

　　function string2array($data) {

　　$data = trim($data);

　　if($data == '') return array();

　　if(strpos($data, 'array')===0){

　　@eval("\$array = $data;");

　　

　　}else{

　　if(strpos($data, '{\\')===0) $data = stripslashes($data);

　　$array=json_decode($data,true);

　　if(strtolower(CHARSET)=='gbk'){

　　$array = mult_iconv("UTF-8", "GBK//IGNORE", $array);

　　}

　　}

　　return $array;

　　}

　　該函數中使用了eval函數，這就代表所有調用這個(gè)函數的地方，如果存在過(guò)濾不嚴的情況，都會(huì )出現嚴重的命令執行漏洞。當然，我們不用懷疑程序員寫(xiě)BUG的能力，PHPCMS中多個(gè)命令執行漏洞都是因為外部參數未進(jìn)行嚴格過(guò)濾，就直接帶進(jìn)了string2array()中進(jìn)行處理，所以最終觸發(fā)了漏洞。

　　其中最經(jīng)典的一個(gè)漏洞PHPCMS 2008任意代碼執行漏洞，該漏洞利用門(mén)檻之低讓人大跌眼鏡，漏洞的出處就在yp/web/include/common.inc.php的menu變量：

　　$menu = string2array($menu);

　　$siteurl = $m_s_url[1] = $M['url'].'web/?'.$userid;

　　$introduceurl = $m_s_url[2] = $siteurl.'/category-introduce.html';

　　$newsurl = $m_s_url[3] = $siteurl.'/category-news.html';

　　$product = $m_s_url[4] = $siteurl.'/category-product.html';

　　$buyurl = $m_s_url[5] = $siteurl.'/category-buy.html';

　　$joburl = $m_s_url[6] = $siteurl.'/category-job.html';

　　$joburl = $m_s_url[7] = $siteurl.'/category-certificate.html';

　　$guestbookurl = $m_s_url[8] = $siteurl.'/category-guestbook.html';

　　$contacturl = $m_s_url[9] = $siteurl.'/category-contact.html';

　　Menu參數是一個(gè)外部可控參數，該參數被被傳進(jìn)后臺之后未經(jīng)過(guò)任何處理以及限制，導致在string2array()函數中直接被eval函數執行，導致遠程代碼執行漏洞。

　　而這個(gè)函數從PHPCMS 2008到PHPCMS V9一直都存在，而該系統程序員也只是在之后每一個(gè)調用此函數的地方都先對傳入參數進(jìn)行過(guò)濾或者限制，但是任何過(guò)濾限制都有被繞過(guò)的可能，之后的事實(shí)證明確實(shí)如此，比如之后再V9版本出現的PHPCMS V9 phpcms\

　　modules\dbsource\data.php出現的遠程命令執行漏洞，PHPCMSV9 /phpcms/modules/vote/

　　index.php代碼執行漏洞等均是因為這個(gè)原因。

　　所以，防止PHP程序出*敏*感*詞*科玉律：永遠不要在代碼中使用eval。

　　因為，很少有人能夠掌控住這個(gè)函數，一旦控制不住，可能就會(huì )出現一個(gè)“一鍋端”的命令執行漏洞。

　　另外PHPCMS中出現的一個(gè)PHPCMS /phpsso_server/phpcms/modules/phpsso/index.php代碼執行漏洞，它的思想很特別、也很典型。該漏洞中存在的一個(gè)猛獸理論值得很多程序員以及安全研究人員來(lái)認真研究的?！懊瞳F來(lái)了,我們應該將其絕殺在門(mén)外,但是有些人非得把它放進(jìn)屋內,才殺之,你們難道不知道猛獸的嘴里可能叼了一個(gè)*敏*感*詞*包嗎? 砰!!!結果全都玩完了…”。下面用具體代碼來(lái)解釋這個(gè)理論。

　　其中:

　　猛獸放進(jìn)室內：copy($_GET['src'],$_GET['dst']);

　　這條猛獸不安全,殺之：unlink($_GET['dst']);

　　*敏*感*詞*包：$_GET['dst'] 此*敏*感*詞*包的作用是生成惡意文件。

　　這段代碼中存在缺陷的地方就是將“猛獸”放進(jìn)市內的地方：

　　copy($_GET['src'],$_GET['dst']);

　　可將任意文件copy成惡意文件,如木馬，后來(lái)發(fā)現這個(gè)文件不安全，然后使用unlink將之刪除...，但是，有種可能就是木馬在刪除之前,生成了新的木馬文件,結果可想而知。

　　PHPCMS V9

　　/phpsso_server/phpcms/modules/phpsso/index.php任意命令執行就是這個(gè)原理。首先上傳頭像，頭像的格式被壓縮為zip格式文件，然后文件到了/phpsso_server/phpcms/modules/phpsso/index.php的uploadavatar()函數，首先被解壓，然后判斷為非jpg文件后刪除。攻擊者利用這個(gè)漏洞的過(guò)程中是將webshell保存為jpg中，構造后綴名突破jpg的限制，在文件被上傳解壓后，webshell執行在上層目錄生成一個(gè)新的webshell文件，由此觸發(fā)漏洞。

　　命令執行漏洞的威脅性極大，在任何代碼審計中，只要代碼中出現了eval，assert等這類(lèi)代碼執行函數后，都有可能出現代碼執行漏洞。并且猛獸理論也應該在被關(guān)注，這樣的邏輯在很多代碼中都會(huì )被用到，其解決的方法即應該在第一步的時(shí)候就處理風(fēng)險，不能將“猛獸放進(jìn)屋來(lái)”。

　　任意文件上傳漏洞、任意文件下載、任意文件讀取漏洞

　　這三類(lèi)漏洞是關(guān)于文件操作的漏洞，具有很多的共性。PHPCMS中的任意文件上傳漏洞主要是因為文件上傳過(guò)程中，文件類(lèi)型的限制不嚴或者因為存在過(guò)濾限制繞過(guò)，導致可以上傳一些可執行文件，最終GetShell。該類(lèi)漏洞與代碼執行很相似，最根本就是為了執行上傳文件中的惡意代碼。

　　其中PHPCMS v9 注冊頁(yè)面任意文件上傳漏洞和PHPCMS v9.6.1 后綴名提取導致任意文件上傳漏洞都是一種采用構造后綴名繞過(guò)限制過(guò)濾的漏洞。第一個(gè)漏洞中的正則要求輸入滿(mǎn)足src/href=url.(gif|jpg|jpeg|bmp|png)，則構造的（

　?。┓线@一格式（這也就是為什么后面要加.jpg的原因）。之后通過(guò)一系列處理，將.jpg去掉，那么最后文件的后綴就變成了.php成為了可執行文件。

　　而第二個(gè)漏洞中則因strtolower(trim

　　(substr(strrchr($filename, '.'), 1, 10)));處理被繞過(guò)，攻擊這可以使用/1.thumb_.Php.JPG%20%20

　　%20%20%20%20%20Php來(lái)繞過(guò)過(guò)濾，最終由于apache的文件名解析特性（可以去掉空格）導致上傳文件里php代碼最終被解析執行。所以該類(lèi)漏洞中，都是因為對文件名后綴缺少更嚴謹的處理，導致上傳可執行文件最終導致getshell。

　　PHPCMS