由于WEB應用程序對于當今許多企業的內部和外部操作都極端重要，所以其可用性和安全性既是客戶的期望又是其要求。因而，企業應該在WEB應用程序問題上不惜一切代價。同時，WEB應用程序的重要性也給安全專家帶來巨大壓力，因為沒有什么會比企業的關鍵網站或應用被攻擊、破壞更恐怖了。不幸的是，在構建應用程序的競賽中，許多企業給開發者施加壓力，要求其重點關注應用程序的安全。

本文將探討如何在WEB應用程序的性能、可用性、安全性上達到平衡。

安全策略

在WEB應用程序安全問題上保持前瞻性和主動性應當成為IT的頭等大事。如果WEB應用程序遭受破壞，企業往往會遭受極大損失。對于大型企業，丟失的不僅僅是金錢，更重要的是聲譽的喪失。重要WEB應用程序經常遭受攻擊會使客戶和公司的CEO不滿。不管是否可以避免攻擊，IT往往會遭受譴責，雖然這未必公平。

在CIO和CFO們談到“安全”時，他們往往會為高額費用而震驚。但是，企業未必需要將大把的金錢用于強化WEB應用程序。要贏得WEB安全的保衛戰，企業需要打“組合拳”：將相關解決安全問題的最佳方法和工具結合起來。

你不必請一位資深的CISSP來加固你的WEB應用程序，也不必花太多金錢。但成功地強化企業的WEB應用確實需要花費時間、努力和一些交涉技巧(你對安全的擔憂和關注在項目經理眼中也許就是在大驚小怪)。在固化企業的WEB應用程序時,你需要綜合利用過程、工具、優化及最佳方法。一般說來，這些策略就是關于網絡、與應用程序和過程相關的性質等。

WEB應用的最佳方法應從網絡層開始，從WEB應用程序的開發到投入使用的整個過程中，都要將安全性作為頭等大事。

網絡：將服務器隱藏在DMZ(隔離區)

如果你是安全專家，可能會覺得此方法有點兒小兒科。但是，并非人人都是安全專家，而且即使最好的安全專家有時也會犯困。將WEB服務器放在DMZ 不會從技術上使WEB應用或網站更安全，但是一旦WEB服務器被成功攻擊或破壞，該方法可以保護基礎架構的其余部分免受攻擊。

如果企業網站或WEB應用程序在自己的服務器上，那么，外圍防御每天都會遭受各種掃描。你無法阻止攻擊者探測外圍的開放服務，但你可以在攻擊者成功損害了一臺WEB服務器后，使他難以造成更大的危害。將面向外部的WEB服務器放在DMZ中的要旨在于，將攻擊者限制在一個較小的范圍內，在一臺服務器被攻克后，這樣做可以限制其危害。例如，如果你將所有進入的連接都進行地址轉換，使其到達內部網絡，那么黑客就可以成功地利用未打補丁的漏洞或使用SQL注入實現特權提升，從而可以無限制地訪問內部網絡。

網絡：重新審查防火墻規則

減少WEB應用程序攻擊面的最簡捷的方法之一就是保證丟棄所有進入WEB服務器群端口的連接。如果你暴露了一個WEB應用，就沒有理由在WEB服務器上允許RDP，也沒有理由允許ICMP。暴露WEB服務器上的其它TCP/UDP服務可能需要測試或診斷，但除卻TCP的80端口或443端口，沒有理由允許任何進入的連接到達WEB服務器。安全管理專家應經常檢查防火墻的規則的異常情況，特別是如果企業有幾個人在管理防火墻，經常審查就尤其重要了。

工具：保護前端

如果你要保護內部的WEB應用程序，一般并不需要WEB應用程序防火墻。但是大型企業往往擁有面向外部世界的WEB應用程序，如果這些程序出現問題，企業將喪失大量金錢，因而企業非常需要WEB應用防火墻。

無疑，一個遵循謹慎原則而開發的應用程序不可能需要WEB應用防火墻級的保護。但是，有時WEB的開發者們不驗證用戶提供的輸入，此時最大敵人恰好是開發者自己。而且，從編碼的觀點看，WEB開發者也無法保護WEB應用程序免受曠日持久的DoS攻擊;雖然我們應當責備開發者因粗心大意而使網站遭受SQL注入攻擊，但如果系統管理員沒有正確地強化WEB服務器，也沒有及時打補丁，是不是也應承擔責任呢?在出現問題時，再去探究漏洞是否是人為錯誤造成的就沒有太大意義了。關鍵的問題是，WEB應用防火墻對于保護WEB應用程序免于遭受各種攻擊和漏洞利用可謂意義重大，最根本的問題是防止漏洞被利用。企業需要判定不部署WEB應用防火墻的風險是否超過其益處。

應用程序：強化WEB服務器

脆弱的WEB應用程序會將企業暴露在不必要的風險中。將WEB服務器部署在Linux而非Windows上未必會更安全。配置錯誤的Apache部署與配置錯誤的IIS一樣脆弱。同樣的理論也適用于底層的操作系統。

事實上，如果你僅僅固化WEB服務器自身卻沒有強化底層的操作系統，那么你就不可能覆蓋攻擊WEB應用程序的所有漏洞。正如企業應當過濾防火墻上所有不必要的協議一樣，移除那些對于WEB應用程序非必需的系統服務也非常重要。

例如，Windows Server 2008的默認部署包含50個正在運行的服務，而Windows Server Core的默認部署僅包含36個服務。雖然IIS會增加少量服務，但是借助用于部署WEB服務器的方法來進行簡單優化，就可以極大地減少WEB應用程序的攻擊面。當然，在Linux中，禁用一些不必要的正在運行的進程從而強化底層操作系統，也可以達到同樣的優化目的?；〞r間從服務器中清除不必要的服務是改善WEB應用程序安全狀況的最簡捷步驟。

工具：經常使用漏洞掃描器

不管企業的變更控制過程如何嚴格，業務的自然過程(無論是否受到控制)都會產生新漏洞。這些漏洞有可能是防火墻變化的結果，也可能是更新WEB應用程序或底層操作系統、新發現的零日漏洞、錯誤配置的結果。

新發現漏洞的原因并不重要，因為最重要的問題是能夠發現并解決安全問題。不幸的是，你不能依靠某個安全專家甚至不能依靠某個安全團隊，去發現WEB應用程序環境中的漏洞。在一個WEB應用程序投入使用時，發現新漏洞的責任最好交給可以主動發現安全問題并在問題發時生發出警告的自動化工具。

沒有什么可以替代一個健全的漏洞掃描器，我們也沒有理由不去使用這種工具，因為這種掃描器便宜且易于部署。

應用程序：清楚應用程序的默認配置和安全環境

從網絡和操作系統的觀點看，許多問題都會把WEB服務器置于風險中。但管理員做的最糟糕的事情之一就是部署了IIS等產品后，就覺得“完活”了。保障IIS的安全本身就身就是一項艱巨的任務，不過，為使WEB 應用程序成為一個難以攻克的目標，你不必成為一個IIS權威。你只需要理解哪個WEB應用程序服務器的默認配置會增加風險，以及如何快速解決這些問題就可以了。

攻擊者非常熟悉IIS，所以他們知道默認的IIS站點是放在c:\inetpub\wwwroot目錄下。在IIS中，WEB應用程序運行在用以隔離應用程序從而實現更好安全的應用程序池中。不過，狡猾的攻擊者知道默認的應用程序運行在網絡服務(Network Service)賬戶下。網絡服務(Network Service)賬戶擁有的權利超過了用戶給予應用程序池的權利。所以，禁用默認配置并創建一個由新賬戶保障其安全的新應用程序池是最簡單有效的安全建議。攻擊者還知道，默認情況下，應用程序池運行在iUSR_Host_Name賬戶下。如果攻擊者可以發現WEB服務器的主機名，就可以知道答案并關閉iUSR賬戶，并通過發送假冒的認證請求而攻克WEB服務器。

為保障IIS服務器的安全，管理員應當做的事情有很多，但是保留WEB服務器的默認設置是一個很容易避免的安全問題。

過程：參加設計會議

技術不可能完全解決安全方面的每一個問題，因為我們還需要其它方面的工作。

有些開發者可能會認為，在開發應用程序時，安全并非頭等大事。這并不是說開發者不關心安全問題，但緊迫時間表和資源可能會阻止開發者重視安全問題。另外，有的開發者還可能缺乏安全編程所需要的知識。

例如，安全專家都知道當開發者在WEB應用程序中使用動態查詢卻沒有對用戶提供的輸入信息進行凈化時，就有可能面臨SQL注入風險。如果安全專家在在WEB應用程序的設計會議上詢問一下，就會發現幾乎所有的開發人員因為執行速度問題而偏愛動態查詢。但通過使用存儲過程或參數化查詢，開發者就可以防止攻擊者歪曲查詢結果。如果你無法提出建議，你就不可能影響關鍵的設計決策，無法對最終的產品的安全性產生重要影響。

在設計階段安全專家應當解決的另一個問題是，將要增加到WEB應用程序上去的數據驗證方法。不正確地驗證數據就會給SQL注入和跨站腳本攻擊敞開大門。WEB應用程序不應當允許用戶在一個字段中輸入指向惡意腳本的URL。同樣地，WEB應用程序也不應當允許用戶在一個本該輸入電話號碼的字段中輸入SQL命令。

多數開發者知道，在涉及到數據驗證問題時，首要的規則就是絕對不相信用戶提供的輸入。但是，數據驗證并不是安全專家在WEB應用程序的設計會議期間應當提出的唯一的問題，“數據消毒”問題也必須解決。例如，在多數情況下，用戶不應當能夠在一個字段中輸入由HTML標記封裝起來的數據。在一個期望捕獲基本的用戶信息的WEB表單中，在將一個字符串的值寫到數據庫中時，我們有什么合理的理由可以存儲HTML標記嗎?

這里你就需要做出判斷了：如果此時談論的WEB應用程序的某些字段要求使用HTML標記來構建更好看的清單，那么由于業務需要，你就需要在某些實例中處理HTML。但這類WEB應用程序也會強化安全策略，禁止使用可能有破壞性的HTML。所以，在設計階段，這類WEB應用程序可以提供一個很好的范例，它會啟發安全專家或具有安全意識的開發者對最終的WEB應用程序產品發揮重大影響。

處理：安全團隊和質量保證團隊應當緊密團結

在有些情況下，在一個新WEB應用程序的開發期間安排安全專家留在開發小組中也許不太可能或無法令人接受。但對于管理良好的開發項目來說，你一定要確保質量保證專員留在開發者的房間內。

在理想情況下，在涉及新WEB應用程序的測試過程中，安全和質量保證團隊應當緊密團結。其原因很簡單：質量保證團隊的專家通常幾乎沒有應用程序的安全概念背景。所以，在與一個不使用相關安全最佳方法的開發團隊進行合作時，最可能的產品有可能是一個漏洞百出的應用程序。

改變這種產品的最好而且是唯一的機會是，在發布新WEB應用程序的公共測試版本時，使安全團隊或至少一個安全專家與質量保證團隊在一起。如果你工作在一個中小型企業，開發團隊還有可能就是質量保證團隊，或企業將應用程序的開發外包出去。

無論怎樣，安全專家必須能夠闡述明白：具體的SQL注入攻擊、XSS攻擊或LFI/RFI攻擊如何實現。這將會給開發過程帶來巨大價值。

最終目標是部署一個穩定而安全的WEB應用程序。所以，從安全的觀點看，安全專家們的思考和行動能夠像質量保證團隊一樣是非常重要的。這可能意味著主動提供質量保證服務或關注發布版本日期，關注何時準備部署現有的產品更新(因為新版本需要進行測試)。雖然你作為一名安全專家出現在開發團隊有時不太受歡迎，但日后你可能因幫助開發了一個更穩健和安全的WEB應用程序而得到感謝。而且，在此過程中，如果你能夠教育WEB開發者黑客如何利用WEB應用程序的漏洞，就自然有助于確保未來的軟件會包含使WEB應用程序更強健更安全的特性。

總體而說，WEB應用程序的安全并不是一個那么難的目標。雖然許多安全項目的成功存在于安全專家的手中，實現強健的WEB應用程序的安全要求企業各方的協同努力。

WEB應用程序的安全更應當是一個過程驅動的而不是技術驅動的問題，而且必須一直如此。我們不能用一個防火墻和反病毒軟件來保障WEB應用程序的安全后就覺得萬事大吉了。正如歷經開發生命周期的其它任何軟件一樣，我們應當用一種可預測的和結構化的方法來實現保障WEB應用程序的過程。有時，保障WEB應用程序安全需要耗費很多時間和努力，但在與不付出這些時間和努力所造成的巨額代價相比，這是完全值得的。