背景介紹
通過分析關于互聯網攻擊增長的幾個潛在因素，提到了關于個人信息已被明碼標價在互聯網上進行非法購買，而更多的黑客開始將精力投入到企業網站攻擊這樣的一個高回報率的攻擊行為中。也提到了關于web應用防火墻對于保護企業網站和防止數據竊取方面的獨到之處。今天我們就通過一個攻擊實例來具體了解攻擊是怎么發生的，又是如何進行數據竊取。另外，部署專業的web應用防火墻加上嚴格的安全管理策略才能真正為企業提供細致到位的安全防護。
文中引用的攻擊實例發生在一家國外已部署WEB應用防火墻產品的企業，由于處在網絡調整階段，所以防火墻被臨時置于“被動模式”（被動模式：只監控并記錄對網站的訪問，任何攻擊防護都未啟用），正是由于一時的疏忽，給黑客侵入該公司市場部數據庫制造了機會。分析顯示，發起該攻擊的黑客采用了多項應用攻擊手段，并且從亞洲和歐洲兩個區域分別發起攻擊。竊取了一部分資料，由于企業及時發現了攻擊行為，并將防火墻恢復到了主動模式（主動模式：監控記錄對網站的訪問，并且提供安全防護），沒有造成更嚴重的數據泄漏。
小貼士1：Web 應用的設計保證了數據能夠透明地穿過網絡防火墻，因此傳統的四層網絡防火墻無法檢測并阻止七層（應用層）的攻擊；然而，許多企業都還沒有充分意識到四層安全措施已經不能滿足當前的需求，從而使得這些企業極易受到針對各種應用的攻擊行為。
小貼士2：不管動機如何，針對 Web 應用的攻擊，尤其是 SQL 注入攻擊，都被證明是滲透網絡并竊取數據的最有效途徑：
Web 應用攻擊僅占全部數據泄露事件的 54%，但被竊取的數據占92％
SQL 注入攻擊僅占 Web 應用攻擊的25%，但是被竊取的數據占89%
數據泄露事件說明：
此次數據泄露事件的主要原因有以下幾點：
1. 網站的PHP 代碼存在錯誤
2. 原本應定期進行的代碼漏洞掃描被忽略，導致沒有及時發現PHP代碼問題
3. 網站維護人員沒有開啟Web應用防火墻的安全防護功能
對有漏洞的代碼未加以保護，受到攻擊只是個時間問題。根據Web應用防火墻的記錄和報告，攻擊的過程記錄如下：
時間 描述
2011-04-10 00:07:59 GMT 第一個IP開始對網站主頁進行探測
2011-04-10 00:16:15 GMT 攻擊者在嘗試了175個URL后找到了存在漏洞的URL，開始探測數據庫
2011-04-10 03:10:43 GMT 第二個IP地址開始對存在漏洞的URL進行探測
2011-04-10 10:10:00 GMT 攻擊開始，黑客試圖檢索數據庫用戶
2011-04-10 10:16:00 GMT 攻擊者放棄針對用戶的攻擊，轉而嘗試獲取數據庫的列表(list)和架構(schema)
2011-04-10 10:19:00 GMT 攻擊者開始盜取數據
2011-04-10 17:30:00 GMT 發現網站被攻擊
2011-04-10 17:37:00 GMT 發現WEB應用防火墻針的防護功能暫未開啟
2011-04-10 17:39:59 GMT 開啟WEB應用防火墻的防護功能， 此后沒有再發現任何攻擊行為發生
2011-04-10 21:00:00 GMT 源自這些IP地址的攻擊不再進行停止
數據泄露事件具體過程：我們將以圖解的方式結合各式日志來分解這次攻擊。
發現漏洞
第一次攻擊的開始時間為4月9日下午5:07，攻擊者的IP地址為 115.134.249.15，來自馬來西亞的吉隆坡，該日志條目證實了認為攻擊來自馬來西亞的在線報告。我們還注意到，攻擊者用以探測 Web 網站SQL 注入缺陷的是White hats設計的滲透工具的一個修改版；
第一個攻擊者使用自動工具逐步遍歷網站，并對每個允許輸入的參數項注入一系列 SQL 命令，查找可能的漏洞。SQL 注入工具于下午 5:16 找到了第一個漏洞，但沒有繼續深入該網頁；下午 8:10，IP地址為 87.106.220.57 的第二個客戶端加入了攻擊行列。經追蹤發現，第二個IP地址的服務器在德國，但尚不清楚該服務器是一個代理，還是第二個攻擊者。
從Web應用防火墻的日志發現，攻擊者似乎利用了第二個客戶端對已發現的漏洞進行了手動攻擊，而主要攻擊仍然集中在繼續對Web 站點進行掃描，以獲取其它漏洞。最終，攻擊者們集中力量攻擊非主頁的一個WEB 頁面上的一行弱代碼，其輸入參數并未進行控制審查。以下是那段代碼：<?=Foo_Function( $_GET[‘parameter’] )?> //獲得用戶輸入
因未對輸入值進行限定，該代碼錯誤讓攻擊者們得以向 HTML的輸入參數進行注入 SQL 命令來攻擊后臺數據庫。網站開發者們被告知絕對不要信任用戶的輸入；所有的用戶輸入在發送到后臺服務器之前必須進行審查。然而，通過上述案例，你可以發現僅僅用眼睛很難發現所有的代碼錯誤。這就是為什么除了必要的防范性代碼設計以外，企業還需要使用漏洞掃描工具和Web應用防火墻設備來為可能的缺陷提供保護。由于自動式掃描攻擊的存在，在一個含有成千上萬條代碼的 Web 站點中，只要有一個簡單的錯誤就能讓攻擊得逞。所以還需要添加了一條代碼，對受影響的頁面上的輸入進行限定審查，以保護未來的可能攻擊。
從漏洞到數據泄露
攻擊者們發現了存在漏洞的頁面后，企圖竊取數據庫用戶賬號。在接下來的 10個小時里，攻擊者們嘗試了數種方法來強行闖入后臺數據庫，但是每次都以失敗告終。上午3:06，攻擊者們改變了策略，集中攻擊后臺數據庫Schema。事實證明，正是這個方法。到 3:19am，攻擊者們已經竊取了第一批電子郵箱賬號。
網站管理員在10:30am 發現網站被攻擊，并于10:39am將Web應用防火墻切換到主動模式開啟保護，阻止了來自 IP 地址為 115.134.249.15 的所有后續攻擊。接下來的數小時里，攻擊者們繼續對剩下的 Web 頁面進行定時攻擊，Web應用防火墻設備將所有這些攻擊拒之門外。從攻擊文件證實了我們的結論，即：攻擊者們使用了一種自動掃描滲透工具，大范圍地注入 SQL 命令。最終，攻擊者們從兩個攻擊IP地址總共對 175 個URL 發送了 110,892 個 SQL 注入式命令，其頻率為每分鐘 42次。
追蹤Web應用防火墻上的防火墻日志和訪問日志時，確定攻擊者們竊取了市場部數據庫中的兩套記錄，包含 21,861 個用戶名和電子郵件記錄。因為這兩套記錄還存在副本，并且當中有許多用戶已離開原先的公司，所以受影響的用戶數比被竊取記錄的總數要小得多。
任何數據泄露都是嚴重的問題。盡管這次攻擊的后果還沒有進一步的顯現，但是類似的泄漏數據中的郵件帳號，可能被用來對受影響的用戶進行釣魚攻擊。
結論
這次攻擊事件，是一個非常有借鑒意義的教材；為企業和網管人員分享了經驗，從多個角度驗證對于網站攻擊或者數據竊取，部署專業的設備和嚴格的安全管理策略必不可少。
梭子魚Web應用防火墻設備產品能夠為網站提供對包括SQL注入在內的各種攻擊的防護。即使網頁中包含PHP代碼漏洞，但只要開啟梭子魚Web應用防火墻的防護功能，所有的攻擊都在幾秒鐘內都被阻止。而且，梭子魚Web應用防火墻的日志和報告提供了完整的攻擊記錄以及失竊數據的記錄，從而為分析和研究Web應用安全提供了一個很好的案例。為了保障網站的安全，在編寫高質量的代碼和進行漏洞測試的同時，梭子魚Web應用防火墻設備應該成為防御應用層攻擊的第一道防線。
