<menu id="guoca"></menu>
<nav id="guoca"></nav><xmp id="guoca">
  • <xmp id="guoca">
  • <nav id="guoca"><code id="guoca"></code></nav>
  • <nav id="guoca"><code id="guoca"></code></nav>

    企業安全 | 淺談軟件安全開發

    VSole2022-11-24 07:15:42

    安全性在軟件開發過程中是一個極其重要和深刻的話題。當安全性受到損害時,會發生非常糟糕的事情。我們在軟件開發生命周期的各個階段都必須記住這一點。

    不同于一些其他非功能性要求,一般不能在之后才在系統中考慮到安全性。開發一個相對安全的項目離不開一個安全規則的指導,一個好用的開發工具,一套安全的編碼規范。

    下面就從開發安全規則、開發工具的安全利用,安全編碼這三方面進行分析。降低軟件中的漏洞,包括但不限于緩沖區溢出、邊界外的數組訪問、未初始化的內存使用、類型混淆等安全漏洞。

    安全開發規則

    一個好的安全開發指導規則,能夠在開發軟件過程中挖掘出漏洞的。這個好的安全規則首選推薦微軟的SDL(安全開發生命周期)。下面就梳理下這個SDL的一些相對核心的理論基礎。

    它主要側重于軟件開發的安全保證過程。SDL致力于減少軟件中漏洞的數量和嚴重性。

    SDL的核心理念是將安全考慮集成在軟件開發的每一個階段:需求分析、設計、編碼、測試和維護。從需求、設計到發布產品的每一個階段每都增加了相應的安全活動,以減少軟件中漏洞的數量并將安全缺陷降低到最小程度。

    SDL基于三個核心概率:培訓教育、持續過程改善和責任。

    SDL的一個主要目標:安全和隱私。

    SDL在開發過程的所有階段進行安全和隱私保護

    安全開發生命周期 (SDL)由一組支持安全保證和合規性要求的實踐組成。SDL 通過減少軟件中漏洞的數量和嚴重性,同時降低開發成本,幫助開發人員構建更安全的軟件。

    SDL詳細步驟

    SDL安全設計核心原則主要包括:攻擊面最小化、基本隱私、權限最小化、默認安全、縱深防御、威脅建模。下面就這對這些原則展開做個簡單解析。

    攻擊面最小化(Attack Surface Reduction):

    指盡量減少暴露惡意用戶可能發現并試圖利用的攻擊面數量。軟件產品的受攻擊面是一個混合體,不僅包括代碼、接口、服務,也包括對所有用戶提供服務的協議。尤其是那些未被驗證或者遠程的用戶都可以訪問到的協議,安全人員在攻擊面最小化時首先要對攻擊面進行分析,攻擊面分析就是枚舉所有訪問入庫、接口、協議一劑可執行代碼的過程,從更高層次來說,攻擊面分析著重于如下4點:

    1、降低默認執行的代碼量

    2、限制可訪問到代碼的人員范圍

    3、限定可訪問到代碼的人員身份

    4、降低代碼執行所需權限

    基本隱私(Basic Privacy):

    指用戶在使用軟件時無可避免個人信息被收集、使用甚至分發,企業則有責任和義務建立保護個人信息的保護措施,抵御敵對攻擊行為,確保用戶基本隱私的安全性。

    權限最小化(Least Privilege):

    指如果一個應用程序或網站被攻擊、破壞,權限最小化機制能夠有效的將潛在損害最小化。常見的權限最小化實踐如:

    1、普通管理員/系統管理員等角色管理

    2、文件只讀權限/文件訪問權限等訪問控制

    3、進程/服務以所需最小用戶權限運行

    默認安全(Secure Defaults):

    默認安全配置在客戶熟悉安全配置選項之前不僅有利于更好的幫助用戶掌握安全配置經驗,同時也可以確保應用程序初始狀態下處于較安全狀態。

    縱深防御(Defense in Depth):

    縱深防御包含兩層含義:首先,要在各個不同層面、不同方面實施安全方案,避免出現疏漏,不同安全方案之間需要相互配合,構成一個整體;其次,要在正確的地方做正確的事情,即:在解決根本問題的地方實施針對性的安全方案。

    威脅建模(Threat Modeling):

    威脅建模是一種分析應用程序威脅的過程和方法。這里的威脅是指惡意用戶可能會試圖利用以破壞系統。

    工具安全

    下面就以visual studio工具進行展開,利用工具上的幾個配置進行提高軟件安全性。使用這些工具和做法并不會使應用程序免受攻擊,但能降低攻擊成功的可能性。

    1、代碼分析功能

    此編譯器選項將激活報告潛在安全問題(比如緩沖區溢出、未初始化的內存、null指針取消引用和內存泄漏)的代碼分析。此選項默認已關閉。建議開啟這個開關。

    2、/GS(緩沖區安全檢查)

    這個的安全檢查主要處理:函數調用的返回地址;函數的異常處理程序的地址;易受攻擊的函數參數。導致緩沖區溢出是黑客用來利用不強制實施緩沖區大小限制的代碼的技術。

    指示編譯器將溢出檢測代碼插入到面臨被利用風險的函數中。檢測到溢出時,則停止執行。默認情況下,此選項處于啟用狀態。

    傳遞到函數中的易受攻擊的參數。易受攻擊的參數是指針、C++ 引用、C 結構 (C++ POD 類型) 包含指針或 GS 緩沖區。

    3、/DYNAMICBASE(使用地址空間布局隨機化)

    使用 Windows 的地址空間布局隨機化 (ASLR) 功能,指定是否生成可在加載時隨機重新設定基址的可執行文件映像。

    通過使用此鏈接器選項,可以生成一個在執行開始時可在內存的不同位置加載的可執行映像。此選項還使內存中的堆棧位置更加不可預測。

    編碼安全

    當前軟件中都可能存在相同類別的內存安全漏洞,也可能存在于推理且無序的執行路徑中,包括但不限于緩沖區溢出、邊界外的數組訪問、未初始化的內存使用、類型混淆等漏洞。

    一個套規范的安全開發可以大大降低軟件漏洞的風險,安全開發通常需要我們在編碼過程中做到

    1、不要使用那些易受攻擊的API函數;

    2、要做好對輸入參數做校驗;

    3、慎重使用強制類型轉換;

    4、防止算術溢出和下溢;

    5、異常捕獲是定時炸彈;

    6、多用安全工具進行檢查代碼;

    7、文件操作過程中要做好路徑和權限管控。

    1、系統函數

    系統函數的使用可以大大降低代碼的開發工作量,但使用不安全的系統函數那就得不償失了。

    在開過過程中許多舊CRT函數具有持續更新、更安全的版本。如果存在安全函數,則較舊的、安全性更低的版本將標記為已棄用,并且新版本具有 _s(“安全”)后綴。

    安全函數不會阻止或更正安全錯誤。相反,它們會在發生錯誤時捕獲錯誤。它們對錯誤情況執行其他檢查。如果出現錯誤,則調用錯誤處理程序。

    上圖中函數strcpy 無法判斷正在復制的字符串對于目標緩沖區而言是否太大。其安全對應項 strcpy_s 會將緩沖區大小作為參數。因此,可以確定是否會發生緩沖區溢出。如果你使用 strcpy_s 將 11 個字符復制到 10 個字符緩沖區中,則這是你方造成的錯誤;strcpy_s 無法更正錯誤。

    2、SafeInt庫

    SafeInt它是可以與 MSVC、GCC或 Clang 結合使用的可移植庫,有助于防止在應用程序執行數學運算時可能會出現的整數溢出而被利用。SafeInt庫包括 SafeInt 類、SafeIntException 類和幾個SafeInt 函數。

    詳細的鏈接地址:

    https://github.com/dcleblanc/SafeInt

    SafeInt 類可防止整數溢出和被零除攻擊。可以通過使用它處理不同類型的值之間的比較。它提供了兩種錯誤處理策略。默認策略是針對引發 SafeInt 類異常的 SafeIntException 類,以報告無法完成數學運算的原因。第二個策略針對 SafeInt 類,用以停止程序的執行。還可以定義自定義策略。

    每個 SafeInt 函數各保護一個數學運算免于出現可被利用的錯誤。使用兩種不同的參數,而不必將它們轉換為相同類型。若要保護多個數學運算,請使用 SafeInt 類。

    3、信任邊界

    信任邊界存在于應用程序可能與信任度較低的上下文提供的數據進行交互的位置,例如系統上的另一個進程,或者內核模式設備驅動程序中的非管理用戶模式進程。

    4、類型轉換

    類型強制轉換使用盡可能用C++的風格static_cast<>,dynamic_cast<>,它允許允許更多編譯器檢查,并且更為顯式,相對更安全。

    5、接口應用

    無論是C還是C++的編程范式,從實用的角度,最終對面向接口編程,好的代碼接口具備下述特性:

    1、Self-describing,即自描述性,設計清晰簡潔的API接口名稱,一眼就能知道是什么功能。

    2、Clear hierarchy,即清晰的層級性,API的接口大類不能與小類相混淆。

    3、Granularity sex,即粒度性,掌控好粒度性的API接口,不能太過于粗糙,盡量細分化,容易后續的擴展。

    6、外部可控函數

    盡量減少使用外部可控數據作為啟動函數的參數例如:system、WinExec、ShellExecute、CreateProcess、execv、ececvp ,popen;如果外部可控作為這些函數的參數,就會有導致被注入的風險。如果確實需要使用這些函數,可以使用白名單機制驗證其參數,確保這些函數的參數不受到外來數據的命令注入影響。

    7、文件操作

    對文件操作的時候可以幾個降低安全風險

    1、當文件路徑來自外部數據時候,需要先將文件路徑規范化,這個沒處理攻擊者就會有機會通過惡意構造文件路徑進行文件的越權訪問。

    2、創建文件時候必須做好指定文件的訪問權限

    int open( const char * pathname, int flags);

    int open( const char * pathname, int flags, mode_t mode);

    盡可能使用第二個模式。

    小結

    以上知識的梳理更多從基礎理論出發,并且很多詳細細節還有待在后續實踐進行進一步的完善。

    軟件安全和二進制漏洞是一個永恒的對抗話題,基于一套安全的開發規范,指導在開發安全生命周期內進行推進軟件開發。并且加強開發中的安全意識的培養,又助于降低減少軟件的漏洞的出現。

    軟件安全sdl
    本作品采用《CC 協議》,轉載必須注明作者和本文鏈接
    安全性在軟件開發過程中是一個極其重要和深刻的話題。當安全性受到損害時,會發生非常糟糕的事情。我們在軟件開發生
    通過SDL實踐落地,藍網科技構建了完備的安全開發體系流程制度,架構師、開發人員、測試人員、安全運營人員安全意識和能力均得到全面提升,并建立起完善的事件響應機制,能應對不同級別的安全事件,產品安全漏洞也大幅減少。
    當下,軟件開發安全的理念很火,各行各業都已認識到保障應用系統開發安全的重要性,但是要真正實現起來,結果卻不是那么理想。
    一篇來自Security Week的文章,討論憑證泄漏導致的API漏洞不斷增長。最近的一項調查發現,超過一半的美國專業人士曾遭受過API漏洞,但77%人認為他們的組織有效地管理了API令牌。這聽起來有點矛盾,因為很多專業人士對他們的憑證管理很有信心,但還是會發生憑證相關的API漏洞情況。
    軟件供應鏈安全風險解析 隨著互聯網的迅猛發展,軟件供應鏈安全事件近年來頻繁發生。軟件供應鏈安全具有威脅對象種類多、極端隱蔽、涉及緯度廣、攻擊成本低回報高、檢測困難等特性。軟件供應鏈中的任意環節遭受攻擊,都會引起連鎖反應,甚至威脅到國家網絡安全。
    2021年5月12日,美國總統拜登簽署了“關于改善國家網絡安全(EO 14028)”的行政命令,其中第4節“加強軟件供應鏈安全”的(e)條款要求:初步指南發布90天內(不遲于2022年2月6日),NIST應發布加強軟件供應鏈安全實踐的指南,并明確了指南需包含的10余項具體內容(表3一二列)。
    SSDF的重點在于實現安全軟件開發實踐的結果,而沒有明確實現它們的工具、技術和機制。SSDF并不要求所有組織具有相同的安全目標和優先級,框架中的建議恰恰反映了軟件生產者可能的獨特安全預期和軟件使用者可能的獨特安全需求。表3 SSDF任務與行政令要求的對應關系
    由中國信通院指導、懸鏡安全主辦的中國首屆DevSecOps敏捷安全大會(DSO 2021)現場,《軟件供應鏈安全白皮書(2021)》正式發布。
    隨著容器、微服務等新技術日新月異,開源軟件成為業界主流形態,軟件行業快速發展。但同時,軟件供應鏈也越來越趨于復雜化和多樣化,軟件供應鏈安全風險不斷加劇,針對軟件供應鏈薄弱環節的網絡攻擊隨之增加,軟件供應鏈成為影響軟件安全的關鍵因素之一。近年來,全球針對軟件供應鏈的安全事件頻發,影響巨大,軟件供應鏈安全已然成為一個全球性問題。全面、高效地保障軟件供應鏈的安全對于我國軟件行業發展、數字化進程推進具有重
    隨著軟件技術的飛速發展和軟件開發技術的不斷進步,軟件開發和集成過程中常會應用第三方軟件產品或開源組件,其供應鏈中軟件的安全性和可靠性逐步成為軟件產業面臨的重要安全問題。近年來大量涌現的軟件供應鏈安全事件則具有不同的特點,攻擊軟件供應鏈相較于攻擊軟件本身,難度和成本顯著降低,影響范圍一般顯著擴大,并且由于攻擊發生后被供應鏈上的多次傳遞所掩蓋,難以被現有的計算機系統安全防范措施識別和處理。
    VSole
    網絡安全專家
      亚洲 欧美 自拍 唯美 另类