告訴你如何保障網路應用安全性

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

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

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

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

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

　　在開發週期的後期實施安全測試的高昂成本

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

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

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

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

　　整合方法的好處

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

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

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

　　整合性合成測試的好處

　　軟體測試的整合性的合成分析方法可以更大地提升效率。整合開發環境的特定插件在發現使用者的編碼錯誤時會向編碼人員發出警告。靜態分析，也稱為「白盒」測試，在將不同的模組組裝成最終的產品之前，開發人員和稽核人員就對其使用此技術。靜態分析在程式碼層級上提供了一種內部人員對應用程式的檢查分析。靜態分析對於發現語法錯誤和程式碼層級的缺陷是很有效的，但並不適於決定缺陷是否會導致可利用的漏洞。

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

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

　　將安全性建構到軟體的生命週期：實用方法

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

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

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

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

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

　　需求

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

　　將安全性整合到需求階段的步驟

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

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

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

　　架構和設計

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

　　將安全性整合到架構和設計階段的步驟

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

　　2. 評估應用程式與原有系統互動時的安全意義與風險，以及不同的元件、層或系統之間的資料流的安全性問題。

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

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

　　其好處體現在五個面向：

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

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

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

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

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

　　程式碼執行與編譯

　　在開發人員開始編寫程式碼時，他們對安全控制必須擁有一套完整的風險評估設計和清晰指南，或透過經認可的服務來使用這種安全控制。整合到IDE中的自動化靜態程式碼工具可以在編寫程式碼時向開發人員提供檢查和指南。自動化的工具還可在編譯期間用於對照策略範本檢查程式碼是否違規，並可以深入查看程式碼層級的安全性問題。

　　將安全性整合到程式碼執行和編譯階段的步驟

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

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

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

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

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

　　這會帶來如下的好處：

　　1. 可將更乾淨的或漏洞更少的程式碼提交給品質評價人員。

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

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

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

　　品質評估/測試

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

　　那麼，在品質評估和測試階段，應採取哪些整合安全和改善安全的步驟呢?

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

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

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

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

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

　　部署/投產

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

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

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

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

　　3. 將部署前的風險評估與投產後的暴露範圍進行比較，並向測試團隊提供回饋。

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

　　其好處有以下幾個面向：

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

　　2. 發現並阻止應用程式的誤用情況。

　　3. 在動態測試和投產中的應用程式控制(如網路應用防火牆或IPS)之間實現更好的整合。

　　4. 滿足再次編寫程式碼之前的合規需求。

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

　　小結

　　保障網路應用程式的安全未必意味著延長開發週期。只要對所有開發人員進行良好的教育，並採取清晰且可重複的建置流程，企業就可以以一種高效且可合作的方式將安全和風險納入開發過程中。

　　將安全性建置到網路應用程式的交付週期中確實需要一種合作性的方法，需要將人員、流程和技術整合到一起。雖然Web應用程式安全工具和套件有助於流程的改進，但它們並非萬靈丹。為獲得最大利益，應考慮選擇能夠理解完整開發週期的Web應用程式安全工具廠商，還要有能在開發過程的多個階段提供支援的工具。

以上是告訴你如何保障網路應用安全性的詳細內容。更多資訊請關注PHP中文網其他相關文章！