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

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

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

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

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

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

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

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

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

我們要考慮如下要點：

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

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

端口和服務(wù)要求：應(yīng)用程序有可能還要與其它應(yīng)用通信。要確認(rèn)需要為該應(yīng)用程序打開哪些端口和服務(wù)。

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

禁用明文協(xié)議：運行明文服務(wù)的端口應(yīng)當(dāng)關(guān)閉，并且不應(yīng)該用于應(yīng)用程序的任何部分。

3.輸入驗證

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

我們必須考慮如下要點：

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

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

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

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

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

4.認(rèn)證

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

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

服務(wù)器端的認(rèn)證控制：要確保在服務(wù)器端驗證憑據(jù)而不是在客戶端?？蛻舳说恼J(rèn)證很容易被繞過去。

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

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

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

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

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

框架的默認(rèn)口令：許多應(yīng)用程序框架都有一個默認(rèn)的口令。要確保將口令改成一種不易猜測的強口令。

5.授權(quán)

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

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

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

6.配置管理

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

如下要點必須引起重視：

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

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

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

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

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

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

7.會話管理

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

關(guān)于會話管理，如下要點應(yīng)引起重視：

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

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

8.加密

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

關(guān)于加密，我們應(yīng)考慮如下要點：

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

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

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

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

9.參數(shù)操縱

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

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

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

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

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

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

10.例外管理

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

11.審計和日志

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

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

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

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

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

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

12.應(yīng)用程序框架和庫

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

結(jié)語

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