軟件安全策略-下

軟件安全策略

@author：alkaid

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

前文

• 見 軟件安全策略-上

正文

對抗中間人

背景

• 在前文中提到的三大基石策略——身份認證、訪問控制和會話管理，在通信過程都涉及到與遠程服務器交換秘密信息，同時在實際的業務過程中，也包含了大量的個人隱私信息。
• 如果這些信息被竊取，可能會對社會、個人造成巨大的影響。

概念

• 在具體討論怎么對抗中間人之前，我們首先來看看中間人到底是什么？

• 從名字來看，中間——那肯定是在什么之間。

• 信息系統常見幾個重要的主體，應用、操作系統、網絡鏈路、客戶端、服務端，通信過程如下：
  

• 一般而言，我們所考慮的中間人攻擊的情況是圖中虛線的框框——網絡設備，攻擊者可能控制了相關的路由器或者交換機，進而對應用的相關數據包進行監聽、篡改。

• 一般不考慮應用與操作系統、操作系統與網卡之間攔截，一方面由於這些操作都需要對客戶端/服務端的操作系統進行控制，如果能進行控制，那么有其他更加豐富的方式獲
  取相關的數據，包括但不僅限於hook相關的技術、屏幕錄像。 另一方面，由於需要獲取操作系統的控制權，一般而言是個例，不具有普遍性，在資源有限的情況，不會進行考慮。同時在這類場景下，更關鍵是需要解決惡意攻擊者獲得操作系統控制權的問題。

  • 當然，如果有特殊的要求確實需要納入到考慮范圍的情況，那肯定需要在應用層面去完成，自然是最方便的途徑，從數據的源頭進行防護，設計的要求同針對網絡設備的中間人一致。

• 對抗中間人攻擊，不可能去解決掉中間人，而不可能去保證每個人一個人的鏈路的安全。

• 需要解決如何在不可性的鏈路上去構建一個可信或者相對可信的鏈路。

風險與處理

• 風險其實在背景里已經提到了就是信息被竊取、篡改，而處理的解決方式就是需要去構建可信信道。

• 具體的風險可以細化成以下四種：

  1. 虛擬身份或者臨時身份被竊取
  2. 重放
  3. 監聽（隱私信息采集等）
  4. 業務數據包被篡改

• 從風險可知，構建的可信信道需要滿足

  1. 數據被加密，防止被竊取身份，被采集信息
     • 加密應該保證每個對象與對象之間不同（如果是現代密碼學算法應該保證每組通信采用不同的密鑰）。
  2. 需要支持完整性的校驗
  3. 需要支持對抗重放數據——即每個數據包有自己的標識

已有技術

• 提到中間人，不得不提到的一定是SSL、TLS，以及結合http協議形成的https，一般情況其代碼實現已經集成在操作系統中。
• 理想情況下，TLS或者SSL協議能夠打成我們的目標，但是它們在構建可信信道的過程中，依賴於數字證書技術。如果不當使用數字證書，例如自簽證書、不可信CA濫發證書，那么可信信道就無法構建。
• 無共享信息的可信信道，基本上無法建立，除了量子。
• 那么為了部分解決SSL/TLS的數字證書問題，只能采取增加部分預置信息的方式，例如HSTS——瀏覽器緩存證書，SSL Pinning——內置證書進行比較

注意事項

• 由於SSL/TLS是對抗中間人的完整性校驗和對抗重放，重放的另一個威脅源來自客戶端自身在應用層發起的請求，這類情況無法適用SSL/TLS。
• 一般建議在應用層面的核心業務，再次實現完整性校驗和對抗重放的技術。例如交易。

異常處理

• 滲透測試的小伙伴應該會這樣的體會——只有當輸入信息與我們預期的正常情況存在出入的時候，才會引起注意，例如頁面500報錯、異常的業務流程、預計之外數據輸出。
• 所以異常可以算是一切攻擊的源頭，如果所有的情況都能符合預期，那么我想攻擊者的途徑應該會少很多吧。
• 可惜的是人非聖賢，異常難以避免。
• 對研發而言，我們希望異常越清晰越好，查看異常越簡單越好，能夠協助我們盡快的定位bug，分析業務。
• 在攻擊者在挖掘漏洞的過程，同樣希望異常越清晰越好，與開發者們的預期一致，在頻繁的上線和更新代碼的過程中，經常會遺忘掉這些暗門，從而使攻擊者能夠從研發留下的痕跡中收獲不少敏感信息。
• 所幸的是目前部分框架已經支持對全局異常的統一處理。
• 剩下的需要解決的是配置問題，在下文中也會單獨的講這個問題，不過在這個篇章里索性就先提一點。
  • 研發人員和攻擊者都關注異常信息，自然不可能把異常信息全都屏蔽，那么對於研發人員可能是一場災難。
  • 那么如何把兩者划開來呢，測試環境自不必說，對於生產環境而言，攻擊者能接觸到的應用頁面、通信的數據包，而研發人員在授權的情況下，理論上可以接觸到所有數據的，所以我們可控制異常信息的輸出，輸出到攻擊者無法接觸的地方，例如操作系統的某個固定目錄下、統一的日志收集平台。
  • 當然有個后話，如何保證相關目錄的安全、日志平台安全以及哪些數據需要隱藏又是我們需要繼續考慮的問題。

注意事項

• 異常處理的手段其實在本質上並不能解決信息泄露的問題，只是通過對異常處理的控制，盡可能地降低從異常中獲取的信息量，提高攻擊者的攻擊成本和利用難度，從而降低風險。
  • （沒有任何回顯，本身就是一種異常。只是造成這類異常的情況豐富且復雜，從而降低從異常中獲取得信息量）
  • PS：信息量/信息熵等概念，可自行搜索了解，本質上是為了量化信息。

配置管理

• 對於應用系統而言，經常需要部署在不同的運行環境，我們引入了配置從而避免了因為環境的變動就需要對應用進行重新編碼，重新測試的情況，同時各種各樣的配置項可以支持各式各樣的組件和程序不同的運行方式，極大的提高了效率。

場景一 不同的運行環境

• 跨平台的編程語言解決了應用需要在不同操作系統部署的問題，優化了大量的時間投入。但是它們沒辦法解決不同抽象的運行環境，例如開發環境、測試環境、准生產、生產環境，不同的抽象運行環境對應着不同的組件、網絡以及信息安全的要求。
  • 開發環境/測試環境：對於信息安全的要求應該是最低，同時也是輸出信息最為豐富、系統最不穩定的。
  • 准生產/生產環境：對於信息安全有明確的要求，僅保留必要的輸出，系統最為穩定。

風險與處理

• 在從開發環境切換到准生產/生產環境，難免需要更新具體的配置，一般而言會考慮引入編譯的配置選項來解決，實現一鍵切換，例如maven的profile屬性，不同的屬性值對應了不同的策略，包括不同的打包策略、不同的配置文件。
• 這類方式是提高系統可靠性的重要方式，但是也存在一些副作用，需要使用者進行控制。
  1. 如果管理不當，開發者有可能接觸到生產環境的具體配置信息，對生產經營產生影響
  2. 如果打包策略/配置文件未進行檢查和校驗，導致多個環境信息被一起打包。
  3. 如果缺少對具體配置項的檢查，導致生產環境采用了測試環境的配置，進而可能產生信息泄露事件。
  4. 各個組件（中間件、容器等）的配置。雖然目前有docker一類的容器技術，用於實現運行環境的標准化配置，但是標准化配置不是一個不再需要關注的點而是一個更加需要關注的點，試想如果某個標准化上配置存在弱口令賬號或者所有的標准化環境共享一個賬號，會帶來什么樣的風險。

場景二 日志管理

• 日志功能相關的組件越來越成熟，大多通過配置進行實現，索性就納入到了配置管理模塊。
• 日志是目前所有系統審計的重要依據，同時也是發現攻擊者和內鬼的重要手段，但是隨着SSL/TLS等相關加密方式普及，位於通信鏈路上的相關設備越來越難以捕獲到明文信息，應用系統自身的日志顯得越來越重要。 我想隨着雲相關技術的進一步推廣，應用系統的日志會更加重要。
• 如何管理這些日志，采集哪些日志就是需要進行考慮的。

風險與處理

• 日志最好也能有全局的日志控制。
• 當然，如果需要最大發揮日志的價值，一般是需要匯集到統一的日志平台，用於支持搜索。而日志往往包含了最詳盡的業務信息，從某種意義上而言，這些日志可能是在誘導犯罪。（不知道是不是對前文中關於臨時身份有印象，拿到這些臨時身份的令牌，就可以完成身份竊取）
• 一類風險是正式這些日志信息造成，我們需要有明確的規定有指導數據記錄，例如敏感信息、個人隱私信息、令牌、身份等信息，不要存儲全文，需要進行部分的模糊化。
• 另一類風險正是引入日志平台其本身帶入的風險。
• 日志的具體配置不當，例如本地的日志文件存放到了web的相關目錄，從而能直接訪問，造成大量信息泄露。（相關實例可自行搜索）

場景三 權限配置

• 目前越來越來多的應用支持復雜的權限配置和資源配置，有效維護這類信息，能夠大幅度降低安全風險。
• 具體涉及的權限內容，可查看訪問控制策略章節了解

軟件技術棧

概念

• 軟件技術棧——我姑且這么寫如果有更好的名稱可以私信我，這里主要想提一提應用系統中那些無法進行掌控的第三方組件，例如java的第三方jar、框架、中間件。
• 對於現在的應用程序而言，從零開始的搭建已經有點不可能了，不是技術不可能，而是業務上不可能，我們需要速度，在已有輪子的前提下，肯定不需要再造輪子，即使造輪子，你有能力保證造的輪子就比別人的好使嗎？
• 但是呢，這類第三方的代碼與我們編寫的代碼在運行時共享的是同樣的權限、系統資源，如果這些代碼出現了問題，又當如何？

風險與處理

• 至少需要能管理、了解到底用了哪些第三方的代碼。唯有這樣，在相關的第三方出現安全問題時，能夠快速響應，做到止損。（相關工具：SCA——軟件成分分析軟件）
• 盡可能不使用存在已知問題的組件，不使用停止維護/維護不當的第三方內容(如果是開源的，己方有能力維護可以不納入考慮)。

敏感數據

• 敏感數據現在是屬於法律法規領域最關注的一個點了，雖然互聯網上的應用五花八門，但是所有這些虛擬身份的背后都是一個唯一的實體人。生命以負熵為食，人天生喜歡規律也是有規律的，大量數據可能能夠重新去定義一個實體人，通過定向的投放去影響和控制人，甚至盜取這個人的現實身份，這也是為什么敏感數據會成為各國法律法規的關注點。
• 所以在應用系統設計的初期，我們必須需要明確哪些是所謂的敏感數據，以及圍繞着敏感數據的生命周期要如何處置

哪些是敏感數據

1. 個人隱私

   • CISSP ALL in One 在隱私章節里給出部分屬於隱私的數據類型，如下：
   • 

2. 敏感的業務數據

   • 財務相關交易記錄
   • …… 需要根據具體內容去決定

敏感數據的生命周期

• 一般而言，生命周期至少包括數據的產生、存儲、使用、銷毀，該過程映射到實際的應用系統中可能還需要進行更加細節的處理。
  1. 傳輸
     • 應用系統涉及到信息交互，那么首先要新增的一個過程就是傳輸，在傳輸過程中的敏感信息要如何進行處理是需要進行明確。明文傳輸肯定是不行的。
  2. 產生
     • 我覺得更明確的詞，應該是采集。
     • 采集就涉及到到底是采用完整的數據，還是部分關鍵即可，如果是部分關鍵，那么將采集出的數據直接轉成Hash摘要可作為一種參考方式。
  3. 存儲
     1. 避免明文存儲
     2. 如果不需要明文的敏感數據，建議采用hash算法等方式轉化數據，僅用於對比
     3. 如果需要明文的敏感數據進行操作，建議采用加密算法保障
     4. 其他情況
  4. 使用
     • 使用可能涉及到多個場景，例如客戶端頁面的展示、業務操作的需要，如不必要進行展示，盡量不進行展示。
  5. 銷毀
     • 一般這類敏感數據是需要提供銷毀數據的功能的，是真正從數據庫清空相關信息，而不是通過標志位實現的假刪除方式
• 注意： 這里的說明，僅僅是提供敏感數據相關策略的參考，具體內容以相關的法律法規以及業務自行設計。

輸入輸出

概念

• 輸入與輸出，絕大多數的漏洞都在體現在這方面，假如一個系統完全沒有輸入和輸出，開個玩笑，如果真有這個系統，有和沒有又有什么區別？
• 輸入與輸出，這兩個詞雖然簡單但是里面缺少了一個東西——主體，什么東西的輸入輸出。
  • 假如實體服務器，那么輸入輸出基本上就是我們在通信鏈路上來回輸送的數據，但是這些數據有點駁雜，沒有辦法再進一步的處理，唯一能做是采用一些全局的過濾器或者攔截器，但是誤殺又太高。
    • 所有站在這個維度，雖然實現起來相對容易，但是把握度的難度會比較困難
  • 假如把實體的粒度划的再細一點，定義成應用軟件（軟件，而非系統）。從這個維度來看，系統的輸入和輸出類型就豐富來起來
    1. 輸入：來自文件系統上的文件、數據庫中的數據、中間件/容器傳遞的業務數據、其他組件的數據輸入、
    2. 輸出：文件系統、數據庫、其他組件、中間件/容器
    • 此時的輸入輸出可以看得出與部分漏洞有了聯系，例如與文件系統相關的文件上傳漏洞、任意文件讀取漏洞
• 記住，原則上一切的輸入和輸出都不可信，只是經過校驗和過濾的數據才能提高可信度。

風險與處理

• 通過縮小實體的粒度，我們更加明確了輸入與輸出，后續的風險便是圍繞着具體的輸入信息和輸出的信息進行分析，構建針對性的過濾和處理。
• 當然，這種方法因為縮小了粒度所以在實現上就要復雜的多，主要是分析工作量增大，需要有針對性。

引用

• 深度解讀SSL/TLS實現
• SpringBoot開發詳解（六）-- 異常統一管理以及AOP的使用