應用程序的架構(gòu)檢查是指檢查應用程序架構(gòu)中當前的安全控制。這種檢查有助于用戶在早期確認潛在的安全漏洞，并在開始開發(fā)之前就極大地減少漏洞。糟糕的架構(gòu)設計有可能暴露出應用程序的許多安全漏洞。最好的辦法是在設計階段就執(zhí)行架構(gòu)檢查，因為在部署后再實施安全控制將花費高昂的成本和代價。

本文可作為架構(gòu)師的安全設計指南，也可以為滲透測試人員執(zhí)行應用程序架構(gòu)檢查提供參考，二者都可以將文中提及的方法和措施作為全局安全評估的一部分。

下圖展示的是在設計階段必須解決的一些主要問題。

在進行架構(gòu)檢查時，我們重點關注以下方面：應用程序架構(gòu)的文檔、部署和基礎架構(gòu)問題、輸入驗證、認證、授權、配置管理、會話管理、加密、參數(shù)操縱、例如管理、審計和記錄、應用程序框架和庫。

下面分別看一下這些方面：

1.應用程序架構(gòu)的文檔

我們應關注的第一個問題就是應用程序架構(gòu)文檔的實用性。每一個應用程序都應當有合適的可備查的架構(gòu)圖，其中要有對上述要點的深入解釋，以及能夠顯示不同組件如何安裝和保障安全的網(wǎng)絡連接圖。

2.對部署和基礎架構(gòu)的考慮

要檢查應用程序賴以部署的基礎架構(gòu)，其中可能包括檢查網(wǎng)絡、系統(tǒng)、基礎架構(gòu)的性能監(jiān)視等。

我們要考慮如下要點：

應用所要求的組件：支持此應用程序的操作系統(tǒng)是什么?硬件需求是什么?

防火墻實施的限制：要檢查防火墻為應用程序定義的策略，要檢查防火墻允許哪類通信，阻止哪類通信。

端口和服務要求：應用程序有可能還要與其它應用通信。要確認需要為該應用程序打開哪些端口和服務。

組件隔離：應用程序的不同組件應當相互隔離。例如，應用程序服務器和數(shù)據(jù)庫服務器絕不應位于同一臺機器中。

禁用明文協(xié)議：運行明文服務的端口應當關閉，并且不應該用于應用程序的任何部分。

3.輸入驗證

不健全的輸入驗證是導致應用程序安全問題的主要原因之一。適當?shù)妮斎腧炞C有助于防止跨站腳本攻擊、SQL注入攻擊等許多攻擊。應對所有頁面的每一個輸入字段(包括隱藏的表單字段)實施驗證。最佳實踐是利用一種集中化的方法。

我們必須考慮如下要點：

驗證用戶輸入的機制：要檢查該應用是否能夠驗證用戶輸入或者能夠處理所要求的輸入。

繞過驗證：我們要檢查用戶輸入是如何被驗證的。是否有可能繞過驗證?要確認輸入驗證是否依賴應用程序的框架。要檢查框架中是否有用戶可以繞過驗證的任何漏洞。

集中化的方法：如果企業(yè)使用定制方法來驗證用戶輸入，就要檢查是否采用集中化的方法。

在所有層中進行驗證：作為一種最佳實踐，我們應當在所有層上實施驗證，也就是在業(yè)務層、數(shù)據(jù)層等層面上實施驗證。

解決SQL注入問題：輸入驗證有助于在一定程度上減少SQL注入問題。我們應在后端利用參數(shù)化查詢來檢查應用程序是否可以應對SQL注入漏洞。

4.認證

認證是確認用戶身份的活動。在應用程序中，驗證是通過提供用戶名和口令來實施的。不健全的認證機制可能導致繞過登錄過程進而訪問應用程序。這可能會帶來重大損害。在設計應用程序時，應當實施強健的認證。

為有效地實施認證，我們必須考慮如下要點：

服務器端的認證控制：要確保在服務器端驗證憑據(jù)而不是在客戶端。客戶端的認證很容易被繞過去。

認證的安全通道：程序在設計時，要確保通過加密通道來發(fā)送登錄憑據(jù)。通過明文通道傳送的憑據(jù)很容易被攻擊者嗅探。

檢查登錄頁是否可以通過HTTP協(xié)議傳送。要檢查在沒有實施SSL證書的情況下，應用程序是否可以通過任何其它的端口訪問。

強健的口令策略：企業(yè)的應用程序應當配置為只接受強口令。弱口令很容易遭受蠻力攻擊。

認證cookie：要檢查SSL是否在整個應用程序中實施，并且要檢查任何頁面的認證cookie是否通過明文傳送。

服務賬戶：服務賬戶是一種服務應用程序賴以運行的賬戶。應用程序所要求的服務賬戶在與數(shù)據(jù)庫通信時，應當有一套受限制的特權集。

框架的默認口令：許多應用程序框架都有一個默認的口令。要確保將口令改成一種不易猜測的強口令。

5.授權

授權決定了哪些資源可以被經(jīng)認證的用戶訪問。不健全的授權控制可能導致特權提升攻擊。企業(yè)應當考慮的要點如下：

特權提升和欺詐：在用戶訪問超過了其被允許訪問的更多資源時，或者在用戶能夠執(zhí)行超過其被允許的更多活動時，就發(fā)生了特權提升。要檢查一下，如果用戶要通過操縱請求或者通過直接訪問未經(jīng)授權的頁面或資源，從而試圖提升其特權，企業(yè)是否可以提供控制機制。

直接對象引用：要檢查應用程序是否會根據(jù)用戶提供的輸入而提供了對于對象的直接訪問。如果可以的話，攻擊者就可以通過繞過授權而訪問屬于其它用戶的資源。例如，下載其他用戶的發(fā)票。

6.配置管理

企業(yè)應避免不健全的配置。在配置文件中存儲的任何敏感信息都有可能被攻擊者獲得。

如下要點必須引起重視：

安全強化：要確保應用程序所要求的所有組件都是最新的，而且要安裝最新的補丁。如果可能的話，要改變默認配置。

敏感數(shù)據(jù)：數(shù)據(jù)庫連接字符串、加密密鑰、管理員憑據(jù)或任何其它機密都不應當以明文形式存儲。要檢查配置文件是否可以防御非授權的訪問。

長期cookie：我們應避免將敏感數(shù)據(jù)以明文形式長期存放在cookie中。用戶可以看到和修改明文數(shù)據(jù)。要檢查應用程序是否將明文數(shù)據(jù)長期存放在cookie中。

使用GET協(xié)議傳遞敏感數(shù)據(jù)：GET協(xié)議在查詢串中發(fā)送數(shù)據(jù)。通過GET發(fā)送的敏感信息都可以通過瀏覽器歷史或記錄進行訪問。

禁用不安全的方法：我們要驗證應用程序只能接受GET和POST方法。TRACE、PUT、DELETE等其它方法都應當被禁用。

通過HTTP協(xié)議傳輸數(shù)據(jù)：在組件之間的通信，如在應用程序服務器和數(shù)據(jù)庫服務器之間的通信都應當實施加密。

7.會話管理

會話是對用戶活動的跟蹤。強健的會話管理在應用程序的總體安全中扮演著一個重要角色。會話中的漏洞可能導致嚴重的攻擊。

關于會話管理，如下要點應引起重視：

使用架構(gòu)的默認會話管理：定制的會話管理可能存在多種漏洞。要確保不使用定制的會話管理器，并且使用應用程序框架的默認會話管理。

確保會話管理遵循如下最佳方法：會話ID應是隨機的、長度足夠長且保證唯一性;會話在登出后就失效;成功認證的會話ID和再次認證的會話ID應不同;會話 ID不應出現(xiàn)在URL中;在一段非活動時間過后，會話應超時;會話ID必須在安全通道中傳送;要檢查cookie的屬性(HttpOnly、 Secure、path、domain等)的安全性;

8.加密

為保障存儲數(shù)據(jù)的安全，或為保護在不安全的通道中數(shù)據(jù)傳輸?shù)陌踩?，應用程序往往使用加密技術。

關于加密，我們應考慮如下要點：

定制加密不靠譜：設計一種專用的加密機制有可能導致更脆弱的保護。企業(yè)應使用由平臺提供的安全加密服務。企業(yè)應檢查應用程序中所使用的加密類型。

加密密鑰管理：要檢查是否存在加密密鑰的管理策略，也就是說，是否有關于密鑰的生成、分發(fā)、刪除、消亡的策略。

保障加密密鑰的安全：加密密鑰用于作為一種加密或解密數(shù)據(jù)的輸入。如果加密密鑰遭到泄露，加密的數(shù)據(jù)就會遭到解密。

密鑰的生命周期策略：在一段時間后，密鑰應當重新生成。長期使用同樣的密鑰是不安全的安全實踐。

9.參數(shù)操縱

借助參數(shù)操縱攻擊，攻擊者可以篡改從應用程序傳輸?shù)絎eb服務器的數(shù)據(jù)。這會導致對服務的非授權訪問。

因此，我們需考慮如下要點：

驗證來自客戶端的所有輸入：在客戶端實施驗證可以減少服務器的負擔，但僅依賴客戶端的認證是一種不安全的實踐。攻擊者可以利用代理工具繞過客戶端的認證。因而，我們應檢查是否也在服務器上實施了認證。

不要依賴HTTP頭：應用程序中的安全決策不應當是基于HTTP頭的。如果應用程序僅通過檢查“referrer”頭來為網(wǎng)頁服務，攻擊者就可以通過改變代理服務器工具中的頭部來繞過此控制。

加密cookies：cookies包含著由服務器授權給用戶的數(shù)據(jù)。我們必須保護這類數(shù)據(jù)以防止非授權的操縱攻擊。

ViewState中的敏感數(shù)據(jù)：例如，ASP.NET應用程序中的viewstate可能包含一些敏感數(shù)據(jù)，后者是用于在服務器上進行授權的根據(jù)。如果不啟用消息認證碼的話，viewstate中的數(shù)據(jù)就容易被篡改。因而，我們應檢查是否使用了消息認證碼來保護viewstate中的數(shù)據(jù)。

10.例外管理

不安全的例外處理機制可能暴露有價值的信息，攻擊者可以利用這個缺陷來調(diào)整其攻擊。如果沒有例外管理，堆棧跟蹤、框架細節(jié)、服務器細節(jié)、SQL查詢、內(nèi)部路徑等敏感信息都有可能遭到泄露。我們必須檢查是否部署了集中化的例外管理，要確保例外管理機制顯示盡可能少的信息。

11.審計和日志

日志文件包含著事件的記錄。這些事件可能是一次成功的或失敗的登錄嘗試，或是數(shù)據(jù)的恢復、修改、刪除等，或是網(wǎng)絡通信等的任何企圖。我們必須能夠?qū)崟r地監(jiān)視日志。

因而，在構(gòu)建應用程序的架構(gòu)時必須重視如下要點：

支持和啟用日志：必須檢查是否支持應用程序和平臺的日志功能。

記錄事件：我們必須檢查是否所有安全等級的重要事件都能夠生成日志，如成功和失敗的認證、數(shù)據(jù)訪問、修改、網(wǎng)絡訪問等。日志應當包含事件的時間、用戶身份、機器名和位置等。要確認記錄哪些事件。

記錄敏感數(shù)據(jù)：應用程序不應當包含日志的敏感數(shù)據(jù)，如用戶憑據(jù)、口令哈希、信用卡細節(jié)等。

存儲、安全、分析：日志文件應當存放在一個不同于應用程序正在運行的地方。日志文件應當復制并移動到一個永久性的存儲器進行保留;必須保護日志文件，防止未經(jīng)授權的訪問、修改、刪除等;必須定期地對日志文件進行分析。

12.應用程序框架和庫

要確保應用程序框架和庫的最新，并保證對其部署了相關的補丁。要確認在框架中沒有使用默認的口令。還要檢查是否使用了老的或易受攻擊的框架。

結(jié)語

上述要點基本代表了設計安全的應用程序應關注的問題。在設計階段實施這些要點可以減少為保障應用程序安全而花費的總成本。如果企業(yè)已經(jīng)部署了應用程序，那么，應用程序架構(gòu)的安全檢查就成為全面安全評估的一個重要部分，并有助于修復已有的漏洞和改善未來的應用程序設計。