Web應用程式安全趨勢

Web應用安全引言

Web應用程式的高速增長直接導緻了相關安全事件的增加。現在，Web應用安全正受到越來越多的關注，并且在安全事務中的優先級也在不斷提高，但是在技術領域仍然存在一些阻礙。這篇文章彙集了有關Web應用程式安全在技術和商業方面的趨勢。

網絡層與應用層的融合

通常意義上的風險評估和管理主要針對網絡層或者作業系統層，利用手工滲透測試以及一些自動化安全評估工具來完成。當下的發展趨勢上傾向于網絡掃描器與應用層弱點掃描工具的融合。前一階段賽門鐵克收購@Stake可能不僅僅是為了獲得@Stake在服務領域的生意，還看重了@Stake豐厚的技術積累。我們将同樣在網絡管理軟體領域看到類似的融合。

現在大多數網絡管理終端适用于類似防火牆這樣處理資訊請求的裝置。未來的發展趨勢是将除網絡層之外的各種應用層處理工具（例如應用層網關）整合進來。一個沒有明顯展現出這種趨勢的領域可能是更新檔管理系統。雖然網絡管理軟體的控制台能夠與更新檔管理産品進行良好的捆綁，但由于很多Web應用程式是公司某個部門自行定制開發的，是以在這種情況下很難将網管軟體與這些Web應用的對接，而隻能由其開發者手動進行漏洞修複等工作。

QA測試和開發知識

通常，QA(Quality Assurance)小組并不與資訊安全人員為伍，但是有趨勢顯示了這種思維正在轉變。自動化測試工具領域的主導廠商Mercury Interactive最近宣布與一些主要的安全檢測供應商合作，提供自己測試産品與其檢測工具的整體解決方案。

這意味着QA小組要成為安全專家？并非如此。整體解決方案允許QA測試人員繼續完成他們的自動化測試，而無需了解相關的安全技術。在大多數情況下我們将看到企業根據自身的安全政策建立相應的自動化測試，并由QA專業人員來負責執行。

我們期待看到QA小組的工作從功能性測試向符合性測試擴充。舉例來說，為了符合不同地區的隐私法案，QA小組可以決定哪些Web頁面需要提及隐私政策，以及哪些頁面應該在表單的送出中透漏URL資訊。

開發人員也将受益于不斷發展的的Web應用程式弱點檢測工具。理想情況下，檢測系統能夠從有缺陷的代碼行中找到安全漏洞，這種功能可能會象代碼編輯功能一樣成為開發工具的基本元件。一些廠商已經開始為提高代碼安全性推出相應的開發工具，但目前這些工具的銷售情況還不是太好，因為大多數這類工具不能提供完整的應用程式了解能力，而隻能針對特定的模式進行操作。同時我們可以預期內建Bug追蹤系統的出現，這将簡化開發人員現在所使用的缺陷跟蹤方法，并使開發人員可以象處理功能缺陷一樣簡便的處理安全缺陷。

進階的行業知識

這裡彙集了一些技術方面的資訊以供大家增進Web應用程式安全弱點方面的知識。至于到底哪些資訊管道對于商業産品開發更具影響力目前尚未有明顯的結論。

下面是兩個在應用程式安全技術發展方面起到關鍵作用的組織：

l   Open Web Application Security Project (OWASP) – 做為最權威的組織之一，釋出針對主要Web應用程式安全漏洞的Top Ten清單。

l   OASIS Web應用程式安全技術委員會 – 發展将Web應用弱點及攻擊進行分類并生成XML schema的技術。

Web應用程式安全檢測技術能夠為邊界防禦設施（如防火牆和入侵檢測系統）提供更為廣泛的檢測能力，不同的标準和廠商聯盟也将是以産生。目前比較優秀的标準包括應用漏洞描述語言（Application Vulnerability Description Language）和Web應用安全（Web Application Security），兩者都基于XML标準。

從微軟釋出的安全資訊也能獲得豐富的知識，這一點已經開始迅速在開發社群中獲得認同。另外象美國資訊技術協會（ITAA）這樣的行業組織，預先為離岸的程式提供Web應用安全方面的指導，很多離岸的公司也努力提高其産品的安全水準以為他們的客戶提供更好的服務。

攻擊檢測精度的發展

Web應用漏洞檢測技術變得日益精細起來。大多數工具的發展已經超越了通過指紋識别簡單緩沖區溢出攻擊的階段。對于呈增長趨勢的跨站腳本（XSS）攻擊，一般的方法是使用内嵌檢測的方式進行處理，并且檢測方法正從簡單的内嵌字元串注入檢測發展為多層次的攻擊檢測。複雜之處在于對性能（Web應用和使用者輸入産生的互動所用的海量資料）和精度（減少誤報）的處理。對于一些大型金融機構最近揭示的跨架構腳本（XFS）攻擊，一種特殊類型的利用頁面中的架構技術的網絡釣魚方法，廠商也及時對檢測方法進行了更新。

Web服務是另一個受到關注的領域。當更多的網站和線上應用程式依賴Web服務的時候，我們迫切需要對Web服務的安全弱點進行檢驗。在極大程度上，廠商隻是利用一些簡單的技術檢測畸形XML schema攻擊，并将現有的非XML應用程式弱點知識應用于XML應用程式。在這一領域仍有很多工作需要完成，這決定了我們的商業應用能否信賴Web服務。

檢測工具的增長

包括使用者建立自定義測試這樣的新功能正被加入到工具之中，以提供為新的安全弱點編寫腳本的能力。傳統模式下我們通常從廠商處擷取程式更新，一般需要六個月到九個月的時間 – 相對于資訊安全世界的變化來說這實在是太過緩慢了。一個關鍵的挑戰在于這些政策腳本采用怎樣的格式，目前VB、javascript和Nessus的NASL語言正被廠商廣泛使用。很快，定義和設計得更加完善的檢測工具将可以選用更多的腳本語言，并有效的将開源工具融入商業程式。

風險評估工具的最關鍵的能力并不僅僅是攻擊能力，更在于如何快速的擷取新的攻擊方法并成功的檢測這種攻擊。另一個衡量Web應用程式測試工具的重要尺度是所能發現漏洞的數量以及産生的誤報數量，誤報使我們必須付出巨大的努力手工過濾資料中的虛假内容。

主流的攻擊檢測工具也象傳統的故障檢測工具一樣由簡單的模式比對（例如搜尋404錯誤頁面）向更加複雜的檢測手段（例如使用者配置的規則表達式）演化。未來的趨勢在于發展啟發式檢測技術，近年來湧現的zero-day防禦技術從已知安全漏洞的行為中學習其模式并在未知行為的檢測中進行應用（現在一些入侵檢測系統使用了這樣的技術）。

目前大多數高階的安全測試人員使用包括商業和開源産品的多種工具來完成工作。主要的理由在于大多數工具隻能發現已有漏洞中很少的一部分。按照我們的經驗，大多數工具在檢測典型Web應用程式的時候至少應該發現已知漏洞的25-50%。一些廠商允許使用者增加自己的腳本以對産品進行擴充，這有助于增加能夠發現漏洞的數量，也能減少誤報的發生。顯然，象檢測技術的發展一樣，産品的精确性也将持續得到改善。其間使用者應該關注更重要的需求，正确的評估工具的彈性和擴充能力。

另一個有待成長的是對于Web應用程式用戶端的測試能力。大多數站點非常倚重javascript技術。然而現在很少有工具能夠妥善的對類似javascript這樣的用戶端腳本進行測試和處理。對廠商來說這個問題或許非常困難，因為在編碼風格方面大家所受的訓練存在着很大的不同。是以，面對弱點檢測工具中需要内建代碼掃描程式的需要，産品供應商們面臨着不小的挑戰。

結語

目前大多數Web應用安全測試工具仍然集中在滲透測試人員和安全專家的手中，但已有向QA從業人員和審計專家擴充的趨勢。我們的一個美好遠景是所有開發人員都能夠肩負起編寫安全代碼的責任，安全永遠是一個整體，需要所有相關的人同心協力構築良好的防禦。