2017-2018-2 20179205《網絡攻防技術與實踐》第十一週做業 SQL注入攻擊與實踐

時間 2019-11-09

原文原文鏈接

《網絡攻防技術與實踐》第十一週做業 SQL注入攻擊與實踐

1.研究緩衝區溢出的原理，至少針對兩種數據庫進行差別化研究

緩衝區溢出原理

在計算機內部，輸入數據一般被存放在一個臨時空間內，這個臨時存放的空間就被稱爲緩衝區，緩衝區的長度事先已經被程序或者操做系統定義好了。向緩衝區內填充數據，若是數據的長度很長，超過了緩衝區自己的容量，那麼數據就會溢出存儲空間，而這些溢出的數據還會覆蓋在合法的數據上，這就是緩衝區和緩衝區溢出的道理。

一般，在棧中分配某個字節數組來保存一個字符串，可是字符串的長度超出了爲數組分配的空間。C對於數組引用不進行任何邊界檢查，並且局部變量和狀態信息，都存在棧中。這樣，對越界的數組元素的寫操做會破壞存儲在棧中的狀態信息。當程序使用這個被破壞的狀態，試圖從新加載寄存器或執行ret指令時，就會出現很嚴重的錯誤。php

void echo()
{
char buf[8] ;
gets(buf) ;
puts(buf) ;
}

因爲棧是向地地址增加的，數組緩衝區是向高地址增加的。故，長一些的字符串會致使gets覆蓋棧上存儲的某些信息。
隨着字符串變長，下面的信息會被破壞：
輸入的字符數量被破壞的狀態
0---7 無
8---11 保存的%ebx的值
12---15 保存的%ebp的值
16---19 返回地址
20+ caller中保存的狀態
若是破壞了存儲%ebp的值，那麼基址寄存器就不能正確地恢復，所以調用者就不能正確地引用它的局部變量或參數。
若是破壞了存儲的返回地址，那麼ret指令會使程序跳轉到徹底意想不到的地方。linux

緩衝區溢出的一個更加致命的使用就是讓程序執行它原本不肯意執行的函數。這是一種最多見的經過計算機網絡攻擊系統安全的方法。一般，輸入給程序一個字符串，這個字符串包含一些可執行代碼的字節編碼，稱爲攻擊代碼，另外還有一些字節會用一個指向攻擊代碼的指針覆蓋返回地址。那麼，執行ret指令的效果就是跳轉到攻擊代碼。程序員

一般，使用gets或其餘任何能致使存儲溢出的函數，都不是好的編程習慣。不幸的是，不少經常使用庫函數，包括strcpy、strcat、sprintf，都有一個屬性——不須要告訴它們目標緩衝區的大小，就產生一個字節序列。web

對抗緩衝區溢出攻擊

一、棧隨機化

爲了在系統中插入攻擊代碼，攻擊者不但要插入代碼，還要插入指向這段代碼的指針，這個指針也是攻擊字符串的一部分。產生這個指針須要知道這個字符串放置的棧地址。在過去，程序的棧地址很是容易預測，在不一樣的機器之間，棧的位置是至關固定的。
棧隨機化的思想使得棧的位置在程序每次運行時都有變化。所以，即便許多機器都運行相同的代碼。它們的棧地址都是不一樣的。
實現的方式是：程序開始時，在棧上分配一段0--n字節之間的隨機大小空間。程序不使用這段空間，可是它會致使程序每次執行時後續的棧位置發生了變化。sql

在Linux系統中，棧隨機化已經變成了標準行爲。（在linux上每次運行相同的程序，其同一局部變量的地址都不相同）shell

二、棧破壞檢測

在C語言中，沒有可靠的方法來防止對數組的越界寫，可是，咱們可以在發生了越界寫的時候，在沒有形成任何有害結果以前，嘗試檢測到它。
最近的GCC版本在產生的代碼中加入了一種棧保護者機制，用來檢測緩衝區越界，其思想是在棧中任何局部緩衝區與棧狀態之間存儲一個特殊的金絲雀值。這個金絲雀值是在程序每次運行時隨機產生的，所以，攻擊者沒有簡單的辦法知道它是什麼。
在恢復寄存器狀態和從函數返回以前，程序檢查這個金絲雀值是否被該函數的某個操做或者函數調用的某個操做改變了。若是是，那麼程序異常終止。數據庫

三、限制可執行代碼區域

限制那些可以存放可執行代碼的存儲器區域。在典型的程序中，只有保存編譯器產生的代碼的那部分存儲器才須要是可執行的，其餘部分能夠被限制爲只容許讀和寫。
如今的64位處理器的內存保護引入了」NX」(不執行)位。有了這個特性，棧能夠被標記爲可讀和可寫，可是不可執行，檢查頁是否可執行由硬件來完成，效率上沒有損失。編程

2.針對不一樣數據類型，研究SQL注入點的發現與注入技術

SQL注入產生緣由及威脅：

剛剛講過當咱們訪問動態網頁時, Web 服務器會向數據訪問層發起 Sql 查詢請求，若是權限驗證經過就會執行 Sql 語句。後端

這種網站內部直接發送的Sql請求通常不會有危險，但實際狀況是不少時候須要結合用戶的輸入數據動態構造 Sql 語句，若是用戶輸入的數據被構形成惡意 Sql 代碼，Web 應用又未對動態構造的 Sql 語句使用的參數進行審查，則會帶來意想不到的危險。數組

Sql 注入帶來的威脅主要有以下幾點：

猜解後臺數據庫，這是利用最多的方式，盜取網站的敏感信息。
繞過認證，列如繞過驗證登陸網站後臺。
注入能夠藉助數據庫的存儲過程進行提權等操做

2.1 判斷SQL注入點

一般狀況下，可能存在 Sql 注入漏洞的 Url 是相似這種形式：http://xxx.xxx.xxx/abcd.php?id=XX

對 Sql 注入的判斷，主要有兩個方面：

判斷該帶參數的 Url 是否存在 Sql 注入？
若是存在 Sql 注入，那麼屬於哪一種 Sql 注入？

可能存在 Sql 注入攻擊的 ASP/PHP/JSP 動態網頁中，一個動態網頁中可能只有一個參數，有時可能有多個參數。有時是整型參數，有時是字符串型參數，不能一律而論。總之只要是帶有參數的動態網頁且此網頁訪問了數據庫，那麼就有可能存在 Sql 注入。若是程序員沒有足夠的安全意識，沒有進行必要的字符過濾，存在SQL注入的可能性就很是大。

2.2 判斷是否存在SQL注入漏洞

最爲經典的單引號判斷法：

在參數後面加上單引號,好比:

http://xxx/abc.php?id=1'

若是頁面返回錯誤，則存在 Sql 注入。

緣由是不管字符型仍是整型都會由於單引號個數不匹配而報錯。

注：若是未報錯，不表明不存在 Sql 注入，由於有可能頁面對單引號作了過濾，這時可使用判斷語句進行注入

2.3 判斷SQL注入漏洞的類型

一般 Sql 注入漏洞分爲 2 種類型：

數字型
字符型
搜索型

其實全部的類型都是根據數據庫自己表的類型所產生的，在咱們建立表的時候會發現其後總有個數據類型的限制，而不一樣的數據庫又有不一樣的數據類型，可是不管怎麼分經常使用的查詢數據類型老是以數字與字符來區分的，因此就會產生注入點爲什麼種類型。

2.3.1數字型判斷：

當輸入的參 x 爲整型時，一般 abc.php 中 Sql 語句類型大體以下：

select * from <表名> where id = x

這種類型可使用經典的 and 1=1 和 and 1=2 來判斷：

Url 地址中輸入 http://xxx/abc.php?id= x and 1=1頁面依舊運行正常，繼續進行下一步。
Url 地址中繼續輸入http://xxx/abc.php?id= x and 1=2 頁面運行錯誤，則說明此 Sql 注入爲數字型注入。
緣由以下：

當輸入 and 1=1時，後臺執行 Sql 語句：

select * from <表名> where id = x and 1=1

沒有語法錯誤且邏輯判斷爲正確，因此返回正常。

當輸入and 1=2時，後臺執行 Sql 語句：

select * from <表名> where id = x and 1=2

沒有語法錯誤可是邏輯判斷爲假，因此返回錯誤。

咱們再使用假設法：若是這是字符型注入的話，咱們輸入以上語句以後應該出現以下狀況：

select * from <表名> where id = 'x and 1=1' 
select * from <表名> where id = 'x and 1=2'

查詢語句將 and 語句所有轉換爲了字符串，並無進行 and 的邏輯判斷，因此不會出現以上結果，故假設是不成立的。

2.3.2字符型判斷：

當輸入的參 x 爲字符型時，一般 abc.php 中 SQL 語句類型大體以下：

select * from <表名> where id = 'x'

這種類型咱們一樣可使用and '1'='1 和 and '1'='2 來判斷：

Url 地址中輸入http://xxx/abc.php?id= x' and '1'='1 頁面運行正常，繼續進行下一步。
Url 地址中繼續輸入http://xxx/abc.php?id= x' and '1'='2頁面運行錯誤，則說明此 Sql 注入爲字符型注入。
緣由以下：

當輸入 and '1'='1時，後臺執行 Sql 語句：

select * from <表名> where id = 'x' and '1'='1'

語法正確，邏輯判斷正確，因此返回正確。

當輸入 and '1'='2時，後臺執行 Sql 語句：

select * from <表名> where id = 'x' and '1'='2'

語法正確，但邏輯判斷錯誤，因此返回正確。

2.3.3搜索型注入點：

emsp;這是一種特殊的注入類型。這類注入主要是指在進行數據搜索時沒過濾搜索參數，通常在連接地址中有「keyword=關鍵字」，有的不顯示的連接地址，而是直接經過搜索框表單提交。
此類注入點提交的 SQL 語句，其原形大體爲：

select * from 表名 where 字段 like '%關鍵字%'

當咱們提交注入參數爲「keyword='and[查詢條件] and '%'=',則向數據庫提交的完事SQL語句爲：

select * from 表名 where 字段 like '%' and [查詢條件] and '%'='%'

總結：

經過查找資料我對SQL注入有了一個大概得了解，也清楚了SQL注入的強大。sql注入經常使用技術有段還包括：

採用非主流通道技術
避開輸入過濾技術
使用特殊的字符
強制產生錯誤
使用條件語句
利用存儲過程
推斷技術
........

3.研究緩衝區溢出的防範方法，至少針對兩種編程語言進行差別化研究

檢測方法及防範措施；

根據緩衝區溢出攻擊的步驟，可將經常使用的緩衝區溢出攻擊檢測技術分爲如下 3 種類型：

基於輸入字符串的檢測方法
基於保護堆棧中的返回地址的檢測方法
基於監視系統調用的檢測方法。

3.1 基於輸入字符串的檢測方法

對輸入的字符串進行檢測，肯定其爲溢出攻擊字符串時採起阻攔措施，使攻擊者沒法注入攻擊代碼。通常有如下3種方法構建溢出攻擊字符串。以下圖所示：

緩衝區大於 ShellCode 長度：

緩衝區小於 ShellCode 長度：

將 ShellCode 放在環境變量裏：

第 1 種溢出攻擊字符串適用於緩衝區大於 ShellCode 長度的狀況；第 2 種溢出攻擊字符串通常用於緩衝區小於 ShellCode 長度的狀況；第 3 種方法是將 ShellCode 放在環境變量裏，是目前較爲經常使用的方法。

在第 1 種和第 2 種類型的溢出攻擊字符串中 ShellCode 前都加了若干的 NOP指令，由於這 2 種狀況下 ShellCode 的地址沒法肯定，但只要返回地址指向 ShellCode 前的任一條NOP 指令， ShellCode 就能夠執行，大大增長了 ShellCode 執行的可能性。這些 NOP指令稱爲 sledge 。其餘單字節指令如 AAA 等也可構成 sledge 。所以緩衝區溢出攻擊檢測系統能夠經過檢查輸入的字符串中是否含有大量 NOP等可構成 sledge 的指令來判斷此字符串是不是溢出攻擊字符串。不過這種方法並不適用於檢測第 3 種類型的攻擊。但這 3 種類型的攻
擊字符串中都含有 ShellCode 。所以，肯定出 ShellCode 的基本特徵 , 如不含有「 0x00」，含有某些特殊的系統調用等，而後利用人工智能、模式匹配、規則匹配等方法檢查輸入字符串中是否包含 ShellCode 也可檢測出是否有緩衝區溢出攻擊發生。這些檢測均可以在入侵檢測等外圍防護系統中實現，優勢是實現較爲簡單，不會增長被保護系統的開銷；缺點是漏報率較高，沒法檢測出無明顯特徵的溢出攻擊字符串。

3.2 基於保護堆棧中返回地址的檢測方法

緩衝區溢出攻擊最關鍵的步驟是要經過修改函數返回地址來改變程序的流程，所以，在函數調用返回前，經過檢查返回地址是否被修改能夠判斷是否有緩衝區溢出攻擊發生。該檢測的實現能夠經過在源碼中插入一些約束和判斷的模塊，而後在編譯後的程序運行期間對有關變量和堆棧區域進行監控，檢測是否有攻擊發生。 StackGuard 和StackShield 就是這一類型的工具，它們都是 gcc 編譯器的擴展工具，用於監控調用的函數返回地址是否正常。StackGuard 主要是在內存中的返回地址及緩衝區之間插入一個「Canary 」字，如圖所示。

在函數調用返回前經過檢查「Canary」字來判斷返回地址是否已經被修改，若是這個 Canary的值被改變了，說明可能有人正進行緩衝區溢出攻擊，程序會馬上響應，發送一則入侵警告消息，而後中止工做。爲防止攻擊者構造 Canary」字， StackGuard 選用「終止符」和「隨機數」做爲「 Canary」字的值。但因爲「 Canary 」字所在的位置是固定的，所以也可能被繞過StackShield 對此做了改進，建立了一個新的堆棧用於備份被保護函數的返回地址。它在被保護函數開始處增長一段代碼，用來將函數返回地址拷貝到一張特殊的表中；一樣在被保護函數的結尾處也增長一段代碼，用來將函數返回地址從表中拷貝回堆棧。從而保證函數正確返回。

3.3 基於監視系統調用的檢測方法

若是攻擊者成功注入攻擊代碼，並改變了程序的執行流程使指令的執行指針指向了ShellCode 的入口地址。按照一次緩衝區攻擊的 3 個步驟，還須執行 ShellCode 來完成攻擊目的。所以，經過檢測是否有 ShellCode 運行能夠檢測是否發生緩衝區溢出攻擊。攻擊者既但願 ShellCode 利用得到的權限啓動一個交互式的 shell 進程來完成儘可能多的事情，又但願 ShellCode 儘可能短小從而更加隱蔽，因此絕大多數 ShellCode 都會調用系統函數。因爲監視全部系統調用會耗費大量系統資源，所以只對 ShellCode 經常使用的系統調用進行監視，根據某些特徵判斷受監視的系統調用是否爲非法調用就可肯定被保護系統是否遭到緩衝區溢出攻擊。例如，若是發現系統調用的返回地址爲堆棧，則可認爲其爲非法調用，由於不多有程序在堆棧上運行代碼。

緩衝區漏洞的防範措施

上面三種方法是針對如何檢測已經發生的緩衝區漏洞，方法雖然多，可是相對比較麻煩，因此咱們最好能從根本上防範它，防止緩衝區漏洞的發生。首先在編寫程序過程當中，程序員有責任和義務養成安全編程的思想，應該熟悉那些可能會產生漏洞或需慎用的函數，清楚那些在編程中要當心使用的函數 ( 特別是在使用 C語言時 ) ，例如： gets() 、 strcpy() 等等。在軟件測試階段，要專門對程序中的每一個緩衝區做邊界檢查和溢出檢測。可是，因爲程序編寫者的經驗不足和測試工做不夠全面、充分，目前還不可能徹底避免緩衝區溢出漏洞，所以這些漏洞在已經使用以及正在開發的軟件中仍是有存在的可能，還須要在使用軟件時，對它作實時的監測。

其次是使用安全語言編寫程序，應使用 Java等安全的語言編寫程序，由於 Java在對緩衝區進行操做時，有相應的邊界檢查，因此能夠有效地防止緩衝區溢出漏洞的產生。可是， Java也並不是絕對安全， Java的解釋器是用 C語言編寫的，而 C並非一種安全的語言，因此 Java解釋器仍是可能存在緩衝區溢出漏洞並受到攻擊。最後能夠經過改進編譯器，它的主要思想是在編譯器中增長邊界檢查以及保護堆棧的功能，使得含有漏洞的程序和代碼段沒法經過編譯。針對 gcc編譯器的不少補丁就提供了這些功能，好比說 Stackguard 等等。

4.數據庫注入攻擊工具

BSQL Hacker

BSQL Hacker是由Portcullis實驗室開發的，BSQL Hacker 是一個SQL自動注入工具（支持SQL盲注），其設計的目的是但願能對任何的數據庫進行SQL溢出注入。 BSQL Hacker的適用羣體是那些對注入有經驗的使用者和那些想進行自動SQL注入的人羣。BSQL Hacker可自動對Oracle和MySQL數據庫進行攻擊，並自動提取數據庫的數據和架構。