【51CTO.com 獨家特稿】隨著信息技術的告訴發展，企業中的信息系統越來越復雜，就目前的趨勢而言，Web應用程序在企業中占據主要地位，因此企業越來越依賴于Web應用程序，目前在安全方面考慮最多的可能是在服務器前部署防火墻，開啟SSL協議和主機加固，但遺憾的是攻擊的主要目標現在已經逐漸轉移到Web應用程序本身了，這些保護措施已經變得越來越沒有用了。

是什么使Web應用程序變得脆弱的呢？

按照OSI參考模型來看，信息的傳輸要通過多層網絡協議，處于頂層的應用層包括HTTP、FTP等協議，本文的重點放在HTTP協議上，傳統的防火墻不能有效地阻止這一層協議，因此許多攻擊者都喜歡在網絡層構造虛假的HTTP請求，在其中夾雜攻擊代碼。

HTTP攜帶式攻擊允許無限制地對數據庫訪問，并可以執行任意系統命令，甚至修改網站內容。由于缺乏和不重視對Web應用程序的安全管理和測試，很容易將系統漏洞暴露給攻擊者。主要有下面三方面的原因：

（1）分析人員和設計人員在考慮安全問題時，只考慮了網絡安全，只有少數安全專家才會認證對待和思考應用層安全。

（2）開發團隊認為應用程序安全是一個模糊的概念，或者在交付使用時發表聲明，要求客戶做好保護工作，使得安全性測試實施變得非常困難。

（3）即使進行了安全測試，也是放在軟件生命周期的后期了，即由攻擊者發起的攻擊性測試。常見的Web應用程序攻擊類型針對Web應用程序的攻擊種類很多，切入點也有很多，通常，在一個Web系統中有下面這些攻擊切入點，也正是要保護的點，如圖1所示。

圖1

圖1     Web應用程序的安全問題

從上圖可以看出，攻擊者要發起攻擊，有很多的入口點，那我們該怎么辦呢？通常應該選擇符合自己需要的防范措施和技術手段，而不應該一味地追求最新的攻擊方式保護。下面列舉出一些常見的攻擊類型和防范措施，也許對你的Web應用程序有所幫助。

描述    常見原因    預防措施

（1）偽裝傳入一個不同用戶的身份憑據、修改cookie或修改參數偽裝成某個用戶，或將cookie偽裝成來自某個用戶

[a]使用基于通信的身份認證，允許訪問所有用戶的數據。

 [b]使用未加密的證書可能被捕獲和重用。

 [c]在cookie或參數中存儲證書

[d]使用未經驗證的認證方法或認證來自于不受信任的域。

[e]客戶端軟件不驗證主機。

使用以下手段為證書提供嚴格的驗證和保護：

[a]操作系統提供的框架

 [b]加密令牌，如會話cookie [c]數字簽名 #p#

（2）篡改未經認證就修改或刪除資源（如丑化網站界面，修改傳輸途中的數據）

 [a]未經驗證就信任數據源。

[b]清洗輸入數據，避免不想運行的代碼執行。

 [c]運行的權限越來越大。

 [d]敏感數據位加密。

 [a]使用操作系統鎖定文件、目錄和其它資源。

 [b]驗證你的數據。

[c]在數據傳輸過程中散列和簽名（如使用SSL或IPsec）。

（3）否認試圖破壞、隱藏或修改已經發生的事實（如刪除日志，模仿一個用戶請求修改）

[a]使用的是比較弱或缺乏授權的驗證程序。

 [b]不恰當的日志記錄。

 [c]允許敏感信息在無任何保護的信道中傳輸。

 [a]使用嚴格的認證、事務記錄是數字簽名。

 [b]審核

（4）信息泄露泄露個人身份信息，如密碼和信用卡數據，加上信息來源和主機信息

[a]允許授權用戶訪問其它用戶的數據。

 [b]允許敏感信息在不安全的信道上傳輸。

[c]選擇了弱的加密算法和密鑰。

 [a]在會話上存儲個人身份信息而不是永久性存儲。

 [b]無論何時，對敏感數據都使用散列和加密。

 [c]以用戶身份匹配用戶數據

（5）拒絕服務（DoS）

[a]洪水攻擊-同時向服務發送許多消息和請求。

 [b]封鎖-突然發送大量的請求，耗光資源使服務器響應變慢，迫使應用程序重啟

[a]在一臺服務器上放置了過多的應用程序或在一臺服務器上部署了相互沖突的應用程序。

 [c]忽略了全面的單元測試。

[a]使用防火墻過濾數據包。

 [b]使用負載均衡設備控制對單一資源的大量請求。

 [c]使用異步協議處理CPU密集型請求和錯誤恢復。

（6）特權提升超過正常訪問權限獲得管理員特權，訪問機密文件

[a]以root或Administrator用戶運行Web服務器進程。

 [b]使用了代碼出錯時允許緩沖區溢出，將應用提升到調試狀態。

 [a]無論何時盡可能使用最小的權限。

 [b]使用類型安全語言和編譯器選項，預防或控制緩沖區溢出。

為Web應用程序提供安全保障的基本原則

使用安全的方法創建的應用程序可以避免受到表1中列出的那些攻擊，當然對于現有的Web應用程序也可以采取一些補救措施來加強安全保護，包括：

（1）發現并建立基線

管理一個完整的應用程序和系統產品目錄，包括技術信息，如ip地址，DNS，操作系統類型等，再加上一些商務信息，如誰批準開發的，如果系統故障應該通知誰，或誰負責處理。接下來完整掃描一次你的Web架構，找出其中的漏洞，檢查清單和bug跟蹤網站上有你操作系統、第三方應用程序和Web服務器的全部已知威脅，在上系統前，確保服務器已經打上所有的補丁，最后，測試應用程序認證和用戶權限管理功能，并終止未知的服務。

（2）評估和轉移風險

評估應用程序和系統的風險，主要集中評估數據存儲、訪問控制、用戶配置和權限管理。優先考慮評估期間發現的應用程序漏洞，評審組織、行業和政府政策的遵從性，確定哪些操作可接受，哪些操作不能接受。

（3）保護應用程序避免危害擴散

掌控已知的安全威脅，并及時打上各類補丁，如果漏洞補丁還未發布，最好使用應用層防火墻限制訪問，禁用應用或重定向到其它程序。

（4）持續的監測和評審

使用文檔不間斷地進行記錄，持續監測，發現問題及時評審，最快做出響應。系統生命周期內的安全測試在Web應用程序開發早期使用RUP框架準則，這樣做在發現和修復漏洞方面具有良好的成本效益，越是到生命周期后面，發現錯誤和漏洞時的補救成本越高。

一些開發團隊在前期收集需求的階段不重視安全需求，忽略了這方面的需求分析，這樣設計開發出來的系統當然不能很好地抵御威脅，在編碼階段，程序員也沒有獲得具體的安全需求，可能在代碼中混雜了很多具有缺陷的代碼，在移交給用戶方時，常常缺少專業的安全人員進行評估，用戶一味地信任系統開發方，當然作為系統開發方而言，肯定也不愿意找安全專家在此時來評估系統漏洞，因為此時發現的錯誤和漏洞要修復成本非常高昂。

下面一一個表列出系統生命周期內不同階段修復漏洞的成本。#p#

錯誤類型 設計 編碼 集成 Beta 部署

設計    1x   5x      10x     15x     30x

編碼          1x      10x      20x     30x

集成                    1x       10x      20x

發現錯誤時間越晚，修復的相對成本越高

選擇正確的測試方法

為了避免出現在部署時才發現問題，系統研發團隊應該建立一套良好的安全測試方法，在開發過程中和質量管理一起形成一個有機的保障屏障。下面列出已知安全測試的方法及對應的優缺點，以供大家參考：

描述    優點    缺點

（1）手動測試由安全專家利用工具和腳本進行滲透和安全驗收測試 對具體的應用功能發起有針對性的測試

 [a]受限于測試專家

 [b]可能導致更高的錯誤率和循環成本

 [c]由于時間限制，限制了應用的覆蓋率

（2）自動化測試包括兩種方法：

 [a]自底向上 - 測試具體的個別功能，有開發人員自己實現

 [b]自頂向下 - QA團隊從最終用戶的角度建立測試 質量高，減少測試和迭代開發過程 比手動測試需要更大的開銷

（3）黑盒或系統測試只查看系統的輸入輸出，修改正常的用戶輸入查看應用程序的行為 使用成熟度非常高的自動化測試工具，學習難度較低

 [a]可能只有當所有應用程序組件都就緒后才能開始測試（通常是在產品開發后期或在生產環境中使用）

[b]可能產生無法忽略，無法回退的事務

（4）白盒測試為特定功能錯誤評估個別組件，通常結合代碼掃描工具和同級評審 可以使用與開發IDE環境集成的工具

 [a]不能暴露需求和設計缺陷

 [b]可能不會暴露包含在多個組件內的漏洞，或在單元測試時段可能不會暴露

 [c]需要編碼人員承擔安全測試表3 Web應用程序安全測試方法說了半天，那究竟該如何保護Web應用程序呢？下面就談談保護Web應用程序的四個最佳實踐。

保護Web應用程序的四個最佳實踐

（1）增強安全意識這包括通過培訓、交流增強團隊成員的安全意識，當然有一個安全專家作顧問就更好了。最少每年也得在團隊成員之間開展一次安全培訓，包括開發人員、質量保證人員、分析人員和部門經理。

描述當前的攻擊方式和推薦的補救措施，討論組織的當前安全實踐，開發人員必須參加培訓，要掌握框架內置的安全功能。另外值得一試的是持續收集和整理其它團隊分享的經驗，團隊之間經常保持交流，團隊內部更是應該經常開展安全編程討論。

（2）分類應用程序風險和責任每個組織的資源都是有限的，必須為其設置優先級，通過以下手段可以幫助你設置安全優先級：

 [a]定義風險閥值，指定什么時候安全團隊應該終止應用程序服務。

 [b]按風險因素對應用程序進行分類，如互聯網、局域網和外部網。

 [c]定期進行安全掃描，生成安全報告。

[d]創建一個數據庫，按風險分析和排列應用程序。

（3）建立零誤差執行政策在開發和部署階段建立零誤差執行政策，可以降低部署含有缺陷的系統的風險，在開始階段就要確定好在系統真正部署前必須經過什么測試才能上線，并把這個決定通知給所有團隊成員，在開始編碼前必須評審需求說明書和設計說明書，真的不能少了這些必要的步驟，這點時間是節約不得的。

（4）從開發到交付的整個周期要不停地測試通過不停的測試、評審對設計、開發都有正面影響，在整個軟件生命周期內都應該有測試活動，并且確定你的測試框架包括以下內容：

 [a]使用自動化測試工具，使得測試工作可以隨時開始。

 [b]包括單元測試和系統測試。

[c]允許在生成系統中進行審核測試。

 [d]包括事件驅動測試。

[e]使用一個敏捷的開發方法。

 [f]可以在編碼、測試、集成和生成時運行測試。

因為越到后面缺陷修復的成本越高，故做好前幾個階段的工作，能夠提前預知可能發生的潛在風險那是最好不過了，因此本文限于篇幅，也只限于整理開始階段和建模編碼階段的建議。

（1）開始階段 - 定義好安全需求應用相關 要考慮的限制和需求應用環境

（1）確定并認可組織安全策略

（2）認識基礎設施的限制，如防火墻、協議和服務

（3）確定托管環境的限制，如VPN

（4）確定應用程序部署配置

（5）確定網絡域結構、集群和遠程應用服務器

（6）確定數據庫服務器

（7）確定環境支持哪些安全通信功能

（8）確定可擴展性和性能指標輸入數據校驗

安全性考慮    詳細說明   建議編碼實踐

（1）未測試時不要減少或修改默認安全設置

（2）代碼不要含糊

（3）不要暴露不需要的信息

（4）盡早發現并修復安全錯誤

（5）不顯示堆棧跟蹤或有關敏感信息輸入數據校驗

小結

縱觀這幾年信息技術的發展勢頭，越來越多的政府機關和企事業單位都積極投身于自身的信息化建設，幾乎每個企業都運行有與自身相關的業務系統和網站。

而且今后的發展趨勢會是Web化，集成化，越來越多的數據在網絡上傳輸，而且正在逐步向互聯網方向進化，攻擊事件逐年遞增，攻擊手段越來越先進，越來越傻瓜化，安全如果不從源頭抓起，那就只是一句空話，過分信任安全設備和軟件廠家潛在的風險實在太大，只有多方積極配合，相互協調才能真正應對Web應用程序未來的挑戰。

【51CTO.COM 獨家特稿，轉載請注明出處及作者】