Web應用程序是當今多數企業應用的前沿陣地。Web應用程序在一個復雜的混合性架構中可以發揮多種不同的功能。其涉及范圍極廣，從在最新的云技術上運行的面向服務的方案，到較老的多層Web應用程序，再到準許客戶訪問大型主機上老應用程序的Web入口，都有其應用。

管理與這些復雜的Web應用程序相關的風險是公司的必然要求，而且運行這些Web應用程序的底層代碼的安全性直接影響到公司應用程序可用數據的風險態勢。不幸的是，開發可重復的高效Web應用程序的安全實踐并非一項簡單任務。許多單位試圖運用后生產(post-production)解決方案來提供安全控制，如Web應用防火墻和入侵防御系統等。

但是一直等到生命周期的生產階段才部署安全機制有點兒太遲，其效用也太小。設計或架構問題在生命周期的早期階段更容易解決，如果等到應用程序投入生產之后再“亡羊補 牢”,其所花費的成本將極其高昂。Web應用程序的安全漏洞可導致數據泄露、違反策略，而且，在部署后再打補丁或進行全面的代碼修復都會極大地增加總成本。

為保證效益和效率，Web應用程序的安全必須從需求的定義階段開始，直至最后的接收階段。這種方法要求全體設計人員在整個過程中能夠作為一個團隊通力合作。在實施和測試等階段，使用遵循策略的自動化工具能夠支持可重復的測試，并且隨著測試過程的標準化可以使開發周期更快。

在開發過程的最初階段就著手構建安全性未必很復雜。在整個開發周期實施安全檢查和平衡，可以實現更快的發布周期，并可以極大地減少Web應用程序的漏洞。

在開發周期的后期實施安全測試的高昂成本

將安全檢查點加入到開發過程中，確實可以減少總體交付時間。這聽起來有點兒違反直覺，但是，在Web應用程序部署進入生產階段之后，與糾正設計錯誤和代碼錯誤相關的成本是極其高昂的。

例如，在許多開發環境中，安全和審核專家往往出現在開發周期結束之時。此時，應用程序已經完成，任何延誤都被看作是多余的瓶頸。企業方面要求軟件產品快速推出，這種巨大的壓力意味著可能會忽略安全控制，導致Web應用程序沒有經過恰當的安全審查。在這種時間極端敏感的環境，即使掃描工具報告了大量的漏洞但卻沒有經過驗證，也沒有確定其優先次序，這種掃描也是弊大于利。

在開發過程的后期進行安全審計，而不是在整個開發周期中協力完成，會導致發布時間延遲，特別是在發現了某些嚴重的錯誤時尤其如此。在開發周期的后期修復設計和編碼錯誤的成本遠遠高于早期發現錯誤所花費的成本。根據美國國家科學基金會的一項研究估計，如果在需求和設計階段發現和糾正了嚴重的軟件問題，其成本要比將軟件投入生產之后再發現問題所花費的成本大約低100倍。

在Web應用程序中構建安全性時，在多數情況下，其目標并不是構建固若金湯的Web應用程序，或者清除每一處可能的漏洞。相反，目標應當是將所要求的特性與經認可的關于Web應用程序的風險預測匹配起來。在整個Web應用程序的開發周期中，其目標應當是實現軟件擔保，即與特定Web應用程序相適應的功能和敏感水平，能夠有理由保證軟件將會持續地實現其所要求的特性，即使軟件遭受攻擊也能夠如此。#p#

整合方法的好處

當來自不同小組的開發人員作為一個團隊協同工作時，就會造就Web應用程序開發過程的高效率。雖然安全專業人員常常慨嘆商務主管完全不理解軟件風險，但是安全專業人員熟悉商業風險也很重要。通過適當的軟件擔保水平來構建Web應用程序，要求在商業需要、可用性和安全性之間進行風險管理權衡。為了達到適當的平衡，必須收集所有開發人員的需求。

從軟件開發的開始階段，需求定義和應用程序的設計就應當考慮安全需求以及功能需求和商業需要。在編寫代碼之前，這種信息就應當傳達給設計師和軟件開發人員。這種方法可以防止多數甚至是全部安全設計漏洞和架構漏洞。

然而，關注安全的軟件設計并不是排除與Web應用程序相關的所有漏洞。開發人員自身必須接受關于安全編碼技術的培訓，以確保在應用程序的設計期間，并不 會帶來安全漏洞。讓開發人員洞察開發語言和運行環境的安全方法可以支持更好的編碼實踐，并會使最終的Web應用程序出現的錯誤更少。將安全性納入到設計過程中的另一個效率上的利益是，能夠在需求和設計期間建立誤用情形。在測試和接收階段這樣做可以節省時間，并有助于消除瓶頸。

整合性合成測試的好處

軟件測試的整合性的合成分析方法可以更大地提升效率。集成開發環境的特定插件在發現用戶的編碼錯誤時會向編碼人員發出警告。靜態分析，也稱為“白盒”測試，在將不同的模塊組裝成最終的產品之前，開發人員和審計人員就對其使用此技術。靜態分析在代碼水平上提供了一種內部人員對應用程序的檢查分析。靜態分析對于發現語法錯誤和代碼水平的缺陷是很有效的，但并不適于決定一個缺陷是否會導致可利用的漏洞。

動態分析和人工滲透測試對于驗證應用程序是否容易受到攻擊是有效的。它也被稱為“黑盒測試”，主要展示的是外部人員對應用程序的檢查分析，可以對投入生產的應用程序進行深入檢查，查看攻擊者是否容易利用其漏洞。然而，動態測試技術僅能用于軟件開發的后期，只能在生成后階段。動態測試的另一個局限性是它很難找出代碼中導致漏洞的代碼源。

這就是將靜態測試和動態測試結合起來以“灰盒”或組合的方法進行混合測試的原因。通過將代碼水平的內部檢查和動態的外部檢查結果結合起來，就可以充分利用兩種技術的長處。使用靜態和動態評估工具可以使管理人員和開發人員區分應用程序、模塊、漏洞的優先次序，并首先處理影響最大的問題。組合分析方法的另外一個好處是動態測試確認的漏洞可 以用靜態工具追溯到特定的代碼行或代碼塊。這便有利于測試和開發團隊進行合作性交流，并使得安全和測試專家更容易向開發人員提供具體的可操作的糾錯指導。#p#

將安全性構建到軟件的生命周期中：實用方法

構建安全性需要人員、過程以及技術、方法。雖然有大量的工具可有助于自動化地強化Web應用程序的安全，但是，如果沒有恰當的過程和訓練有素的人員來創建、測試Web應用程序，那么，任何工具都不會真正有效。

這個過程應當包括一個正式的軟件開發周期及所公布的策略。此外，為所有的開發人員建立角色，并且指派檢查和監管責任也是很重要的。安全和業務在軟件開發周期的每一個階段都應當得到表現，從而可以在每一個步驟處理風險管理。

在軟件的整個開發周期，一個有益的永恒主題就是教育。教育對于開發人員是很重要的，它對于Web應用程序開發所涉及到的全體人員都很有益。因為安全意識 既需要從上而下，也需要從下而上。不要低估教育管理人員認識到Web應用程序的漏洞如何影響企業的重要性。告訴一位管理人員Web應用程序易于遭受跨站請 求偽造(CSRF)可能會令他感到茫然，但是如果向他展示軟件錯誤如何會導致客戶數據的泄露，就能夠有助于使其意識到不安全的Web應用程序所造成的切實 后果。應該準備特定的案例和度量標準用以闡明潛在的各種成本節約。例如，在開發人員檢查其代碼之前，就演示對開發人員的培訓和IDE的靜態分析插件投資可 以阻止軟件應用中的數據泄露根源。

審計人員和評估人員可以從學 習常見的編碼錯誤、后果評估以及與Web應用程序“生態系統”(包括后端的支撐系統、現有的安全控制以及屬于Web應用程序環境的任何服務或應用程序)有關的依賴關系中獲益。測試者及質量評價專家應當熟知誤用情形，并且知道誤用情形是如何區別于標準的應用的，還要知道如何解釋安全測試結果，并能夠按照需要 對結果區分優先次序。

關注軟件開發周期中的具體步驟，在這些步驟中存在著增加效率同時又可以貫徹安全性和風險管理的機會。

需求

Web應用程序的設計者對于定義功能和業務需求非常熟悉，但是未必理解如何定義安全需求。此時，整個團隊需要協同工作，決定哪些安全控制對最終的Web應用程序至關重要。

將安全性集成到需求階段的步驟

1. 根據公司策略、合規和規章要求，討論并定義安全需求。

2. 安全和審計團隊應當評估業務需求和Web應用程序的功能，并且在測試和接受期間開始制定誤用案例(誤用情形)。

其好處有兩方面，一是提前清除或減少安全或違規問題，二是減少部署時間。#p#

架構和設計

由于已經定義了Web應用程序的架構和設計方案，下一步就需要評估安全問題。正是在這個階段，成本高昂的、難以糾正的安全問題可以在其最易于解決的時間 修復。為了防止損失慘重的錯誤，應當從性能和安全兩個方面評估程序的架構。由于編制了詳細的設計規范，因而可以向開發人員展示出應當包括哪些安全控制，以及應用程序的組件如何與完整的Web應用程序進行交互。

將安全性集成到架構和設計階段的步驟

1. 對于所建議的架構和部署環境執行風險評估，以決定設計是否會帶來風險。

2. 評估應用程序與原有系統進行交互時的安全意義和風險，以及不同的組件、層或系統之間的數據流的安全問題。

3. 評述在實施或部署階段需要解決的任何具體的暴露問題(即依賴于應用程序的部署方式和部署位置的漏洞)。

4. 考慮依賴關系以及與混搭關系、SOA及合伙服務的交互所引起的漏洞。將最終的設計交付安全和審計，以確定安全測試計劃和誤用情形。

其好處體現在五個方面：

1. 可以精心協調風險評估分析過程和可重用的風險評估模型。

2. 可以在早期階段確定由架構環境或部署環境所帶來的風險。

3. 可重用的誤用案例可以節省測試階段的時間。

4. 減少特定的設計漏洞。

5. 如果有必要，可以調整或變更帶來風險的架構限制，如果無法完全清除風險,也可以用補償性控制來定義減輕風險的策略。#p#

代碼執行與編譯

在開發人員開始編寫代碼時，他們對安全控制必須擁有一套完整的風險評估設計和清晰指南，或通過經認可的服務來使用這種安全控制。集成到IDE中的自動化靜態代碼工具可以在編寫代碼時向開發人員提供檢查和指南。自動化的工具還可在編譯期間用于對照策略模板檢查代碼是否違規，并可以深入查看代碼水平的安全問題。

將安全性集成到代碼執行和編譯階段的步驟

1. 安裝可與集成開發環境整合到一起的靜態源碼檢查工具。

2. 作為一種選擇，開發人員在交付代碼之前可以用獨立的編碼工具來執行自動化的代碼檢查。

3. 安全和審核團隊抽查代碼模塊，看其是否遵循合規要求，并在編譯之前使用自動化的或手動的代碼檢查來檢查其安全風險。

4. 在編譯過程中，執行自動化的靜態代碼掃描，查找安全問題和策略的遵循情況。

5. 使用工具跟蹤開發人員的編碼錯誤，并對其帶來的安全風險提供解釋性反饋和原因說明。

這會帶來如下的好處：

1. 可將更清潔的或漏洞更少的代碼提交給質量評價人員。

2. 隨著時間的推移開人人員可以提升安全編碼能力。

3. 可重用策略可以提升風險分析的正確性。

4. 在測試階段發現的編碼錯誤或漏洞更少，并會使開發周期更短。#p#

質量評價/測試

用于測試應用程序的具體安全工具范圍很廣，其中有可以評估完整應用程序的獨立解決方案和服務，更有完全集成的套件,這種套件可以提供測試和對從教育到實施等多個階段的支持。集成的方案可以為那些對可重復的Web應用程序的安全周期表現成熟的公司提供多個階段的支持。集成套件可以在進程中的多個時點上實施，并可為持續的改善提供尺度和反饋。

那么，在質量評價和測試階段，應采取哪些集成安全和改善安全的步驟呢?

1. 專注于發現某些資源的最重要問題。

2. 在一個包括現有的補救控制(如防火墻和IPS)的應用架構中驗證這些測試發現。

3. 根據安全性和業務需要，區分所發現的漏洞的優先次序。

4. 對于代碼行或其所依賴的API、服務、庫等提出修復建議。

其好處也是顯而易見的：1. 應用程序開發人員之間可以更好地交流。2. 似是而非的東西更少。3. 修復周期更快。

部署/投產

Web應用程序的安全性并不會終止于應用程序的部署階段。一旦Web應用程序投產，還應當實施其它測試和監視，用以確保數據和服務受到保護。實際的 Web應用程序的自動安全監視能夠確保應用程序正在如所期望的那樣運行，并且不會泄露信息從而造成風險。監視可由內部人員完成，也可外包給能夠全天候監視 應用程序的外部供應商。

在部署和投產階段集成和改善安全性的步驟：

1. 監視誤用情況，其目的是為了確定測試中所謂的“不會被利用的漏洞”在投產后真得不會被利用。

2. 監視數據泄露，其目的是為了查找被錯誤地使用、發送或存儲的所有地方。

3. 將部署前的風險評估與投產后的暴露范圍進行比較，并向測試團隊提供反饋。

4. 實施Web應用防火墻、IPS或其它的補救措施，其目的是為了減輕代碼修復之前的暴露程度，或是為了符合新的安全規范。

其好處有如下幾個方面：

1. 改善能夠成功實施的漏洞利用的知識庫，從而改善在靜態和動態測試期間的掃描效益。

2. 發現并阻止應用程序的誤用情況。

3. 在動態測試和投產中的應用程序控制(如Web應用防火墻或IPS)之間實現更好的集成。

4. 滿足再次編寫代碼之前的合規需要。

5. 使用反饋機制實現持續的改善。

小結

保障Web應用程序的安全未必意味著延長開發周期。只要對所有開發人員進行良好的教育，并采取清晰且可重復的構建過程，企業就可以用一種高效而合作性的方式將安全和風險納入到開發過程中。

將安全構建到Web應用程序的交付周期中確實需要一種合作性的方法，需要將人員、過程和技術集成到一起。雖然Web應用程序安全工具和套件有助于過程的改進，但它們并非萬能藥。為獲得最大利益，應當考慮選擇能夠理解完整開發周期的Web應用程序安全工具廠商，還要有能在開發過程的多個階段提供支持的工具。