基礎知識要打牢:什麼是sql注入
sql注入的測試流程:
- 判斷是否存在注入,注入的類型
- 獲取數據庫版本信息,用戶等
- 猜解當前數據庫名稱
- 猜解數據庫中的表名
- 猜解表中的字段名
- 猜解表中的字段值
- 驗證字段的有效性
我們遇到了一個讓人懷疑的輸入框，根據做安全的敏感神經，我們懷疑框裏會有注入，於是我們插入了我們輸入的惡意字符，那麼惡意字符有哪些呢？什麼是惡意字符，就是不符合常規的，不符合正常客戶輸入的就是惡意字符，特殊字符，惡意的算術表達式等等
那麼我們遇到了這樣的框幹嘛呢？我先嚐試輸入【‘】【”】或者編碼過後的看瀏覽器會返回什麼信息，正常的話那就正常唄，不正常那就開始分析返回的信息唄
那麼單純的輸入框正常的話我們會去幹嘛？這個是時候就是理論紮實的時候了，我有一篇帖子介紹了，什麼是sql注入，輸入框屬於參數注入點，那麼還有其他如:User-Agent注入點，Referer注入點，cookie注入點，這裏就說這三個，還有另外的後面單說。
那麼我們可對這個輸入框的提交進行抓包，對上述幾個注入點進行fuzz測試【模糊測試】，一個一個的嘗試，嘗試沒有編碼的，然後嘗試各種編碼的奇淫技巧，如果沒有返回錯誤或者也沒有想盲注那樣有任何反應，那麼就放過他，測試其他漏洞，類似xss，csrf等等
Low級別
這是未報錯的顯示
這是輸入特殊字符的報錯界面
那麼報錯的話我們幹嘛.我們可以想到幹嘛,輸入一個'就報錯了,後臺數據庫語句的代碼是咋樣的啊?報錯了就扔sqlmap?如果沒有工具我們該怎麼辦?這些都是我們需要考慮的問題,這就是我們做這個實驗的意義.
我們先看low的代碼進行分析
我們發現代碼對傳入的參數沒有做任何的過濾就直接帶入數據庫查詢語句了,我們輸入的參數導致'產生歧義,不知道是和前面的'閉合還是和後面的'閉合,產生錯誤,那麼我們可以使用sql裏的註釋符#來將後面的語句註釋掉,我們看還會報錯嗎?
沒有報錯了,說明我們的做法正確,我們掌握了它的傳參邏輯和查詢語句的寫法,那麼我們接下來可以幹嘛.我們可以首先確定該表的字段長度,那麼如何判斷呢?
SQL語句:1' order by number # ,number是你輸入的數字,你可以從1開始嘗試,如果頁面返回正常,那說明表內有1個字段,如果你輸入3返回不正常,那說明沒有3個字段,只有2個
order by的意思如下所述:
select a,b
from table
order by 2 ;
相當於：
select a,b
from table
order by b ;
當輸入3時報錯
那麼接下來我們可以繼續構造sql語句來獲取表,列,字段,我們可以利用union語句來構造sql查詢,union是連接查詢,union意思具體不做贅述
那麼我們現在該利用漏洞獲取那些的信息呢?
這裏我們根據錯誤回顯發現數據庫是mariad數據庫,是mysql的替代品.
我們會用到的mysql函數,當然如果是其他類型的數據庫,根據其內置的函數來進行信息收集即可
- database():當前網站使用的數據庫
- version():當前mysql的版本
- user():當前mysql的用戶
那麼我們可以構造如下sql語句來查詢所需的信息
union select database(),version()
我們發現成功的顯示了當前網站使用的數據庫爲dvwa,當前數據庫版本爲5.5.60-MariaDB
我通過構造查詢語句得到了數據庫版本的信息
我們瞭解到Mysql5.0以上版本會有information_schema默認數據庫,同時支持多線程,多用戶
5.0以下版本不內置這個默認函數,同時支持多線程,但不支持多用戶
infomation這個默認數據庫會存放當前用戶創建的所有數據庫的庫名,表名,列名,
對應着,SCHEMATA,TABLES,COLUMNS
schemata表存儲該用戶創建的所有數據庫的庫名,其中有我們需要記住的字段名爲schena_name
tables表存儲了該用戶創建的所有數據庫的庫名和表名,對應的我們需要記住其中tables_schema和tables_name兩個字段
columns表存儲了該用戶創建的所有數據庫的庫名,表名,列名,對應的我們需要記住其中的tables_schema,tables_name,column_name三個字段
那麼我們現在可以構造如下語句,來查詢默認數據庫內的其他數據庫名
1' union select 1,schema_name from information_schema.schemata#
構造如下語句來查詢默認數據內的其他表名
1' union select 1,table_name from information_schema.tables#
構造如下語句來查詢默認數據庫內的字段名
1' union select 1,column_name from information_schema.columns#
這裏我只是把默認的幾個表查詢了,實際中我們結合之前查找到的當前網站使用的數據庫來做where查詢,請看官自行發揮
Medium級別
那麼以上dvwa,low級別的sql 顯注實驗結束,我們進入下一步medium
我們發現中級別的沒有輸入框了,改成下拉框了,提交參數的方式也改成了post請求
那麼我們應該怎麼做呢?我們首先想的是應該是抓包看一下數據包是咋樣的,
那麼我們看到數據包修改成了post,其他的沒有很大的改變,我們還是可以嘗試我們的幾個注入點,我們打開burp的repeater插件進行測試
我們先判斷是否存在注入,並且分析注入是字符型還是數字型
發現存在注入點,並且提示'被/轉義,說明過濾了字符型注入,我們嘗試下構造數字型注入的poc
or 1 = 1
返回正常,說明該注入爲數字型注入.
我們分析下源碼
我們發現參數在提交的查詢前做了一個過濾:
過濾函數爲mysql_real_escape_string(),該函數轉義sql語句中使用的字符串中的特殊字符
有以下字符受到影響
- \x00
- \n
- \r
- \
- '
- "
- \x1a
如果成功,則該函數返回被轉義的字符串,如果失敗,則返回false
因此,數字型的注入能夠繞過這個漏洞,接下來收集信息的操作就是跟上面的low級別一樣,注意一點,聯合查詢時需要輸入''的話我們可以使用類似16進制來達到查詢的效果
High級別
接下來我們進入high級別,我們先看代碼
代碼沒有做過濾,我們嘗試了'發現報錯,存在注入,但是看代碼發現加了一個LIMIT 1 ,LIMIT的使用格式爲 limit m,n 其中m是指記錄開始的位置,n是指取n條記錄.,這個我們可以直接通過#來註釋掉,那麼這樣的話後面的操作就和low級別的手工注入一樣了
注意:
我們發現高級別的查詢提交頁面和查詢結果顯示頁面不是同一個,也沒有執行302跳轉,這樣做的目的是爲了防止一般的sqlmap注入,因爲sqlmap在這個注入的過程中,無法在查詢提交頁面上獲取查詢結果,沒有了反饋,也就沒辦法進一步注入
最後我們留一個問題給看官,大家對注入impossible級別有什麼騷操作???