最近做這方面東西，感覺這篇文章應該是最接地氣的和最全面的一篇關於架構設計的文章，除了這12個問題，還要加一個監控系統（Crash監控，內存泄漏監控，下載監控，dns劫持監控等等）。
下面分別看一下這些方面：
1.應用程序架構的文檔
我們應關注的第一個問題就是應用程序架構文檔的實用性。每一個應用程序都應當有合適的可備查的架構圖，其中要有對上述要點的深入解釋，以及能夠顯示不同組件如何安裝和保障安全的網絡連接圖。
2.對部署和基礎架構的考慮
要檢查應用程序賴以部署的基礎架構，其中可能包括檢查網絡、系統、基礎架構的性能監視等。
我們要考慮如下要點：
應用所要求的組件：支持此應用程序的操作系統是什么?硬件需求是什么?
防火牆實施的限制：要檢查防火牆為應用程序定義的策略，要檢查防火牆允許哪類通信，阻止哪類通信。
端口和服務要求：應用程序有可能還要與其它應用通信。要確認需要為該應用程序打開哪些端口和服務。
組件隔離：應用程序的不同組件應當相互隔離。例如，應用程序服務器和數據庫服務器絕不應位於同一台機器中。
禁用明文協議：運行明文服務的端口應當關閉，並且不應該用於應用程序的任何部分。
3.輸入驗證
不健全的輸入驗證是導致應用程序安全問題的主要原因之一。適當的輸入驗證有助於防止跨站腳本攻擊、SQL注入攻擊等許多攻擊。應對所有頁面的每一個輸入字段(包括隱藏的表單字段)實施驗證。最佳實踐是利用一種集中化的方法。
我們必須考慮如下要點：
驗證用戶輸入的機制：要檢查該應用是否能夠驗證用戶輸入或者能夠處理所要求的輸入。
繞過驗證：我們要檢查用戶輸入是如何被驗證的。是否有可能繞過驗證?要確認輸入驗證是否依賴應用程序的框架。要檢查框架中是否有用戶可以繞過驗證的任何漏洞。
集中化的方法：如果企業使用定制方法來驗證用戶輸入，就要檢查是否采用集中化的方法。
在所有層中進行驗證：作為一種最佳實踐，我們應當在所有層上實施驗證，也就是在業務層、數據層等層面上實施驗證。
解決SQL注入問題：輸入驗證有助於在一定程度上減少SQL注入問題。我們應在后端利用參數化查詢來檢查應用程序是否可以應對SQL注入漏洞。
4.認證
認證是確認用戶身份的活動。在應用程序中，驗證是通過提供用戶名和口令來實施的。不健全的認證機制可能導致繞過登錄過程進而訪問應用程序。這可能會帶來重大損害。在設計應用程序時，應當實施強健的認證。
為有效地實施認證，我們必須考慮如下要點：
服務器端的認證控制：要確保在服務器端驗證憑據而不是在客戶端。客戶端的認證很容易被繞過去。
認證的安全通道：程序在設計時，要確保通過加密通道來發送登錄憑據。通過明文通道傳送的憑據很容易被攻擊者嗅探。
檢查登錄頁是否可以通過HTTP協議傳送。要檢查在沒有實施SSL證書的情況下，應用程序是否可以通過任何其它的端口訪問。
強健的口令策略：企業的應用程序應當配置為只接受強口令。弱口令很容易遭受蠻力攻擊。
認證cookie：要檢查SSL是否在整個應用程序中實施，並且要檢查任何頁面的認證cookie是否通過明文傳送。
服務賬戶：服務賬戶是一種服務應用程序賴以運行的賬戶。應用程序所要求的服務賬戶在與數據庫通信時，應當有一套受限制的特權集。
框架的默認口令：許多應用程序框架都有一個默認的口令。要確保將口令改成一種不易猜測的強口令。
5.授權
授權決定了哪些資源可以被經認證的用戶訪問。不健全的授權控制可能導致特權提升攻擊。企業應當考慮的要點如下：
特權提升和欺詐：在用戶訪問超過了其被允許訪問的更多資源時，或者在用戶能夠執行超過其被允許的更多活動時，就發生了特權提升。要檢查一下，如果用戶要通過操縱請求或者通過直接訪問未經授權的頁面或資源，從而試圖提升其特權，企業是否可以提供控制機制。
直接對象引用：要檢查應用程序是否會根據用戶提供的輸入而提供了對於對象的直接訪問。如果可以的話，攻擊者就可以通過繞過授權而訪問屬於其它用戶的資源。例如，下載其他用戶的發票。
6.配置管理
企業應避免不健全的配置。在配置文件中存儲的任何敏感信息都有可能被攻擊者獲得。
如下要點必須引起重視：
安全強化：要確保應用程序所要求的所有組件都是最新的，而且要安裝最新的補丁。如果可能的話，要改變默認配置。
敏感數據：數據庫連接字符串、加密密鑰、管理員憑據或任何其它機密都不應當以明文形式存儲。要檢查配置文件是否可以防御非授權的訪問。
長期cookie：我們應避免將敏感數據以明文形式長期存放在cookie中。用戶可以看到和修改明文數據。要檢查應用程序是否將明文數據長期存放在cookie中。
使用GET協議傳遞敏感數據：GET協議在查詢串中發送數據。通過GET發送的敏感信息都可以通過瀏覽器歷史或記錄進行訪問。
禁用不安全的方法：我們要驗證應用程序只能接受GET和POST方法。TRACE、PUT、DELETE等其它方法都應當被禁用。
通過HTTP協議傳輸數據：在組件之間的通信，如在應用程序服務器和數據庫服務器之間的通信都應當實施加密。
7.會話管理
會話是對用戶活動的跟蹤。強健的會話管理在應用程序的總體安全中扮演着一個重要角色。會話中的漏洞可能導致嚴重的攻擊。
關於會話管理，如下要點應引起重視：
使用架構的默認會話管理：定制的會話管理可能存在多種漏洞。要確保不使用定制的會話管理器，並且使用應用程序框架的默認會話管理。
確保會話管理遵循如下最佳方法：會話ID應是隨機的、長度足夠長且保證唯一性;會話在登出后就失效;成功認證的會話ID和再次認證的會話ID應不同;會話 ID不應出現在URL中;在一段非活動時間過后，會話應超時;會話ID必須在安全通道中傳送;要檢查cookie的屬性(HttpOnly、 Secure、path、domain等)的安全性;
8.加密
為保障存儲數據的安全，或為保護在不安全的通道中數據傳輸的安全性，應用程序往往使用加密技術。
關於加密，我們應考慮如下要點：
定制加密不靠譜：設計一種專用的加密機制有可能導致更脆弱的保護。企業應使用由平台提供的安全加密服務。企業應檢查應用程序中所使用的加密類型。
加密密鑰管理：要檢查是否存在加密密鑰的管理策略，也就是說，是否有關於密鑰的生成、分發、刪除、消亡的策略。
保障加密密鑰的安全：加密密鑰用於作為一種加密或解密數據的輸入。如果加密密鑰遭到泄露，加密的數據就會遭到解密。
密鑰的生命周期策略：在一段時間后，密鑰應當重新生成。長期使用同樣的密鑰是不安全的安全實踐。
9.參數操縱
借助參數操縱攻擊，攻擊者可以篡改從應用程序傳輸到Web服務器的數據。這會導致對服務的非授權訪問。
因此，我們需考慮如下要點：
驗證來自客戶端的所有輸入：在客戶端實施驗證可以減少服務器的負擔，但僅依賴客戶端的認證是一種不安全的實踐。攻擊者可以利用代理工具繞過客戶端的認證。因而，我們應檢查是否也在服務器上實施了認證。
不要依賴HTTP頭：應用程序中的安全決策不應當是基於HTTP頭的。如果應用程序僅通過檢查“referrer”頭來為網頁服務，攻擊者就可以通過改變代理服務器工具中的頭部來繞過此控制。
加密cookies：cookies包含着由服務器授權給用戶的數據。我們必須保護這類數據以防止非授權的操縱攻擊。
ViewState中的敏感數據：例如，ASP.NET應用程序中的viewstate可能包含一些敏感數據，后者是用於在服務器上進行授權的根據。如果不啟用消息認證碼的話，viewstate中的數據就容易被篡改。因而，我們應檢查是否使用了消息認證碼來保護viewstate中的數據。
10.例外管理
不安全的例外處理機制可能暴露有價值的信息，攻擊者可以利用這個缺陷來調整其攻擊。如果沒有例外管理，堆棧跟蹤、框架細節、服務器細節、SQL查詢、內部路徑等敏感信息都有可能遭到泄露。我們必須檢查是否部署了集中化的例外管理，要確保例外管理機制顯示盡可能少的信息。
11.審計和日志
日志文件包含着事件的記錄。這些事件可能是一次成功的或失敗的登錄嘗試，或是數據的恢復、修改、刪除等，或是網絡通信等的任何企圖。我們必須能夠實時地監視日志。
因而，在構建應用程序的架構時必須重視如下要點：
支持和啟用日志：必須檢查是否支持應用程序和平台的日志功能。
記錄事件：我們必須檢查是否所有安全等級的重要事件都能夠生成日志，如成功和失敗的認證、數據訪問、修改、網絡訪問等。日志應當包含事件的時間、用戶身份、機器名和位置等。要確認記錄哪些事件。
記錄敏感數據：應用程序不應當包含日志的敏感數據，如用戶憑據、口令哈希、信用卡細節等。
存儲、安全、分析：日志文件應當存放在一個不同於應用程序正在運行的地方。日志文件應當復制並移動到一個永久性的存儲器進行保留;必須保護日志文件，防止未經授權的訪問、修改、刪除等;必須定期地對日志文件進行分析。
12.應用程序框架和庫
要確保應用程序框架和庫的最新，並保證對其部署了相關的補丁。要確認在框架中沒有使用默認的口令。還要檢查是否使用了老的或易受攻擊的框架。
結語
上述要點基本代表了設計安全的應用程序應關注的問題。在設計階段實施這些要點可以減少為保障應用程序安全而花費的總成本。如果企業已經部署了應用程序，那么，應用程序架構的安全檢查就成為全面安全評估的一個重要部分，並有助於修復已有的漏洞和改善未來的應用程序設計。
來自 <http://www.xue163.com/5/4/59555_3.html>