借助Burpsuite的Access數據庫手工SQL注入是怎樣的

本篇文章給大家分享的是有關借助Burpsuite的Access數據庫手工SQL注入是怎樣的，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

環境介紹

目標系統是之前在網上偶然下載的一個CMS系統，在本地裝了一個 Windows Server 的虛擬機，開啟 IIS。因為是Access數據庫，所以不需要安裝相關的數據庫服務，再其根目錄的/data文件夾下有個data.mdb文件，即為該數據庫文件。

發現注入點

在測試環境里看了一下站點的情況，發現這個CMS在讀取新聞內容的時候，URL為http://172.22.10.239/info.asp?id=240 的形式。順手在id后面加了個單引號，結果竟然報了500的錯誤！

進一步進行確認，考慮到這里的id應該是數據庫中的行號，猜想一下相關的查詢語句可能的構成應該為：

SELECT {col_name} FROM {table_name} WHERE `id` = {id}

查詢語句里面的id大概率是通過拼接的方式寫進去的。為了證實這個猜想，構造一個payload：

?id=240+and+1=1+

+號在URL中是等同于空格的，為了避免問題空格就用+代替。

這時候發現依然是500，難道判斷錯了？還是后面還有別的什么語句嗎？不甘心的又嘗試了一下or進行拼接：

?id=240+or+1=1+

這下可以正常顯示出頁面了。那基本就能確定此處存在注入點，而且大概率是and字符被替換了。

問題分析

既然發現了注入點，就可以嘗試注入。正常的手段是去試過濾規則，但是因為目標是一個CMS，我們手里有后臺的源碼，因此直接開始對相關頁面的源碼進行分析，看看它到底用了什么規則去攔截我們的輸入。

先打開info.asp文件，找到處理id參數的地方。在開頭的第 4 行就是一個赤裸裸的 SQL 拼接，語句與我們猜測的完全一致：

那這里的rqs()又是啥？在library.asp文件中找到了這個函數的定義：

str_safe函數定義：

看到這里，其實一切規則就都明白了，我們輸入的 {空格}and 是在過濾列表中的。那么下一步就是如何繞過并且進行注入了。

嘗試注入

ACCESS 數據庫與 Mysql 數據庫注入的區別主要體現在 ACCESS 是沒有  information_schema 這種“總表”，也就是說數據表的名稱是無法通過注入的方法讀取到，因此需要去猜解。

繞過過濾

在猜解之前需要先繞過過濾。因為有了看到源碼的便利，知道了過濾的原理，CMS替換的字符都是帶空格的，如{空格}and, select{空格}這種，那需要找到繞過空格的方法。

首先想到的是用大小寫繞過，比如AnD這樣，但是發現Replace函數的參數最后是1, -1, 1。這三個參數分別表示的替換字符的起始、終止和檢查類型。檢查類型默認為0，設置為1的時候是大小寫不敏感的，因此大小寫繞過便沒有作用了。

那么換個思路，嘗試用一些特殊字符來代替空格。存在一些除了%20、+ 以外的字符也可以被 ACCESS 認作空格的作用。這時需要使用 Burpsuite 的 Intruder 工具來進行嘗試。

在 Position 界面把要替換的字符，當然這里根據源碼里面的規則，將空格字符替換掉，使用 URL 轉義的方式填充 %xx ，將除了 ‘%’的部分進行標記。Intruder工具中的 Attack type選擇 Battering ram，這樣所有的標記處都會同步的進行變化：

在 Payload 的部分，類型type選擇 Brute forcer，即暴力破解，字符集填上 HEX 的字符集，即 0~9，A~F，最大和最小位數都是 2 位，這樣就能遍歷 0x00 ~ 0xFF 的全部字符了。

瞬間跑完結果，將結果按照 Response 的狀態 Status 排序，是 200 的那幾條就是返回了正確頁面的。此時就能 初步 得到可以成功跑出結果的字符集。

框中的是初步篩選的結果。這里能夠執行成功，不代表成功代替了空格，有可能是引起了其他轉義（比如截斷等），所以還要將篩選出來的字符用 id=240%{xx}and%{xx}1=2再跑一次確認一下。因為數量不多，所以用 Simple list 模式將這些 Payload 再做一次測試：

這次的結果中，狀態為 500 的返回值說明這個字符是成功的解析成空格的（因為后面注入的是and 1=2，預期返回的是false）。從 200 的結果也可以看出，%00，%16 這兩個字符可以用作截斷，即 %16后面的字符不會被當做 SQL 語句進行解析。

所以目前可以確定，當前可用的替代空格的字符為 %09, %0A, %0D。

猜解表名

因為知道了過濾規則，并找到了可替代的字符，就可以嘗試猜解表名了。

ACCESS 沒有記錄數據表名稱的系統表，所以不能像 Mysql 那樣直接讀取，唯一的方法就是暴力猜解表名。

首先構建Payload。在上一步的基礎上，將 AND 關鍵字后面的條件換成嘗試表名是否存在的語句即可。這里使用 exists 關鍵字來完成這個任務：

EXISTS(SELECT NULL FROM `{表名}`)

如果表名不存在，那么這個查詢會報錯，返回 500；若存在表名，則EXISTS函數會返回 True，自然頁面也會返回 200。

關于表名的猜測，網上有一些類似于 Top 100 的列表可以下載，或者盲猜。一般系統都會有包含 admin 這個名稱的表，無非是前面加上前綴，比如國內的CMS會喜歡加上CMS的縮寫，或者如 “t_admin” 這種一個字母的形式。這樣可以根據目標的特點去構建猜測的列表，用 Intruder 工具將表名列表導入 Simple list中進行暴力破解。

這里這個CMS嘛，因為本地有源碼，就開了個掛，直接看到了它的表名，比如管理員表叫做CMS_ADMIN。

進行注入

現在萬事具備，只欠注入了。這里嘗試使用 UNION 關鍵字來把想要的數據給拿出來。使用 UNION 關鍵字的時候需要知道原查詢的字段數，否則會報列數不匹配的問題，自然返回的就是500。預期構建出的完整 SQL 查詢如下：

SELECT * FROM `cms_info` WHERE id = 1 UNION SELECT 1,1,1, ... ,1 FROM cms_info

現在需要知道 UNION 中的 1 的個數需要多少個。還是用 Intruder 來嘗試，先構建出一條初始的payload: id=1%0Dunion%0Dselect%0D1%0Dfrom%0Dcms_info，使用%0D作為空格的替代。插入標記之后的樣子如下：

此處 Payload type 選擇 Character blocks，Min length設置為2，就是 ",1"的長度。我們想嘗試 1~50列，Max length 就設置為 50 * 2 = 100 即可：

將結果按照 Status 排序，200的結果序號是 34，那么說明當前這個新聞頁面查詢的表的結果一共 35 列（因為初始的時候已經有了 UNION SELECT 1 FROM...，因此這里列數要根據序號 +1）

但是雖然這里是 200，但是頁面并沒有返回正常的數據，使用 Repeter 發送這個數據，發現是要跳轉到 login.asp 頁面：

那么說明返回的字段中是有控制頁面顯示的功能。各個字段分別的功能需要通過修改字段的值來判斷，此處大體就是 0， 1， NULL 三種不同的值排列組合，具體分析方法不再贅述。最終得到注入的結果，比如讀到管理員賬號密碼：

總結分析

這個注入點因為做了替換，將一些主要的 SQL 關鍵字進行了轉義，導致使用 SQLMap 無法直接跑出數據，因此使用手工注入的方式查看。其實也可以通過在 SQLMap 中引入腳本的方式自動替換來達到目的，將空格全部替換成%9D即可自動化跑出內容（沒有試過，但是原理上可行）。

對于 ACCESS 數據庫，對于表名、列名都需要盲猜，其實注入難度會很大，但是對于 CMS 系統來說，表名和字段名是公開的，一般用戶在使用的時候又不會特別去進行修改，一旦出現注入點會有很大的隱患。

對于防止 SQL 注入，像這種替換顯然是有問題的，關鍵字 + 空格的識別還是有很多方法可以進行繞過，如果擔心匹配太嚴格影響業務，也可以從允許的變量類型、長度等方面進行局部限制，來消減 SQLI 的隱患。

以上就是借助Burpsuite的Access數據庫手工SQL注入是怎樣的，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。