6.3、手工驗證SQL注入

6.4、基於錯誤的SQL注入

6.5、確認並利用sql盲注漏洞

6.6、使用SQLMap查找和利用SQL注入

6.7、利用XML外部實體注入

6.8、檢測和利用命令注入漏洞

6.3、手動識別SQL注入

大多數現代Web應用程序都實現某種數據庫，而SQL是最常用的查詢數據庫的語言。 在SQL注入（SQLi）攻擊中，

攻擊者試圖通過注入表單中的SQL命令來發送更改的查詢，從而濫用應用程序和數據庫之間的通信

用於在服務器中構建SQL語句的請求中的輸入或任何其他參數。

在本文中，我們將測試Web應用程序的輸入，以查看它是否容易受到基於錯誤的SQLi的攻擊

登錄到DVWA，轉到SQL注入，並檢查安全級別是否低：

1.與之前的方法一樣，讓我們通過引入一個數字來測試應用程序的正常行爲。將用戶ID設置爲1，然後單擊“提交”。 通過查看結果，我們可以說應用程序查詢數據庫以查看是否存在ID等於1的用戶並返回該用戶的ID，名稱和姓氏。

2.接下來，我們必須測試如果發送應用程序不期望的內容會發生什麼。在文本框中引入1'並提交該ID。 如以下屏幕截圖所示，應用程序應響應錯誤：

此錯誤消息告訴我們數據庫收到錯誤形成的查詢。 這並不意味着我們可以確定這裏有SQLi，但很可能這個應用程序很容易受到攻擊。

3.返回DVWA SQLInjection頁面。

4.爲了確保存在基於錯誤的SQLi，我們嘗試另一個輸入：1''（這次是兩個撇號）：

這次沒有錯誤。 這證實了應用程序中存在SQLi漏洞。

5.現在我們將執行一個非常基本的SQLi攻擊。 在文本框中引入'或'1'='1並提交。結果應如下所示：

看起來我們剛剛在數據庫中註冊了所有用戶。

在用於形成數據庫查詢之前，未對輸入進行驗證和清理時會發生SQLi。 讓我們假設應用程序中的服務器端代碼（在PHP中）組成查詢，如下所示：

$query = "SELECT * FROM users WHEREid='".$_GET['id']. "'";

這意味着id參數中發送的數據將按原樣集成在查詢中。如果我們用它的值替換參數引用，我們有：

$query = "SELECT * FROM users WHEREid='"."1". "'";

因此，當我們像我們一樣發送惡意輸入時，PHP解釋器將按如下方式讀取代碼行：

$query = "SELECT * FROM users WHERE id='"."' or'1'='1"."'";

結果SQL語句如下所示：

$query = "SELECT * FROM users WHERE id='' or '1'='1'";

這意味着如果用戶id等於no或1 = 1，則從名爲users的表中選擇所有內容; 由於一個總是等於一個，所有用戶都將滿足這些標準。 首先我們發送的撇號關閉原始代碼中打開的那個。 之後，我們可以引入一些SQL代碼，最後一個沒有關閉撇號的代碼使用一個已經設置在服務器的代碼中。這被稱爲基於錯誤的SQLi，並且是SQLi的最基本形式，因爲我們使用錯誤消息來確定我們是否已經使用我們的注入形成了有效查詢，並且結果直接顯示在應用程序的輸出中。

更多…

與簡單地顯示應用程序的用戶名相比，SQLi攻擊可能造成更大的破壞。通過利用這種漏洞，攻擊者可能會泄露各種漏洞

有關用戶的敏感信息，例如聯繫方式和信用卡號。 也可能危及整個服務器，並能夠執行命令並升級其中的權限。此外，攻擊者可能能夠從數據庫中提取所有信息，包括數據庫和系統用戶，密碼，以及根據服務器和內部網絡配置，SQLi漏洞可能是完整網絡和內部基礎結構的入口點。

讚賞老哥一瓶大可樂+大雞腿吧！，讚賞碼：

--------------------------------------------------------------------

更多精彩內容，關注玄魂工作室

Kali Linux Web滲透測試手冊(第二版) - 6.2 - 文件包含和文件上傳

查看原文 >>