Web 安全與 Rational AppScan 入門
本文將從對 Web 應用現狀的分析入手，通過列舉常見的攻擊手段，闡明 Web 應用目前面臨的挑戰， 同時，通過對 Rational AppScan 平台的介紹，協助企業制定 Web 應用安全解決方案，為企業的 Web 應 用披上盔甲。在第一部分，將介紹 Web 安全與 Rational AppScan 的入門知識。在後續的 第二部分 將 介紹如何使用 Rational AppScan 應對 Web 應用攻擊。
前言
當今世界，Internet（因特 網）已經成為一個非常重要的基礎平台，很多企業都將應用架設在該平台上，為客戶提供更為方便、快捷 的服務支持。這些應用在功能和性能上，都在不斷的完善和提高，然而在非常重要的安全性上，卻沒有得 到足夠的重視。由於網絡技術日趨成熟，黑客們也將注意力從以往對網絡服務器的攻擊逐步轉移到了對 Web 應用的攻擊上。根據 Gartner 的最新調查，信息安全攻擊有 75% 都是發生在 Web 應用而非網絡層 面上。同時，數據也顯示，三分之二的 Web 站點都相當脆弱，易受攻擊。然而現實確是，絕大多數企業 將大量的投資花費在網絡和服務器的安全上，沒有從真正意義上保證 Web 應用本身的安全，給黑客以可 乘之機。
本文將從對 Web 應用現狀的分析入手，通過列舉常見的攻擊手段，闡明 Web 應用目前面臨的挑戰， 同時，通過對 Rational AppScan 平台的介紹，協助企業制定 Web 應用安全解決方案，為企業的 Web 應 用披上盔甲。
Web 應用現狀
Web 應用的基礎概念
在討論 Web 應用安全之前，先簡 單介紹一下 Web 應用基礎概念，這樣便於理解為什麼 Web 應用是脆弱的，容易受到攻擊。
1、 什麼是 Web 應用
Web 應用是由動態腳本、編譯過的代碼等組合而成。它通常架設在 Web 服務器 上，用戶在 Web 浏覽器上發送請求，這些請求使用 HTTP 協議，經過因特網和企業的 Web 應用交互，由 Web 應用和企業後台的數據庫及其他動態內容通信。
2、 Web 應用的架構
盡管不同的企業會有不同的 Web 環境搭建方式，一個典型的 Web 應用通常是標准的三層架構模型， 如圖 1 所示。
圖 1: Web 應用通常是標准的三層架構模型
在這種最常見的模型中，客戶端是第一層；使用動態 Web 內容技術的部分屬於中間層；數據庫是第三 層。用戶通過 Web 浏覽器發送請求（request）給中間層，由中間層將用戶的請求轉換為對後台數據的查 詢或是更新，並將最終的結果在浏覽器上展示給用戶。
Web 應用安全全景
當討論起 Web 應用安全，我們經常會聽到這樣的回答：
“我們使用了防火牆”、“我們使用了網絡脆弱掃描工具”、“我們使用了 SSL 技術”、“我們每個 季度都會進行滲透測試”……所以，“我們的應用是安全的”。現實真是如此嗎？讓我們一起來看一下 Web 應用安全的全景圖。
圖 2: 信息安全全景
在企業 Web 應用的各個層面，都會使用不同的技術來確保安全性。為了保護客戶端機器的安全，用戶 會安裝防病毒軟件；為了保證用戶數據傳輸到企業 Web 服務器的傳輸安全，通信層通常會使用 SSL（安 全套接層）技術加密數據；企業會使用防火牆和 IDS（入侵診斷系統）/IPS（入侵防御系統）來保證僅允 許特定的訪問，不必要暴露的端口和非法的訪問，在這裡都會被阻止；即使有防火牆，企業依然會使用身 份認證機制授權用戶訪問 Web 應用。
但是，即便有防病毒保護、防火牆和 IDS/IPS，企業仍然不得不允許一部分的通訊經過防火牆，畢竟 Web 應用的目的是為用戶提供服務，保護措施可以關閉不必要暴露的端口，但是 Web 應用必須的 80 和 443 端口，是一定要開放的。可以順利通過的這部分通訊，可能是善意的，也可能是惡意的，很難辨別。 這裡需要注意的是，Web 應用是由軟件構成的，那麼，它一定會包含缺陷（bugs），這些 bug 就可以被 惡意的用戶利用，他們通過執行各種惡意的操作，或者偷竊、或者操控、或者破壞 Web 應用中的重要信 息。
因此可以看出，企業的回答，並不能真正保證企業的應用安全：
網絡脆弱性掃描工具，由於它僅僅用來分析網絡層面的漏洞，不了解應用本身，所以不能徹底提高 Web 應用安全性；
防火牆可以阻止對重要端口的訪問，但是 80 和 443 端口始終要開放，我們無法判斷這兩個端口中通 訊數據是善意的訪問還是惡意的攻擊；
SSL 可以加密數據，但是它僅僅保護了在傳輸過程中數據的安全性，並沒有保護 Web 應用本身；
每個季度的滲透測試，無法滿足處於不斷變更之中的應用。
只要訪問可以順利通過企業的防火牆，Web 應用就毫無保留的呈現在用戶面前。只有加強 Web 應用自 身的安全，才是真正的 Web 應用安全解決之道。
常見的 Web 應用攻擊
兩個重要的國際應用安全組織
在討論常見的 Web 應用攻擊之前，我們需要先了解兩個組織：WASC 和 OWASP。這兩個組織在呼吁企 業加強應用安全意識和指導企業開發安全的 Web 應用方面，起到了重要的作用。
Web Application Security Consortium（WASC），是一個由安全專家、行業顧問和諸多組織的代表組 成的國際團體。他們負責為 WWW 制定被廣為接受的應用安全標准。WASC 組織的關鍵項目之一是“Web 安 全威脅分類”，也就是將 Web 應用所受到的威脅、攻擊進行說明並歸納成具有共同特征的分類。該項目 的目的是針對 Web 應用的安全隱患，制定和推廣行業標准術語。WASC 將 Web 應用安全威脅分為如下六 類：
Authentication（驗證）用來確認某用戶、服務或是應用身份的攻擊手段。Authorization（授權）用 來決定是否某用戶、服務或是應用具有執行請求動作必要權限的攻擊手段。Client-Side Attacks（客戶 側攻擊）用來擾亂或是探測 Web 站點用戶的攻擊手段。Command Execution（命令執行）在 Web 站點上 執行遠程命令的攻擊手段。Information Disclosure（信息暴露）用來獲取 Web 站點具體系統信息的攻 擊手段。Logical Attacks（邏輯性攻擊）用來擾亂或是探測 Web 應用邏輯流程的攻擊手段。
Open Web Application Security Project（OWASP），該組織致力於發現和解決不安全 Web 應用的根 本原因。它們最重要的項目之一是“Web 應用的十大安全隱患”，總結了目前 Web 應用最常受到的十種 攻擊手段，並且按照攻擊發生的概率進行了排序。這個項目的目的是統一業界最關鍵的 Web 應用安全隱 患，並且加強企業對 Web 應用安全的意識。
圖 3: Web 應用十大安全隱患
IBM Rational，是上述兩個組織的成員。
常見的 Web 應用攻擊示例
在 OWASP 組織列舉的十大 Web 應用安全隱患中，有兩個概率最高的攻擊手段，它們分別是“跨站點 腳本攻擊”（Cross-Site Scripting）和“注入缺陷”（Injection Flaws）。下面將通過舉例來說明這 兩種攻擊是如何實施的。
1、 跨站點腳本攻擊
首先來看一下跨站點腳本的利用過程，如圖 4。
圖 4: 跨站點腳本攻擊的過程
在上圖中，惡意攻擊者（這裡使用 Evil.org 表示）通過 E-mail 或 HTTP 將某銀行的網址鏈接發給 用戶（銀行用 bank.com 表示），該鏈接中附加了惡意的腳本（上圖步驟一）；用戶訪問發來的鏈接，進 入銀行網站，同時，嵌在鏈接中的腳本被用戶的浏覽器執行（上圖步驟二、三）；用戶在銀行網站的所有 操作，包括用戶的 cookie 和 session 信息，都被腳本收集到，並且在用戶毫不知情的情況下發送給惡 意攻擊者（上圖步驟四）；惡意攻擊者使用偷來的 session 信息，偽裝成該用戶，進入銀行網站，進行 非法活動（上圖步驟五）。
因此，只要 Web 應用中，有可被惡意攻擊者利用執行腳本的地方，都存在極大的安全隱患。黑客們如 果可以讓用戶執行他們提供的腳本，就可以從用戶正在浏覽的域中偷到他的個人信息、可以完全修改用戶 看到的頁面內容、跟蹤用戶在浏覽器中的每一個動作，甚至利用用戶浏覽器的缺陷完全控制用戶的機器。
目前，跨站點腳本攻擊是最大的安全風險。
2、 注入缺陷
目前的 Web 應用中，絕大多數都會向用戶提供一個接口，用來進行權限驗證、搜索、查詢信息等功能 。比如一個在線銀行應用，首先會有對注冊客戶進行身份驗證的登錄界面，在正確登錄後，會提供更多交 互功能，如根據客戶的銀行卡號信息，查詢客戶的最近交易、轉賬細節等。這些都是注入缺陷的最佳利用 場景。所謂注入缺陷，就是在上述場景中，用戶輸入的數據被當做命令和查詢的一部分，送到後端的解釋 器中解釋執行。如果用戶的輸入是正常合法的，Web 應用自然會返回正常合理的結果，但是，如果惡意攻 擊者，利用輸入數據可被後台執行的原理，偷梁換柱，使用非法的輸入，脆弱的 Web 應用會怎樣呢？
下面我們舉一個例子來說明注入缺陷是如何進行的。在一個交易網站中，用戶必須輸入產品 ID 號才 可以查看該產品的詳細信息。為了實現這個需求，通常會用 SQL 語句查詢數據庫來實現。開發人員在編 寫應用程序時，可能會使用如下的 SQL 語句來實現上述目的（這裡僅為示例）：
1) Select * from products where product_id = ` + 用戶輸入的 ID + `
這裡的 products 是數據庫中用來存放產品信息的表，＋號表示 SQL 語句需要和用戶輸入的真實 ID 進行拼接。如果用戶輸入 325，則該語句在執行時變為：
Select * from products where product_id = ` 325 `
數據庫會將 ID 為 325 的產品信息返回給用戶。
2) 在界面上，需要用戶輸入產品 ID 的地方，黑客會輸入如下數據：
` or `1`= `1
可以看到，黑客並沒有輸入正常合法的產品編號。
3) 通過黑客的非法輸入，需要執行的 SQL 語句變為：
Select * from products where product_id = ` ` or `1`=`1`
可以看出，SQL 語句的意義就完全改變了，當產品 ID 為空或者 1＝1 時，返回產品所有信息，而 1 ＝1 是永遠成立的條件，因此，黑客並沒有輸入任何產品編號，就可以返回數據庫中所有產品的詳細信息 。
通過這個例子，我們可以看出，注入缺陷是風險非常高的安全漏洞，一旦 Web 應用中給用戶提供了需 要其輸入數據的接口，就有可能遭到攻擊，將後台的數據完全暴露在用戶的面前。
上述說明的“跨站點腳本攻擊”和“注入缺陷攻擊”，是目前 Web 應用中比例最高的兩種攻擊手段， 按照 OWASP 的項目排序，還有如下八種風險性較高的攻擊方法：
Malicious File Execution（惡意文件執行）；
Insecure Direct Object Reference（不安全的直接對象引用）；
Cross-Site Request Forgery（跨站點的請求偽造）；
Information Leakage and Improper Error Handling（信息洩漏和不正確的錯誤處理）；
Broken Authentication & Session Management（損壞的認證和 Session 管理）；
Insecure Cryptographic Storage（不安全的密碼存儲）；
Insecure Communications（不安全的通信）；
Failure to Restrict URL Access（未能限制 URL 訪問）
在這裡，我們就不過多的討論這幾種安全隱患，可以使用 3.1 節中提供的鏈接得到更多的描述信息。
構築安全的 Web 應用
功能和性能，往往是我們衡量應用是否滿足需求的指標，但是，對於載體為 Internet 的特殊應用－ Web 應用而言，安全性也是必要的考量標准，皮之不存，毛將焉附？如果失去了安全性，即使功能再完備 、性能再可靠的 Web 應用，一旦遭到黑客的攻擊和破壞，一切都失去了意義。因此企業，尤其是提供 Web 應用的企業，一定要加強對應用安全的重視程度。
針對目前 Web 應用安全性不高的現狀，IBM Rational 提出了構築安全 Web 應用的解決方案。
加強全員應用安全性意識
一個根本、底層的戰略手段就是加強企業全員的應用安全意識。正如前面所闡述過的，對於應用而言 ，無論是開發人員、測試人員、質量管理人員還是項目經理、企業高層，都會對其功能和性能做更多的關 注，這也是由於早期應用多為 C/S 架構的應用，安全問題並不突出。但是在當今的環境，就不得不將安 全作為應用質量的基礎。
圖 5 中功能、易用性、可靠性、性能、可支持性，是由 Rational Unified Process（RUP）定義的 FURPS 質量模型，它告訴我們應用的質量需要從這幾個方面著手衡量，對於 Web 應用，就必須將安全性 作為質量模型的基礎條件。
圖 5: 適於 Web 應用的質量模型
要加強全員應用安全意識，就需要對每一個相關角色落實安全要求。
1) 對於需求分析、設計人員而言，是否已將產品的安全性考慮到產品的需求設計中，從而保證在項目 初期，安全因素已被關注；
2) 對於開發人員，在應用中實現了身份認證等安全功能，並不意味著在編程中已考慮到了應用安全性 ，它們還必須掌握 Web 應用安全編程規范等技術；
3) 對於測試人員，驗證了應用的 FURPS，不能保證產品已具備安全性，還需要借助其他工具或平台， 對應用的安全隱患，進行自動化的掃描，得出全面的安全性報告；
4) 對於質量管理人員，產品的質量過關，也不等於產品已經安全可靠，他們和測試人員一樣，需要借 助工具，掌握 Web 應用全面的安全隱患匯總和分析。
使用先進的工具確保軟件開發生命周期中的安全性
在企業全員都具有了應用安全意識之後，必須將該意識貫徹到項目的具體工作之中，除了要求每個人 具備嚴謹認真、不斷學習的態度之外，還需要借助先進的工具，對開發的 Web 應用進行自動化的安全隱 患發現、分析、報告、提供修復意見等工作，建立人工檢查和自動化工具配合的完整保障措施。IBM Rational AppScan，正是這樣一種 Web 應用自動化診斷工具，下面我們對其進行簡單的介紹。
Rational AppScan，是對 Web 應用和 Web Services 進行自動化安全掃描的黑盒工具，它不但可以簡 化企業發現和修復 Web 應用安全隱患的過程（因為這些工作，以往都是由人工進行，成本相對較高，但 是效率卻非常低下），還可以根據發現的安全隱患，提出針對性的修復建議，並能形成多種符合法規、行 業標准的報告，方便相關人員全面了解企業應用的安全狀況。圖 6 說明了 AppScan 在軟件開發生命周期 中的各個階段，都可以協助安全隱患的診斷。
圖 6: AppScan 對軟件開發生命周期的支持
1) 開發過程中的安全保障
AppScan DE（AppScan 開發版）可以作為多種平台的插件，這些平台包括 Eclipse、WebSphere、 Visual Studio、JBuilder，協助開發人員對編寫的模塊進行自我安全診斷。圖 7 是 AppScan DE 作為 Visual Studio 插件使用的示例。
圖 7: AppScan DE 作為 Visual Studio 的插件
2) 質量管理過程中的安全保障
通過和 Rational ClearQuest 的集成，AppScan 可以將發現的安全隱患方便的導入到變更管理平台中 ，確保發現的每一個問題，都被記錄，並詳細跟蹤其在整個修復過程中的狀態變化。如圖 8 所示。
圖 8: AppScan 和 Rational ClearQuest 集成
除 Rational ClearQuest 之外，AppScan 還可以和 Mercury 的 Quality Center 集成。
3) 在集成和發布階段中的安全保障
在集成和發布階段，可以通過簡單的配置，使用 AppScan 對應用進行全面的掃描，企業僅需要指明 Web 應用的入口鏈接，AppScan 就會利用網絡爬行（Crawling）技術，遍歷應用中所有需要測試的鏈接， 並對每個鏈接發送多種測試參數，診斷其有無漏洞可被利用。最後將結果呈現在用戶面前。如圖 9 是對 示例網站 http://demo.testfire.net 進行診斷的結果。
從結果可以看出，本次診斷共發現了 88 個安全隱患，並按照嚴重程度進行了統計。診斷結果的中部 ，顯示了 AppScan 掃描出來的應用結構、每個模塊或鏈接包含的漏洞數；右上方則按照嚴重程度，對掃 描出來的漏洞進行了分類；結果的右下方對每一種隱患，進行了解釋，並提出了詳細的修復建議，同時說 明了為發現這個漏洞，AppScan 發送了哪些測試參數等。
圖 9: AppScan 的診斷結果示例
4) 對診斷結果進行全面的分析和報告
Rational AppScan 不僅可以對 Web 應用進行自動化的掃描、指出安全漏洞的修復意見，還可以將診 斷結果，使用不同的行業標准、法規，形成針對性的報告，讓相關人員對應用安全狀況和法規遵從等有了 全面的認識。如圖 10，左圖是 AppScan 可以自動生成的行業標准報告，而右圖則是近 40 種的法規遵從 報告，如賽班斯法規遵從等。
圖 10: 自動生成的行業標准報告
小結
通過上述對 Web 應用現狀和常見的 Web 應用攻擊示例分析，我們可以看出，目前因特網上的 Web 應 用，存在著極大的安全隱患和風險，企業對 Web 應用安全的保護，已經刻不容緩。IBM Rational AppScan，作為先進的 Web 應用自動化診斷工具，可以協助企業在整個 Web 應用開發生命周期，將安全 意識貫徹到企業全員具體的工作中，高效率的發現應用中存在的安全隱患、給出詳細的修復建議、並生成 多種符合行業標准和法規的報告，已在全球擁有近千個成功案例，是一個完整的、端到端的 Web 應用安 全解決方案，能真正為企業的 Web 應用披上安全的盔甲。
