Web 安全與 Rational AppScan 入門

Web 應用現狀

Web 應用的基礎概念

在討論 Web 應用安全以前，先簡單介紹一下 Web 應用基礎概念，這樣便於理解爲何 Web 應用是脆弱的，容易受到***。

一、什麼是 Web 應用

Web 應用是由動態腳本、編譯過的代碼等組合而成。它一般架設在 Web 服務器上，用戶在 Web 瀏覽器上發送請求，這些請求使用 HTTP 協議，通過因特網和企業的 Web 應用交互，由 Web 應用和企業後臺的數據庫及其餘動態內容通訊。

二、 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 應用邏輯流程的***手段。

能夠經過以下的網址訪問該組織網站，得到更多詳細信息： [url]www.webappsec.org[/url]。也能夠經過參考資料中連接，具體瞭解「Web 安全威脅分類」項目。

Open Web Application Security Project（OWASP），該組織致力於發現和解決不安全 Web 應用的根本緣由。它們最重要的項目之一是「Web 應用的十大安全隱患」，總結了目前 Web 應用最常受到的十種***手段，而且按照***發生的機率進行了排序。這個項目的目的是統一業界最關鍵的 Web 應用安全隱患，而且增強企業對 Web 應用安全的意識。

圖 3: Web 應用十大安全隱患

能夠經過以下的網址訪問該組織，瞭解更爲詳細的信息： [url]www.owasp.org[/url]。也能夠經過參考資料中連接，具體瞭解「Web 應用十大安全隱患」項目。

IBM Rational，是上述兩個組織的成員。

常見的 Web 應用***示例

在 OWASP 組織列舉的十大 Web 應用安全隱患中，有兩個機率最高的***手段，它們分別是「跨站點腳本***」（Cross-Site Scripting）和「注入缺陷」（Injection Flaws）。下面將經過舉例來講明這兩種***是如何實施的。

一、跨站點腳本***

首先來看一下跨站點腳本的利用過程，如圖 4。

圖 4: 跨站點腳本***的過程

在上圖中，惡意***者（這裏使用 Evil.org 表示）經過 E-mail 或 HTTP 將某銀行的網址連接發給用戶（銀行用 bank.com 表示），該連接中附加了惡意的腳本（上圖步驟一）；用戶訪問發來的連接，進入銀行網站，同時，嵌在連接中的腳本被用戶的瀏覽器執行（上圖步驟2、三）；用戶在銀行網站的全部操做，包括用戶的 cookie 和 session 信息，都被腳本收集到，而且在用戶絕不知情的狀況下發送給惡意***者（上圖步驟四）；惡意***者使用偷來的 session 信息，假裝成該用戶，進入銀行網站，進行非法活動（上圖步驟五）。

所以，只要 Web 應用中，有可被惡意***者利用執行腳本的地方，都存在極大的安全隱患。***們若是可讓用戶執行他們提供的腳本，就能夠從用戶正在瀏覽的域中偷到他的我的信息、能夠徹底修改用戶看到的頁面內容、跟蹤用戶在瀏覽器中的每個動做，甚至利用用戶瀏覽器的缺陷徹底控制用戶的機器。

目前，跨站點腳本***是最大的安全風險。

二、注入缺陷

目前的 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 是對示例網站 [url]http://demo.testfire.net[/url] 進行診斷的結果。

從結果能夠看出，本次診斷共發現了 88 個安全隱患，並按照嚴重程度進行了統計。診斷結果的中部，顯示了 AppScan 掃描出來的應用結構、每一個模塊或連接包含的漏洞數；右上方則按照嚴重程度，對掃描出來的漏洞進行了分類；結果的右下方對每一種隱患，進行了解釋，並提出了詳細的修復建議，同時說明了爲發現這個漏洞，AppScan 發送了哪些測試參數等。

圖 9: AppScan 的診斷結果示例

4) 對診斷結果進行全面的分析和報告

Rational AppScan 不只能夠對 Web 應用進行自動化的掃描、指出安全漏洞的修復意見，還能夠將診斷結果，使用不一樣的行業標準、法規，造成針對性的報告，讓相關人員對應用安全情況和法規聽從等有了全面的認識。如圖 10，左圖是 AppScan 能夠自動生成的行業標準報告，而右圖則是近 40 種的法規聽從報告，如賽班斯法規聽從等。

圖 10: 自動生成的行業標準報告

回頁首

小結

經過上述對 Web 應用現狀和常見的 Web 應用***示例分析，咱們能夠看出，目前因特網上的 Web 應用，存在着極大的安全隱患和風險，企業對 Web 應用安全的保護，已經刻不容緩。IBM Rational AppScan，做爲先進的 Web 應用自動化診斷工具，能夠協助企業在整個 Web 應用開發生命週期，將安全意識貫徹到企業全員具體的工做中，高效率的發現應用中存在的安全隱患、給出詳細的修復建議、並生成多種符合行業標準和法規的報告，已在全球擁有近千個成功案例，是一個完整的、端到端的 Web 應用安全解決方案，能真正爲企業的 Web 應用披上安全的盔甲。

本文同步分享在博客「xjsunjie」（51CTO）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。web