“SQL注入”的前世今生和防御思路
“SQL1注入”流行之前，緩沖區(qū)溢出2是最有效的黑客滲透方法，但經(jīng)歷了一些嚴重事件后（如：Code Red、Nimda、SQL Slammer），現(xiàn)在很多網(wǎng)絡管理員的安全意識增強了，一般都能及時安裝系統(tǒng)補丁，而且軟、硬件廠商都針對溢出問題做了很多解決方案，可以說：緩沖區(qū)溢出在黑客攻擊中的路越來越窄。這時候，針對CGI3程序的滲透被黑客發(fā)現(xiàn)是更有效的辦法，因為CGI程序作為Web應用程序的一部分，通常開發(fā)周期很短，相應的測試環(huán)節(jié)很少，普遍存在缺陷，那么這些CGI程序就有可能成為突破點。下面我們就將介紹CGI攻擊的一大分支：SQL注入。
1、SQL即結構查詢語言（Structured Query Language），一種ANSI (美國國家標準學會) 標準語言，用于訪問、操作關系數(shù)據(jù)庫系統(tǒng)（Relational database systems）。
2、緩沖區(qū)溢出是指當計算機向緩沖區(qū)內(nèi)填充數(shù)據(jù)位數(shù)時超過了緩沖區(qū)本身的容量溢出的數(shù)據(jù)覆蓋在合法數(shù)據(jù)上。理想的情況是：程序檢查數(shù)據(jù)長度并不允許輸入超過緩沖區(qū)長度的字符,但是絕大多數(shù)程序都會假設數(shù)據(jù)長度總是與所分配的儲存空間相匹配,這就為緩沖區(qū)溢出埋下隱患.操作系統(tǒng)所使用的緩沖區(qū)又被稱為"堆棧". 在各個操作進程之間,指令會被臨時儲存在"堆棧"當中,"堆棧"也會出現(xiàn)緩沖區(qū)溢出。
3、Common Gate Interface，簡稱CGI。在物理上是一段程序，運行在服務器上，提供同客戶端 Html頁面的接口。舉個例子：現(xiàn)在的個人主頁上大部分都有一個留言本。留言本的工作是這樣的：先由用戶在客戶端輸入一些信息，如名字之類的東西。接著用戶按一下“留言”（到目前為止工作都在客戶端），瀏覽器把這些信息傳送到服務器的CGI目錄下特定的CGI程序中，于是CGI程序在服務器上按照預定的方法進行處理。在本例中就是把用戶提交的信息存入指定的文件中。然后CGI程序給客戶端發(fā)送一個信息，表示請求的任務已經(jīng)結束。此時用戶在瀏覽器里將看到“留言結束”的字樣。整個過程結束。
“SQL注入”現(xiàn)在已經(jīng)成為互聯(lián)網(wǎng)上最通用的攻擊方式，通過Google、百度等搜索引擎，可以發(fā)現(xiàn)很多相關說明文章和攻擊軟件。這類攻擊的流行，一方面是由于Web應用的迅速普及和Web后臺數(shù)據(jù)價值上升，攻擊者受經(jīng)濟利益驅(qū)使；另一方面，攻擊軟件的泛濫降低了技術門檻，如SQL注入自動化攻擊工具實現(xiàn)了“目標鎖定、發(fā)現(xiàn)注入點及注入攻擊”全過程自動化，尤其是自動完成“發(fā)現(xiàn)注入點”這一關鍵步驟，極大地方便了攻擊者，提高了攻擊成功率。
1、“SQL注入”的定義
很多Web應用程序都使用數(shù)據(jù)庫來存儲信息。SQL命令就是前端Web和后端數(shù)據(jù)庫之間的接口，使得數(shù)據(jù)可以傳遞至Web應用程序。很多Web站點都會利用用戶輸入的參數(shù)動態(tài)地生成SQL查詢要求，攻擊者通過在URL、表單域，或者其他的輸入域中輸入自己的SQL命令，以此改變查詢屬性，騙過應用程序，從而可以對數(shù)據(jù)進行不受限的訪問。
SQL注入漏洞成因在于Web應用程序?qū)τ脩籼峤籆GI參數(shù)數(shù)據(jù)未做充分檢查過濾。用戶提交的數(shù)據(jù)可能會被用來構造訪問后臺數(shù)據(jù)庫的SQL指令，如果這些數(shù)據(jù)過濾不嚴格就有可能被插入惡意的SQL代碼，從而非授權操作后臺的數(shù)據(jù)庫，導致從敏感信息泄露、破壞數(shù)據(jù)庫內(nèi)容和結構、甚至利用數(shù)據(jù)庫本身的擴展功能控制服務器操作系統(tǒng)。利用SQL注入漏洞可以構成對Web服務器的直接攻擊，還可能利用服務器攻擊第三方的瀏覽網(wǎng)站的其他用戶。
2、“SQL注入”的歷史
我們簡單回顧一下SQL注入的相關歷史。
1998年12月， Rain Forest Puppy（RFP） 在Phrack 54上發(fā)表文章“NT Web Technology Vulnerabilities”，首次提到SQL注入；
1999年2月，Allaire發(fā)出警告 “Multiple SQL Statements in Dynamic Queries”；
1999年5月， RFP與Matthew Astley發(fā)出警告 “NT ODBC Remote Compromise”；
2000年2月，RFP發(fā)表文章 “How I hacked Packetstorm – A look at hacking wwthreads via SQL”，披露如何利用SQL注入攻擊滲透Packetstorm網(wǎng)站；
2000年9月，David Litchfield在Blackhat會議上發(fā)表主題演講“Application Assessments on IIS” ；
2000年10月，Chip Andrews在SQLSecurity.com 上發(fā)表“SQL Injection FAQ ”，首次公開使用“SQL注入”這個術語 ；
2001年4月，David Litchfield 在Blackhat會議上發(fā)表主題演講 “Remote Web Application Disassembly with ODBC Error Messages”；
2002年1月，Chris Anley發(fā)表論文“Advanced SQL Injection in SQL Server”，首次深度探討該類攻擊。
2002年6月，Chris Anley發(fā)表論文 “(more) Advanced SQL” ，補充同年1月發(fā)表的論文缺少的細節(jié)。
2004年Blackhat會議上， 0x90.org發(fā)布了SQL注入工具SQeaL ( Absinthe的前身)。
3、“SQL注入”的演進
SQL注入攻擊技術出現(xiàn)已有10多年歷史，該種攻擊技術被廣為利用。2007年，出現(xiàn)了新型的攻擊方法。之前，SQL注入攻擊針對特定的Web應用程序，攻擊者事先已經(jīng)了解到了底層數(shù)據(jù)庫的架構以及應用程序注入點。而新型攻擊與以往有很大不同。它將可能攻擊任何存在SQL注入漏洞的動態(tài)ASP頁面。
根據(jù)網(wǎng)絡世界（Network World）的報導，2008年5月13日，在中國大陸、香港及臺灣地區(qū)有數(shù)萬個網(wǎng)站遭遇一輪 SQL注入攻擊，并引發(fā)大規(guī)模掛馬。同期，根據(jù)微軟的報導，在4個月時間內(nèi)，發(fā)生了3次大規(guī)模攻擊，受害者包括某知名防病毒軟件廠商網(wǎng)站、歐洲某政府網(wǎng)站和某國際機構網(wǎng)站在內(nèi)的多家互聯(lián)網(wǎng)網(wǎng)站，感染頁面數(shù)最多超過10，000頁面/天。
具體攻擊方式，如下圖1所示。黑客首先使用Google搜索引擎定位網(wǎng)頁中包含的動態(tài)ASP腳本，測試腳本是否存在SQL注入漏洞并確定注入點，最終試圖遍歷目標網(wǎng)站后臺SQL Server數(shù)據(jù)庫的所有文本字段，插入指向惡意內(nèi)容（即黑客控制的服務器）的鏈接。攻擊的整個過程完全自動化，一旦攻擊得逞，這些自動插入的數(shù)據(jù)將嚴重破壞后臺數(shù)據(jù)庫所存儲的數(shù)據(jù)，動態(tài)腳本在處理數(shù)據(jù)庫中的數(shù)據(jù)時可能出錯，各級頁面不再具有正常的觀感。被攻擊站點也可能成為惡意軟件的分發(fā)點，訪問這些網(wǎng)站的網(wǎng)民可能遭受惡意代碼的侵襲，用戶的系統(tǒng)被植入木馬程序從而完全為攻擊者控制。
圖1：SQL注入攻擊示意圖
4、防御“SQL注入”的思路
盡管由于攻擊的泛濫，人們防護SQL注入的安全意識已大為提升，但仍然有眾多的人缺乏系統(tǒng)、具體的防護概念。下面將簡要介紹如何以一種綜合的方法來正確防護SQL注入。如下圖2所示，理想的解決思路是在Web應用生命周期的各個階段做相應的努力。
圖2：基于Web生命周期的SQL注入防護方法
1)開發(fā)階段
在編碼階段需要對輸入進行細致的驗證，使用靜態(tài)查詢，如使用參數(shù)化聲明。且遵循“最小權限準則”，即只賦予應用程序完成其功能的最基本權限。以下是關于最小權限的一些建議：
不要使用root權限訪問數(shù)據(jù)庫
為數(shù)據(jù)表設定限制的可讀/可寫權限
慎用數(shù)據(jù)庫存儲過程
2)測試階段
在測試階段采用以下兩種方式確保Web應用程序代碼的安全性：第一，采用源代碼審核方式，從編程者角度審視代碼是否存在漏洞；第二，執(zhí)行滲透測試，從攻擊者角度檢查代碼的安全性。需要注意的是，盡管完成以上兩步，仍不能確保100%的安全，但這兩種方法對于確保應用程序質(zhì)量是必須的。
3)產(chǎn)品化階段
在產(chǎn)品化階段，Web應用程序已經(jīng)正常上線，并對外提供服務。但還是會發(fā)現(xiàn)Web應用存在安全隱患，此時整改代碼對各類組織來說已經(jīng)不現(xiàn)實了，因為需要付出較大代價。這時，可以部署專用的Web應用防火墻（Web Application Firewall，簡稱WAF），以大幅提升Web應用的安全等級。
【編輯推薦】
