軟件安全策略-上

軟件安全策略

@author：alkaid

生命以負熵為食 —— 《生命是什么》薛定諤

背景

• 我想作為一個信息安全從業者，無論是在滲透測試、代碼審計亦或是其他安全服務中都會接觸到各種各樣的漏洞。把這些漏洞進行簡單分類可能能夠得到幾十類漏洞，當然幾乎所有的漏洞類型在common Weakniss Enumeration都有相應的描述。

• 面對類型如此豐富漏洞，我們要如何進行處理呢？

• 要知道人類的本質是懶惰，逐條進行分析驗證幾乎是不可能的。而且滲透測試、紅藍對抗等服務在本質上都是為了達到以點帶面的目的，那么這個面在哪里是值得我們去思考的問題。

• 廢話扯完了，進入正題。

安全策略框架

• 本文所說的安全策略，即系統采用的方式用於處理可能存在的安全風險。
• 我這邊簡單的梳理了一下，在考慮軟件安全時需要考慮的幾個方面的問題，（在標題中斗膽用了框架這個詞，我希望這樣框架確實能夠幫助到更好的實現軟件安全），圖如下：

1. 身份認證策略、訪問控制策略、會話管理策略這三個方面基本上屬於整個軟件安全的基石，如果這三個方面缺少了相應控制或者實現的大方向上存在問題，那么對於整個軟件的影響極大，可能是顛覆性的需要推到重建。
2. 對抗中間人： 對於中間人攻擊大部分人的看法可能是屬於軟件后期的部署問題，采用https/HSTS就沒什么問題（問題可能並沒有這么簡單），不過我還是把它納入到框架。
3. 輸入輸出： 這可能有點老生常談，不過我覺得清楚的了解對於軟件而言是輸入，什么是輸出，可能會更好進行分析。
4. 敏感數據：在網絡逐漸形成虛擬社會的背景下，其開放性的特征必然會引起有關部門的注意，作為一項重要的合規項應當在初期就納入考慮到。同時如果出現相應的問題，軟件修復起來極其頭疼，完全可能出現修不完的情況，在投產的過程觸犯了相應的法規造成的損失可能也極其巨大。
5. 軟件技術棧： 白話一點的說法就是軟件都用了什么技術。
6. 配置管理： 一些意料之外漏洞可能都出自於錯誤的配置管理，諸如交易日志泄露
7. 異常處理： 安全對抗的本質是獲取信息，盡可能的獲取一些常規獲取不到的信息，異常是一項比較重要的來源。

身份認證

概念

• 在虛擬世界中的身份認證同現實世界中一樣，首先需要識別人，建立在識別的基礎能夠去開展各項業務，產生、處理、使用、存儲數據。 只是目前而言，由於你是真實存在的，不會出現類似於證明你是你問題，而虛擬身份的更像是一個物化的概念，那么身份認證就是能夠證明虛擬身份是屬於現實的你。
• 所以在虛擬世界這是一個必須要解決的問題——如何讓真實的你與虛擬世界中虛擬的你進行綁定。
• 那么最直接的方式就是提供秘密——只有賬號的擁有者持有的信息。例如在賬號注冊時輸入的密碼信息、密保信息
• 換句話說，在虛擬的世界中只要能夠提供賬號的相關的秘密信息，就能聲明賬號的所有權。因為對於全知全能的程序而言，它都是僅僅收到了這個秘密，你和他並沒有區別。
• 舉個例子：
  1. alkaid登錄賬號alkaid，輸入了密碼password，程序驗證通過，允許以alkaid賬號執行相關業務
  2. person2 不知道通過什么途徑知道了，alkaid/password的認證信息，程序驗證通過，允許以alkaid賬號執行相關業務。

風險與處理

• 現在身份認證應該就是很清晰了，其實就是驗證虛擬賬號的秘密信息，那么要知道只要是驗證信息就會返回成功和失敗的結果，從一定程度這也是一類信息泄露，只是信息泄露的量較少，通過不斷累積信息，就能最終破獲秘密信息，也是身份認證主要的風險點。

• 這類風險的直接體現就是暴力枚舉破解賬號。

• 當然，這風險屬於無法解決的，我們只能采用降低風險，使風險可控的方式：

  1. 解決累積信息的特點。
     • 賬號鎖定機制
  2. 由於完美解決1是相對困難的（主要是引入的不可用風險不一定能被接受），也可以采用提高目標的信息量的方式，在有限的時間維度內，無法破解賬號
     • 提供秘密信息的復雜度，例如密碼的復雜度
     • 采用驗證碼技術，防止通過機器突破現實人的極限。
  3. 減少單次信息累積的量
     • 模糊失敗的錯誤提示

• 其實還有其他的無法解決的風險，例如秘密信息被竊取。所以一般還會要求提供更換秘密信息的功能。

  • 采用生物信息的技術讓人難以接受的是無法進行更新秘密信息，如果需要更換可能需要重新設計相關的算法和信息采樣的算法，可能會要求所有虛擬用戶同時更換設備和秘密信息。

會話管理

概念

• 由於HTTP協議屬於無狀態（每個數據包都是獨立的，僅根據數據包無法判斷之前發過哪些數據包）的協議，同時在身份認證一節中已經說明大部分的業務操作是需要基於虛擬身份進行的，那么在完成身份認證后，后續數據包無法回溯之前的數據包，從而導致無法證明自己確實能夠持有聲明的虛擬身份。

• 當然如果每次都帶着身份的秘密信息請求進行確實是可以進行身份認證，但是頻繁的使用這類秘密信息可能會增加秘密信息泄露的風險。

• 現實的生活中由於時間和空間的限制，基本上不存在這類風險，我們也很難進行參考。

• 不過這類問題反過來——如何讓服務器知曉是你這個真實的人在操作你的擁有的虛擬身份（問題又回到了身份認證）

  • 同身份認證一章節所述，那就是掌握秘密信息。
  • 即服務器與我商量一個只有我們兩個人知道的臨時秘密，來替代原先虛擬身份的秘密。
  • 臨時秘密作為虛擬身份的秘密的替代品，在每次訪問時都進行提供。—— 臨時秘密即我們一般而言的sesssionID（會話ID）。

• 會話管理，即圍繞sessionID是怎么進行處理的。

• 再繞一點，是不是覺得會話像是系統給我開設的臨時虛擬身份，但是同時具有原先虛擬身份的信息？

  • 確實沒錯，會話從某種程度上來講與賬號其實沒有區別，也能夠提供相應的信息存儲，只不過會話是臨時的。

風險與處理

• 會話與賬號相似，其面對的風險也與身份認證相同。
• 但是由於是相似（如果完全相同，又會回到最開始的問題——無法證明自己確實能夠持有聲明的虛擬身份），會話最大的一個特征是臨時性。 由於預置的時間屬性，基本我們采用2中的復雜度方式。
• 如何來盡可能的保證的復雜度呢？
  • 隨機生成的符號組合。（避免組合單詞，賬號信息等，從信息熵的角度來說，盡可能避免與已知信息相關聯，關聯的越多，這段數據包含的信息越少，越容易被猜測）
  • 一定長度的保證（每一位的長度增加，破解難度都是成倍提高）

訪問控制

概念

• 鑒於可能會與我們學習過的MAC、DAC、RBAC混淆，這節討論的東西不是這些具體的策略，談論這些具體的策略，可能搜索一下google、wiki來得更加方便和准確,是討論訪問控制解決什么問題，面對什么樣的風險。
• 涉及到訪問控制，自然有兩個概念，主體和客體。

主體

• 一般指提出訪問請求的對象。在實現身份認證和會話管理的基礎上，主體相對明確，有兩類構成
  • 虛擬身份代表的主體
  • 沒有虛擬身份，（代表了所有未授權的情況）

客體

• 一般指被訪問的資源。 具體哪些資源其實在相關的系統里是很難明確的，這里我僅提及兩類，功能和數據。 它們應該是在各類系統中最最常見的兩類資源。

分析

• 既然是虛擬時間，如果排除了空間和時間的影響，其本質應該是一樣的，現實中與安全性質類似場景包括消防、防盜、安保等
• 這里以我居住的小區為例，alkaid 住在A小區1幢11層1111房間。
  • 我需要回到我的房間需要經過，小區的門禁、1幢的門禁、1幢的電梯梯控、1111房間的鑰匙、密碼。
• 我們講現實的場景與虛擬的場景進行映射，幫助進行分析也方便大家思考，發現一些我可能沒有提到的東西。
  • 小區的門禁，相當於系統的身份認證，通過門禁確認我屬於小區的住戶
  • 進入小區后，處於會話管理的范疇內，當我只持有1幢的門禁和梯控，相當於只允許我訪問某些功能。
  • 而房間鑰匙則對應着我的數據訪問權限。
  • 而小區的跑道和綠化則屬於授權用戶的公共資源， 小區外的其他則屬於任何人都能訪問的資源
  • 小區中遍布的監控能夠支持對行為的審計

總結

• 在訪問控制方面，我們至少需要幾點：
  1. 功能級別訪問控制
  2. 針對用戶數據或者其他資源的數據級的訪問控制
  3. 梳理公共資源以及個人的資源
  4. 監控與審計

風險與處理

• 風險也圍繞着我們在上文所說的幾點

1. 相關資源的訪問控制（即門禁的設計）。
   1. 根據系統不同的需要，對不同的資源設置相應的訪問權限。畢竟在一般情況下，我房間應該只有我以及我授權的相關人員能夠進入
   2. 需要評估和確認訪問權限設計的有效性，滿足最小化的原則
   3. 對於資源默認的訪問權限應當是拒絕
2. 授權繞過/未授權訪問
   1. 在系統變更過程中是否持續對資源進行梳理和監控
3. 側信道/信息推測
   1. 例子的描述： 房間里會有窗戶，可能透過窗戶能夠看到一些 或者 分析你的生活習慣推測一些信息。 從描述來看，風險相較於其他幾項較少
4. 之前提到過，我們忽略了時間和空間的影響。在虛擬世界中可能會存在直接訪問到我個人房間的情況，所以一般情況下我們首先需要去驗證訪問者是否持有認證通過后持有的虛擬身份。（一般這個操作在軟件系統中會作為全局攔截器來實現，相當於將所有的資源納入到門禁的范圍內，避免在實現新增功能時，忘了考慮這類情況，從而產生風險【該類情況即使通過審計發現，也無法進行追溯】。）

總結

• 本文暫時只分析三個基礎策略，后續會進行更新其他的內容。