建構安全軟體開發 EP 29

2022 iThome 鐵人賽

DAY 29

Security

建構安全軟體開發系列第 29 篇

14th鐵人賽

James Tsai

2022-09-29 11:09:31

1274 瀏覽

分享至

Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

本篇是 建構安全軟體開發 系列文的 EP29。

在上回提到，SEI 所提出的 "Top 10 Secure Coding Practice"：

Validate input (驗證輸入)
Heed compiler warnings (注意編譯器的警告)
Architect and design for security policies (根據安全政策建構與設計)
Keep it simple (保持簡單設計)
Default deny (預設設定拒絕)
Adhere to the principle of least privilege (採取最低權限執行原則)
Sanitize data sent to other systems (傳遞資料時內容格式準則化)
Practice defense in depth (多重防禦縱深活動)
Use effective quality assurance techniques (確保使用有效與品質技術)
Adopt a secure coding standard (適切採用安全程式碼準則)

在落實開發過程當中還有哪些觀念會影響到開發實作時的安全呢？

Declarative vs. Imperative (Programmatic) Security

當代的程式設計與開發環境(無論是 .NET、Java、Python，那個 C/C++ 就...)，通常會支援兩種概念的開發風格 (Style)：

Declarative (宣告式)
Imperative (指令式)

這裡以 C# 語言舉個例子，如果有 6 個學生的考試分數，想要知道這六位學生分數的總和與平均，以上述兩種作法撰寫的程式大致如下：

Declarative (宣告式)：直接撰寫這程式想要什麼樣的執行結果產生，例如：

	int[] scores = { 98, 78, 87, 56, 64, 100 };
	
    var total = scores.Sum();
	var average = scores.Average();
	
    System.Console.WriteLine(total);
	System.Console.WriteLine(average);

Imperative (指令式)：撰寫程式時明確的去描述程式執行，如何一步一步去運作完成，例如：

    int[] scores = { 98, 78, 87, 56, 64, 100 };
    var total = 0;
    
    foreach(var score in scores)
    {
        total += score;
    } 
    var average = (double)total / scores.Length;
    
    System.Console.WriteLine(total);
    System.Console.WriteLine(average);

以上述的例子來說，兩種作法最後都會得到 "總和為 483" 跟 "平均為 80.5" 的答案。

而使用上的對於開發者來說也都各有其優缺點，這就依照個人、團隊、組織...等的開發習慣與文化而定，無論採取上述的哪種開發風格的作法，這都不會造成其程式本身的安全性問題。

如果覺得有疑義，以 .NET 的 C# 語言來說，可以透過 Microsoft 所提供 .NET 的 "Code Analysis" (程式碼分析)，去進行驗證：
https://learn.microsoft.com/dotnet/fundamentals/code-analysis/overview

而倘若再進一步的可以看到 "Code Quality Rules" (程式碼品質規則)：
https://learn.microsoft.com/zh-tw/dotnet/fundamentals/code-analysis/quality-rules/

這些程式碼品質規則的範圍含括 "Design Warnings" (設計規則)、"Globalization Warnings"(全球化)、"Maintainability Warnings" (維護性規則)、"Performance Warnings" (效能規則)...等各種領域，則請視整體的專案需要而去搭配運用。

在這邊要提出的是其中有關 "Security Warnings" (安全性規則)：
https://learn.microsoft.com/dotnet/fundamentals/code-analysis/quality-rules/security-warnings

這些 "Security Warnings" (安全性規則) 對於防止所開發者所撰寫的程式發生安全性瑕疵問題。

所以若是 "停用/忽略" 這些安全性規則中的任何一條警告，務必 "明確標示" 出在程式碼中的安全性警告發生的原因並對 "停用/忽略" 提出解釋，並且 "通知/請示" 管理此開發程式專案中所指定 "安全性管理人員"，並在 "正規" 的 Code Review 中去詳實討論與檢驗。

可以套用看看到上述兩種開發作法上，去套用看看程式碼分析，看看會不會有迸出 "安全性規則" 的問題吧！

對了，再次強調是 "安全性規則" 的問題，若有迸出其他分類的規則問題(如：設計、效能...等)不在此討論範圍。

雖然前面所提的是 Managed Code 的開發環境為主，但 Microsoft 對於 C++ 的部分也是有一份 C++ 語言的安全性規則的檢查指引，詳見下方連結：
https://learn.microsoft.com/cpp/code-quality/code-analysis-for-cpp-corecheck

如果各位不嫌棄，還可以了解一下如何在 C++ 的開發環境當中使用，詳見下方連結：
https://learn.microsoft.com/en-us/cpp/code-quality/using-the-cpp-core-guidelines-checkers

Asynchronous Programming

非同步執行程式開發 (Asynchronous Programming) 在近代的程式開發運用上是相當常見的，所以開發實作上的安全性問題也更明顯且頻繁的發生。

在 "Asynchronous Programming" 當中有兩個詞 Concurrency、Parallelism，常被混淆成同樣的概念，但其實應該區分成：

Concurrency - 通常指的是要對 "物件資料等資源" 來 "同時" 存取。
Parallelism - 通常指的是 "執行中的程式" 能併行運作。

Sequential Concurrent Parallel
上圖取自 Concurrency - Reace Condictions and Deadlock 第 2 頁。

也就是說，兩個執行中的程式可以同時運作(Parallelism)，但是並非一定需要 "同時" 存取資源。

如果種 1 顆西瓜下去到成熟採收需要花 2 個月，那在 1 整年就只能種出 6 顆西瓜嗎？

結論:
所有的 Parallelism 可能會發生 Concurrency，但並非所有的 Concurrency 都來自 Parallelism。

Concurrency

CWE-820: Missing Synchronization

If access to a shared resource is not synchronized, then the resource may not be in a state that is expected by the software. This might lead to unexpected or insecure behaviors, especially if an attacker can influence the shared resource.

這就沒什麼好說的，就是明明白白的列在那裏的 CWE-820 弱點，而其中 Concurrency 最常出現的漏洞性問題是 "Race Conditions"。

Race Conditions

CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

The program contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.

... 略 ...

A race condition violates these properties, which are closely related:

Exclusivity - the code sequence is given exclusive access to the shared resource, i.e., no other code sequence can modify properties of the shared resource before the original sequence has completed execution.

Atomicity - the code sequence is behaviorally atomic, i.e., no other thread or process can concurrently execute the same sequence of instructions (or a subset) against the same resource.

這個安全性弱點(CWE)而造成的明確的安全性漏洞(CVE)其實不少，就舉近兩年的 CVE-2021-1782、CVE-2021-0920、CVE-2020-6819 就好，更別說更早之前所造成的安全性漏洞 (CVE) 還有額外的 17+ 個。

其實針對這個 Race Conditions 的情境，通常會發生在下列三種特徵出現的時候：

Concurrency property：有至少兩個控制流程出現了執行的競爭關係。
Shared object property：它們同時要競爭同一個共享的物件(資源)。
Change state property：至少有一個控制流程對所兢爭的物件(資源)改變了其狀態。

可透過下列兩種概念的調整設計，去避免上述的三種特徵的任一項，以解除會發生 Race Conditions 的情境：

Race windows (a.k.a: Critical Section)
Mutual exclusion (a.k.a: Mutex)

運作概念如下圖：
Prevent Race Conditions
上圖取自 Concurrency: Race Conditions and Deadlocks 第 7 頁

不過，理想上是如此，但處理不好也可能會造成其他問題，如: DeadLock...等，但這又是後話了。

而透過 "Race Conditions" 關鍵字在 CWE 網站上搜尋，其實還有很多安全弱點的存在：
CWE about Race Condition

尤其 "查用不一(TOC/TOU)" 造成的 Race Condition 後，進而繞過權限檢查或保護機制: "CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition" 也是有過不少著名的 CVE 漏洞，如：CVE-2015-1743、CVE-2008-1570...等。