[置顶] SQL注入安全分析
?
?
(一)???????應用環(huán)境列表
網(wǎng)絡互聯(lián)設備操作系統(tǒng)
| 序號 | 操作系統(tǒng)名稱 | 設備名稱 | 脆弱性 |
| 1 | IOS_路由器_內(nèi)部_1 | route1 | ? |
| 2 | IOS_路由器_VPN_1 | 路由器_VPN_1 | ? |
| 3 | IOS_路由器_VPN_2 | 路由器_VPN_2 | ? |
業(yè)務應用軟件
| 序號 | 軟件名稱 | 主要功能 | 脆弱性 |
| 1 | 安全電子郵件服務系統(tǒng)web應用平臺 | 安全電子郵件服務系統(tǒng)運行平臺程序 | 管理界面暴露 |
主機（存儲）操作系統(tǒng)
| 序號 | 設備名稱 | 操作系統(tǒng)/數(shù)據(jù)庫管理系統(tǒng) | 脆弱性 |
| 1 | Web郵件服務器 | Windows Server | ? |
數(shù)據(jù)庫管理系統(tǒng)
| 序號 | 設備名稱 | 操作系統(tǒng)/數(shù)據(jù)庫管理系統(tǒng) | 脆弱性 |
| 1 | 數(shù)據(jù)庫服務器 | Sql Server 2000 | ? |
?
(二)???????SQL注入攻擊的簡單示例
statement := ?"SELECT *FROM Users WHERE Value= " + variable + "
這條語句是很普通的一條SQL語句，他主要實現(xiàn)的功能就是讓用戶輸入一個編號然后查詢處這個編號對應的信息。但是若這條語句被改裝，就可能成為破壞數(shù)據(jù)的黑手。如攻擊者在輸入變量的時候，輸入以下內(nèi)容admin’;drop table Users--。那么這條SQL語句在執(zhí)行的時候就變?yōu)榱薙ELECT* FROM Users WHERE Value= ‘a(chǎn)dmin’;drop table Users--。
篡改后的語句具有什么樣的功能呢？首先‘a(chǎn)dmin’后面的分號表示一個查詢的結(jié)束和另一條語句的開始。Users字符串后的雙連字符，指示執(zhí)行器當前行余下的部分只是一個注釋，應該忽略。如果修改后的代碼語法正確，則服務器將執(zhí)行該代碼。系統(tǒng)在處理這條語句時，將首先執(zhí)行查詢語句，查到用戶編號為”admin” 的用戶信息。然后，數(shù)據(jù)將刪除表Users(前提是Users表沒有內(nèi)外主鍵關(guān)聯(lián)情況下，則刪除操作就會成功)。只要注入的SQL代碼語法正確，便無法采用編程方式來檢測篡改。因此，必須驗證所有用戶輸入，并仔細檢查在您所用的服務器中執(zhí)行構(gòu)造 SQL命令的代碼。
?
?
(三)???????Sql注入安全攻擊原理
1)???????SQL注入是目前比較常見的針對數(shù)據(jù)庫的一種攻擊方式。在這種攻擊方式中，攻擊者會將一些惡意代碼插入到字符串中。然后會通過各種手段將該字符串傳遞到SQLServer數(shù)據(jù)庫的實例中進行分析和執(zhí)行。只要這個惡意代碼符合SQL語句的規(guī)則，則在代碼編譯與執(zhí)行的時候，就不會被系統(tǒng)所發(fā)現(xiàn)。
2)???????SQL注入式攻擊的主要形式有兩種。一是直接將代碼插入到與SQL命令串聯(lián)在一起并使得其以執(zhí)行的用戶輸入變量。由于其直接與SQL語句捆綁，故也被稱為直接注入式攻擊法。二是一種間接的攻擊方法，它將惡意代碼注入要在表中存儲或者作為原數(shù)據(jù)存儲的字符串。在存儲的字符串中會連接到一個動態(tài)的SQL命令中，以執(zhí)行一些惡意的SQL代碼。
3)???????注入過程的工作方式是提前終止文本字符串，然后追加一個新的命令。如以直接注入式攻擊為例。就是在用戶輸入變量的時候，先用一個分號結(jié)束當前的語句。然后再插入一個惡意SQL語句即可。由于插入的命令可能在執(zhí)行前追加其他字符串，因此攻擊者常常用注釋標記“—”來終止注入的字符串。執(zhí)行時，系統(tǒng)會認為此后語句位注釋，故后續(xù)的文本將被忽略，不背編譯與執(zhí)行。
?
?
?
(四)???????漏洞風險加固列表
1.????????風險類型01
?
| 風險名稱 | 固定的獨立參數(shù)滲透 |
| 風險級別 | 中 |
| 攻擊形式 | 傳入名稱、關(guān)鍵字等參數(shù)或不是通過Filter生成查詢條件串的 |
| 解決方案 | 1)??????? SQLServer數(shù)據(jù)庫專門設計了相對安全的SQL參數(shù)。在數(shù)據(jù)庫設計過程中，采用這些參數(shù)來杜絕惡意的SQL注入式攻擊。如在SQL Server數(shù)據(jù)庫中提供了Parameters集合。這個集合提供了類型檢查和長度驗證的功能。如果采用了Parameters這個集合的話，則用戶輸入的內(nèi)容將被視為字符值而不是可執(zhí)行代碼。即使用戶輸入的內(nèi)容中含有可執(zhí)行代碼，則數(shù)據(jù)庫也會過濾掉。因為此時數(shù)據(jù)庫只把它當作普通的字符來處理。 2)??????? 使用Parameters集合的另外一個優(yōu)點是可以強制執(zhí)行類型和長度檢查，范圍以外的值將觸發(fā)異常。如果用戶輸入的值不符合指定的類型與長度約束，就會發(fā)生異常，并報告給管理員。 |
?
2.????????風險類型02
?
| 風險名稱 | SQL截斷攻擊 |
| 風險級別 | 低 |
| 攻擊形式 | 利用SQL語句超長時會截或內(nèi)部SQL文本串緩沖變量定義長度大小時會被截斷而進行的攻擊 |
| 解決方案 | 1)??????? 對查詢條件的輸入值一定要有長度限制，包括UI驗證上一定要有長度驗證，防止過長的條件 2)??????? 存儲過程中的SQL文本緩沖變量長度定義時要足夠大以保證不會產(chǎn)生SQL語句截斷 |
?
3.????????風險類型03
?
| 風險名稱 | WEB的遠程管理漏洞 |
| 風險級別 | 高 |
| 攻擊形式 | 注入攻擊盜取web遠程管理用戶與權(quán)限，遠程管理認證網(wǎng)頁中會有型如：select * from admin where username='XXX' and passWord='YYY' 的語句，若在正式運行此句之前，沒有進行必要的字符過濾，則很容易實施SQL注入。如在用戶名文本框內(nèi)輸入：abc’ or 1=1-- 在密碼框內(nèi)輸入：123 則SQL語句變成：select * from admin where username='abc’ or 1=1 and password='123’ 不管用戶輸入任何用戶名與密碼，此語句永遠都能正確執(zhí)行，用戶輕易騙過系統(tǒng)，獲取合法身份。進行木馬或者惡意程序上傳。 |
| 解決方案 | 1)??????? 加強對用戶輸入的驗證，用戶輸入?yún)?shù)過濾，對敏感字符和數(shù)據(jù)在不影響正常交互前提下，進行替換與截獲過濾。 2)??????? 敏感數(shù)據(jù)片段，使用參數(shù)化SQL查詢語言和數(shù)據(jù)庫安全參數(shù)，如Parameters 3)??????? 普通用戶與系統(tǒng)管理員用戶的權(quán)限要有嚴格的區(qū)分 4)??????? 使用類安全(type-safe)的參數(shù)加碼機制，保證用戶輸入?yún)?shù)正常escaped/encoded |
?
4.????????風險類型04
?
| 風險名稱 | 盜用數(shù)據(jù)字典 |
| 風險級別 | 高 |
| 攻擊形式 | 利用猜解方式盜取服務器數(shù)據(jù)庫數(shù)據(jù)字典 1)??????? 猜解數(shù)據(jù)庫名稱 HTTP://xxx.xxx.xxx/abc.jsp?p=YY and (select count(*) from master.dbo.sysdatabases where name>1 and dbid=6) <>0 因為 dbid 的值從1到5，是系統(tǒng)用了。所以用戶自己建的一定是從6開始的。并且我們提交了 name>1 (name字段是一個字符型的字段和數(shù)字比較會出錯),abc.jsp工作異常，可得到第一個數(shù)據(jù)庫名，同理把DBID分別改成7,8，9,10,11,12…就可得到所有數(shù)據(jù)庫名。 2)??????? 猜解用戶表 SQL-SERVER有一個存放系統(tǒng)核心信息的表sysobjects，有關(guān)一個庫的所有表，視圖等信息全部存放在此表中，而且此表可以通過WEB進行訪問。當xtype='U' and status>0代表是用戶建立的表，發(fā)現(xiàn)并分析每一個用戶建立的表及名稱，便可以得到用戶名表的名稱，基本的實現(xiàn)方法是 |
| 解決方案 | 1)??????? 加強對用戶輸入的驗證，用戶輸入?yún)?shù)過濾，對敏感字符和數(shù)據(jù)在不影響正常交互前提下，進行替換與截獲過濾。 2)??????? 敏感數(shù)據(jù)片段，使用參數(shù)化SQL查詢語言和數(shù)據(jù)庫安全參數(shù)，如Parameters 3)??????? 普通用戶與系統(tǒng)管理員用戶的權(quán)限要有嚴格的區(qū)分 4)??????? 使用類安全(type-safe)的參數(shù)加碼機制，保證用戶輸入?yún)?shù)正常escaped/encoded |
?
5.????????風險類型05
?
| 風險名稱 | 構(gòu)造SQL注入代碼 |
| 風險級別 | 高 |
| 攻擊形式 | 提交數(shù)據(jù)表單時，通過參數(shù)或者表單數(shù)據(jù)植入OR1=1–或者OR1=1--,植入SQL代碼，獲取系統(tǒng)內(nèi)用戶數(shù)據(jù) ? |
| 解決方案 | 1)??????? 數(shù)據(jù)和命令進行嚴格區(qū)分過濾或替換 2)??????? 敏感數(shù)據(jù)片段，使用參數(shù)化SQL查詢語言和數(shù)據(jù)庫安全參數(shù)，如Parameters 3)??????? 使用參數(shù)加碼機制，輸入?yún)?shù)傳輸利用escaped/encoded 4)??????? 訪問服務鏈接統(tǒng)一采用post機制，防數(shù)據(jù)在URL泄露 |
?
6.????????風險類型06
?
| 風險名稱 | SQL字符集編碼注入 |
| 風險級別 | 高 |
| 攻擊形式 | 利用數(shù)據(jù)字符編碼漏洞，例如where xtype=’U’ 字符U對應的ASCII碼是85，繼而用where xtype=char(85)代替；如果字符是中文的，比如where name=’admin’，可以用where name=nchar(29992)+nchar(25143)代替。繞過程序敏感數(shù)據(jù)過濾器進行注入欺騙 |
| 解決方案 | 1)??????? 使用參數(shù)加碼機制，輸入?yún)?shù)傳輸利用escaped/encoded 2)??????? 利用html轉(zhuǎn)義函數(shù)，對頁面數(shù)據(jù)特殊字符轉(zhuǎn)義，如htmlEscape、htmlUnescape等。 3)??????? 業(yè)務處理接收數(shù)據(jù)時，嚴格判斷用戶數(shù)據(jù)對應數(shù)據(jù)類型，阻止數(shù)據(jù)類型欺騙攻擊 |
?
?
7.????????風險類型07
?
| 風險名稱 | Script客戶端腳本攻擊 |
| 風險級別 | 高 |
| 攻擊形式 | 編寫瀏覽器可執(zhí)行的腳本文件，如VBScript、JavaScript篡改頁面數(shù)據(jù)或篡改頁面樣式，進行篡改或攔截用戶提交數(shù)據(jù)信息，造成sql執(zhí)行非法數(shù)據(jù)，典型的應用場景。如，火車票訂票插件 |
| 解決方案 | 1)??????? 設置瀏覽器的安全級別 2)??????? 屏蔽頁面右鍵選項，禁止查看頁面源代碼 3)??????? 服務器接入接口，嚴格做數(shù)據(jù)類型判斷、信息檢索 4)??????? 使用參數(shù)加碼機制，輸入?yún)?shù)傳輸利用escaped/encoded |
?
8.????????風險類型08
?
| 風險名稱 | 數(shù)據(jù)庫執(zhí)行非法Cookie篡改數(shù)據(jù) |
| 風險級別 | 高 |
| 攻擊形式 | 利用瀏覽器cookie數(shù)據(jù)信息，非法修改cookie數(shù)據(jù)，致使客戶端做數(shù)據(jù)上傳時，服務器記錄、篡改用戶數(shù)據(jù) |
| 解決方案 | 1)???? 避免直接在cookie?中泄露用戶隱私，例如email、密碼等等。 2)??????? 通過使cookie?和系統(tǒng)ip?綁定來降低cookie?泄露后的危險。這樣攻擊者得到的cookie?沒有實際價值，不可能拿來重放。 |
?
?
?
?
總結(jié)
以上是生活随笔為你收集整理的[置顶] SQL注入安全分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 反编译中内部类调用外部类成员问题
- 下一篇： Server 2008 Core/服务器