Web 安全與 Rational AppScan 入門

weixin_34262482發表於2011-05-31
WebAPP
在討論 Web 應用安全之前，先簡單介紹一下 Web 應用基礎概念，這樣便於理解為什麼 Web 應用是脆弱的，容易受到***。
1、 什麼是 Web 應用
Web 應用是由動態指令碼、編譯過的程式碼等組合而成。它通常架設在 Web 伺服器上，使用者在 Web 瀏覽器上傳送請求，這些請求使用 HTTP 協議，經過因特網和企業的 Web 應用互動，由 Web 應用和企業後臺的資料庫及其他動態內容通訊。
2、 Web 應用的架構
儘管不同的企業會有不同的 Web 環境搭建方式，一個典型的 Web 應用通常是標準的三層架構模型，如圖 1 所示。

圖 1: Web 應用通常是標準的三層架構模型
Web
在這種最常見的模型中，客戶端是第一層；使用動態 Web 內容技術的部分屬於中間層；資料庫是第三層。使用者通過 Web 瀏覽器傳送請求（request）給中間層，由中間層將使用者的請求轉換為對後臺資料的查詢或是更新，並將最終的結果在瀏覽器上展示給使用者。
當討論起 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 應用***之前，我們需要先了解兩個組織：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 應用十大安全隱患
Web
可以通過如下的網址訪問該組織，瞭解更為詳細的資訊：[url]www.owasp.org[/url]。也可以通過參考資料中連結，具體瞭解“Web 應用十大安全隱患”專案。
IBM Rational，是上述兩個組織的成員。
在 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 節中提供的連結得到更多的描述資訊。


 		 回頁首


功能和效能，往往是我們衡量應用是否滿足需求的指標，但是，對於載體為 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 對軟體開發生命週期的支援
AppScan
1) 開發過程中的安全保障
AppScan DE（AppScan 開發版）可以作為多種平臺的外掛，這些平臺包括 Eclipse、WebSphere、Visual Studio、JBuilder，協助開發人員對編寫的模組進行自我安全診斷。圖 7 是 AppScan DE 作為 Visual Studio 外掛使用的示例。

圖 7: AppScan DE 作為 Visual Studio 的外掛
AppScan
2) 質量管理過程中的安全保障
通過和 Rational ClearQuest 的整合，AppScan 可以將發現的安全隱患方便的匯入到變更管理平臺中，確保發現的每一個問題，都被記錄，並詳細跟蹤其在整個修復過程中的狀態變化。如圖 8 所示。

圖 8: AppScan 和 Rational ClearQuest 整合
AppScan
除 Rational ClearQuest 之外，AppScan 還可以和 Mercury 的 Quality Center 整合。
3) 在整合和釋出階段中的安全保障
在整合和釋出階段，可以通過簡單的配置，使用 AppScan 對應用進行全面的掃描，企業僅需要指明 Web 應用的入口連結，AppScan 就會利用網路爬行（Crawling）技術，遍歷應用中所有需要測試的連結，並對每個連結傳送多種測試引數，診斷其有無漏洞可被利用。最後將結果呈現在使用者面前。如圖 9 是對示例網站 [url]http://demo.testfire.net[/url] 進行診斷的結果。
從結果可以看出，本次診斷共發現了 88 個安全隱患，並按照嚴重程度進行了統計。診斷結果的中部，顯示了 AppScan 掃描出來的應用結構、每個模組或連結包含的漏洞數；右上方則按照嚴重程度，對掃描出來的漏洞進行了分類；結果的右下方對每一種隱患，進行了解釋，並提出了詳細的修復建議，同時說明了為發現這個漏洞，AppScan 傳送了哪些測試引數等。

圖 9: AppScan 的診斷結果示例
AppScan
4) 對診斷結果進行全面的分析和報告
Rational AppScan 不僅可以對 Web 應用進行自動化的掃描、指出安全漏洞的修復意見，還可以將診斷結果，使用不同的行業標準、法規，形成針對性的報告，讓相關人員對應用安全狀況和法規遵從等有了全面的認識。如圖 10，左圖是 AppScan 可以自動生成的行業標準報告，而右圖則是近 40 種的法規遵從報告，如賽班斯法規遵從等。

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


 		 回頁首


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

相關文章