通過限制代碼中原語的數量，開發人員可以使黑客利用軟件的過程更加困難，從而增加利用成本并降低其可能性。

軟件對軍隊的野戰防御和作戰支援能力越來越重要。軍事和航空航天系統中的嵌入式軟件必須既可靠又安全，因為安全漏洞可能與行業開發的許多控制措施來防止的功能缺陷一樣危險。

許多用于解決功能或質量缺陷的相同技術也可以減少安全漏洞。在軟件開發方面，安全缺陷應被視為軟件缺陷，并作為開發過程的一部分進行管理。事實上，安全和質量之間的區別有時可能是微妙的。今天表現為系統故障的缺陷明天可能會被攻擊者利用。

缺陷本質上是潛在的利用原語1，黑客可以創造性地將其串在一起進行攻擊。開發人員可以通過消除盡可能多的原語來使攻擊者利用軟件的過程更加困難。下面的示例演示如何將多個基元鏈接在一起以實現遠程代碼執行。

多基元攻擊示例

假設駐留在遠程上的代碼中存在安全漏洞。雖然確定根本原因足以修復缺陷，但成功利用該漏洞取決于多個預先存在的條件。對于此示例的上下文，我們假設攻擊者嘗試實現遠程代碼執行 （RCE），從而在遠程計算機上運行攻擊者選擇的代碼。雖然觸發安全漏洞是實現RCE所必需的，但它實際上需要許多小步驟，我們稱之為利用原語。通過將這些原語鏈接在一起，攻擊者可以創建一個可靠工作并在漏洞利用結束后保持穩定性的漏洞利用。

在我們的示例中，攻擊者使用（但不限于）四個唯一的基元。使用的第一個原語是軟泄漏2，它利用合法的程序功能來操作目標應用程序中的內存，而不會對穩定性或安全產生影響。這些基元恰好是最常見的，因為它們依賴于預期的有效程序功能。例如，根據設計，服務器將接受來自客戶端的請求。該客戶端發送在會話終止發生之前一直保留的信息。漏洞利用編寫者可以通過確定這些請求和會話的工作原理，根據特定應用程序的功能對其內存布局做出某些假設。

下一個使用的基元是硬泄漏2。硬泄漏或資源泄漏對于大多數 C/C++ 程序員來說非常熟悉。當程序員忘記釋放在運行時動態獲取的內存時，就會發生泄漏。雖然大多數程序員認為這是一個質量問題，在最壞的情況下會導致大量內存消耗，但許多開發藝術家認為這是確保漏洞利用穩定性的機會。攻擊者可以通過永久獲取內存來確保內存的某些部分在進程的整個生存期內永遠不會被使用。

使用的第三個基元是整數溢出。如果數學運算嘗試存儲大于整數可以容納的數字，則多余的數字將丟失。多余數據的丟失有時稱為整數換行。例如，無符號 32 位整數可以保存最大正值。通過將 1 加到該最大正值，整數將在零 （UINT_MAX + 1 == 0） 處再次開始計數。一個真實的例子是汽車在行駛 100 萬英里后翻車并從零重新開始里程計數的里程表。攻擊者可以通過在分配例程中使用此溢出整數來分配比預期更少的內存。

最后，最后一個使用的基元是緩沖區溢出。這是 C/C++ 程序中最常見的具有安全影響的缺陷類型。當程序寫入超過緩沖區末尾時，會導致緩沖區溢出，從而導致相鄰內存內容損壞。在某些情況下，這可能會導致覆蓋堆棧或堆的內容，從而允許攻擊者破壞系統的正常運行，并最終接管程序的控制流。

RCE 中的原始用法

現在，基元類型已經介紹完畢，讓我們討論示例中的攻擊者如何利用它們來實現遠程代碼執行。首先，通過使用現有的程序功能，攻擊者發送有效的請求，導致根據其輸入的大小分配許多內存塊。這似乎無害，但對于實現堆確定性至關重要：將應用程序的內存布局操作到已知的理想狀態，這在利用基于堆的緩沖區溢出時是強制性的。接下來，漏洞利用作者知道一些內存一旦分配，就永遠不應該再釋放。通過利用應用程序中的硬泄漏，可以實現在進程的整個生命周期中保持內存的目標，從而提高開發后的穩定性。

觸發了導致未充分分配的堆緩沖區溢出的整數溢出。這會導致分配緩沖區的實際大小與其包含的預期數據元素數不匹配。然后，攻擊者可以利用緩沖區溢出來覆蓋相鄰內存的內容。例如，假設無法確定一張規則紙的最后一行。如果你按順序繼續寫句子，你最終會在桌子上寫字，并可能寫下那件漂亮的新襯衫。通過覆蓋相鄰內存，攻擊者可以用他控制的數據覆蓋重要信息。

無論嚴重性如何，將基元鏈接在一起的能力都可以更好地控制利用和開發后功能。如果我們的攻擊者沒有能力在應用程序中創建硬泄漏，他將不得不找出一種不同的方法來確保他的內存在會話超時時不會被釋放，或者他至少會意識到最終的程序崩潰是不可避免的。如果整數溢出不存在，我們的攻擊者根本沒有機會利用。

利用原語和安全漏洞之間的聯系可以是直接或間接的。某些類型的基元（如緩沖區溢出）可能導致許多不同類型的漏洞，具體取決于攻擊者的技能、創造力和決心。然而，顯而易見的是，擁有更多可用的原語使攻擊者更容易利用更嚴重的漏洞并開發破壞性漏洞。因此，在開發過程的早期查找和消除大量利用原語可以極大地幫助減少應用程序服務期間的安全漏洞暴露和維護成本。

保護代碼開發的實用方法

開發可靠且安全的軟件是 IT 團隊面臨的一項艱巨挑戰，因為將安全測試盡早集成到開發生命周期中的計劃尚未得到廣泛采用。這并不是說開發人員不想開發安全的產品，而是他們專注于提供新的特性和功能，并且經常面臨滿足發布截止日期的巨大壓力。除了缺乏投資加強安全性的經濟激勵外，開發人員傳統上沒有接受過安全專家的培訓。計算機科學課程的重點是培養具有成為優秀應用程序開發人員基礎的程序員，但不一定是安全專家。因此，今天的開發人員基本上沒有意識到他們可以在代碼中引入安全問題的無數種方式，并且在發現安全問題時也沒有資金來修復它們。

開發測試解決方案需要從開發人員的角度進行設計。這意味著要解決使開發人員回避傳統安全評估工具的主要問題：缺乏可用性和高誤報率。尋求將安全測試集成到其流程中的開發經理應尋找能夠提供以下功能的自動化開發測試工具：

清晰解釋缺陷，噪音小：開發人員根本沒有時間浪費時間試圖篩選嘈雜的結果，或重現實際上不存在的虛幻缺陷。他們需要易于理解且誤報盡可能少的缺陷。

在編寫代碼時及早并經常檢測缺陷：確定缺陷的確切原因需要付出大量努力，修復缺陷可能涉及大量的體系結構更改。盡早發現關鍵缺陷使開發團隊能夠預測工作負載和對發布計劃的影響，從而降低整個項目的成本。

有關如何修復安全缺陷的可操作且正確的建議：作為安全評估的一部分提供的缺陷修正建議通常不會針對軟件包中使用的相關框架、語言或庫進行自定義。開發人員很難將通用建議轉化為有效的修復程序，這通常會導致應用錯誤或不完整的修復程序，從而導致客戶流失和返工。

缺陷是軟件開發不可避免的事實。雖然可能無法完全防止在代碼開發過程中引入漏洞，但現在存在的技術和流程可以幫助開發人員盡可能快速有效地查找和修復這些缺陷。

審核編輯：郭婷