應用程式的架構檢查是指檢查應用程式架構中目前的安全控制。這種檢查有助于使用者在早期确認潛在的安全漏洞,并在開始開發之前就極大地減少漏洞。糟糕的架構設計有可能暴露出應用程式的許多安全漏洞。最好的辦法是在設計階段就執行架構檢查,因為在部署後再實施安全控制将花費高昂的成本和代價。
本文可作為架構師的安全設計指南,也可以為滲透測試人員執行應用程式架構檢查提供參考,二者都可以将文中提及的方法和措施作為全局安全評估的一部分。
下圖展示的是在設計階段必須解決的一些主要問題。
在進行架構檢查時,我們重點關注以下方面:應用程式架構的文檔、部署和基礎架構問題、輸入驗證、認證、授權、配置管理、會話管理、加密、參數操縱、例如管理、審計和記錄、應用程式架構和庫。
下面分别看一下這些方面:
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.應用程式架構和庫
要確定應用程式架構和庫的最新,并保證對其部署了相關的更新檔。要确認在架構中沒有使用預設的密碼。還要檢查是否使用了老的或易受攻擊的架構。
結語
上述要點基本代表了設計安全的應用程式應關注的問題。在設計階段實施這些要點可以減少為保障應用程式安全而花費的總成本。如果企業已經部署了應用程式,那麼,應用程式架構的安全檢查就成為全面安全評估的一個重要部分,并有助于修複已有的漏洞和改善未來的應用程式設計。
本文轉自d1net(轉載)