第一部分 第四章 代碼審計
- 代碼審核在接觸點體系中的位置是什么?
最重要的部分 - 代碼審核的作用是什么?有什么優劣勢?
在程序發布前發現安全弱點。
能盡早發現程序的脆弱性。 - 如何進行代碼審核?
代碼審核過程主要是采用源代碼靜態分析工具隊程序進行分析并輸出報告;審核人員對報告進行甄別和過濾,踢出誤報(假陽性),并確認所發現的安全缺陷。 - 工具在代碼審核中發揮什么作用?有什么局限性
代碼掃描工具的定位:計算機輔助人工代碼審核。可以代替人工記住所有過濾規則,更快的對代碼進行審核。
局限性:較高的誤報率和漏報率,需要人工隊審核結果進行檢查,同時規則也需要人工維護。
第一部分 第五章 軟件滲透測試
什么是(軟件)滲透測試?
一種針對制定計算機系統,在有合法授法的前提下,模擬黑客進行的漏洞攻擊比較:漏洞評估 vs 滲透測試
漏洞評估:檢查系統或服務是否存在潛在安全問題
滲透測試:模擬黑客,并提供攻擊載荷,因此比漏洞評 估更進一步。比較:軟件滲透測試 vs 滲透測試
軟件滲透測試:針對單一軟件或軟件系統進行滲透測試
滲透測試:針對任何信息設備或系統,包括硬件、大型 信息系統等如何做滲透測試?
偵察-->掃描-->滲透-->駐留-->報告滲透測試常用工具及作用?
HTTrack:獲得授權進行測試的ip主機列表
Ping,nmap:端口掃描,得到目標系統開放的端口號及其開放的服務
Nuesse:漏洞掃描,根據開放的端口號和服務掃描可能存在的漏洞
John the Ripper(JtR):密碼破解工具
Metasploit:漏洞攻擊
Wireshark:流量嗅探
netcat:駐留回連
netbus:遠控肉雞-
web服務器掃描工具:Nikto2,Websecurity(為測試者提供交互頁面,快速便捷地對web漏洞進行掃描,包括SQl注入、跨站腳本、文件包含、跨站請求偽造等)
- 漏洞利用(Exploitation):測試者通過目標系統漏洞, 繞過系統防護機制,獲取系統控制權限。
- 漏洞利用程序,漏洞攻擊程序(Exploit):預先打包發 送到目標系統中的代碼集,引發異常行為,以使我們能夠執行攻擊載荷。
- 攻擊載荷(Payload):一段代碼,用于完成安裝新軟件、 創建新用戶、開啟后門等任務。
-
示例: 創建一個濫用案例(Cigital提供)
一個處理敏感財務數據庫的C/S應用程序- 服務器端依靠客戶端管理所有的數據訪問許可
- 服務器端不再檢查用戶的真實證書,就直接授權
- 客戶端存儲有敏感數據庫的一份完整的拷貝
- 客戶端程序運行在普通PC上
濫用案例 - 根據“偽裝客戶端(make the client invisible)”攻擊模式
- 通過嗅探網絡數據流構建一個惡意客戶端
- 通過該惡意客戶端與服務器端通信,騙取服務器授權,幫助惡意用戶成功讀取服務器數據庫中信息
5.1 安全風險分析方法中的共同主題
- 分析對象(深入了解待分析的軟件對象)
- 閱讀和理解規范、體系結構文檔及其他設計材料
- 進行討論和頭腦風暴
- 確定系統便捷和數據敏感度/重要程度
- 實際使用軟件
- 研究代碼和其他的軟件工作(包括代碼分析工具)
- 分析環境(討論圍繞軟件對象的安全問題)
- 對軟件的運行情況展開討論,確定有異議或含糊的地方
- 識別可能的安全弱點,可借助工具和常見弱點列表
- 給出安全弱點利用程序(POC),并討論可能的修補方法 - 理解當前的和規劃的安全控制(留意它們可能引入的新風險)
- 識別危害(確定被入侵的概率)
- 制定利用安全缺點攻擊的腳本
- 綜合平衡與防御能力,確定入侵的可能性
- 分析影響(分析風險影響)
- 確定風險對資產及商業目標的影響
- 考慮風險對安全狀態(posture)的影響
- 風險評級
- 降低風險(制定消除風險的策略)
- 推薦一些可以消除風險的應對措施(countermeasure)
- 形成報告(報告風險分析的結果)
- 依據影響大小,仔細說明主要和次要風險
- 提供一些基本信息,說明如何使用消除風險的有效資源
第一部分 第九章 軟件安全的萬全之策
軟件構建與安全接觸點
- 需求(濫用案例)
- 濫用案例是對軟件的故意無用,并研究由此導致的后果
- 濫用案例的作用:引導編制軟件的安全需求以及相應的安全測試計劃
- 設計(商業風險分析)
- 安全分析必須與商業風險聯系起來才有價值
- 軟件構建的背后的決策者是軟件風險咨詢的key man/key woman
- 必須用商業決策者能夠明白的語言來表述安全風險
- 設計(體系結構風險分析)
- 體系結構風險分析首先要面對商業人員和決策者,運用他們能夠理解的術語來描述風險
- 然后針對軟件系統總體設計、子系統及模塊設計內容,分析安全風險,并形成軟件體系結構安全狀態的總提示圖(“森林級視圖”)
- 安全測試
- 體系結構風險分析評測軟件設計方案中的技術安全問題,并與商業影響聯系起來
- 重點發現系統級獲組件及設計瑕疵
- 在體系結構風險分析的結果指導下,形成兩類測試計劃:功能安全測試計劃、對抗性測試計劃
- 代碼審核
- 代碼審核時發現實現級缺陷的有效方法
- 審核人員應用豐富的編程開發經驗
- 靜態分析工具對發現易出安全問題的脆弱點十分有用
- 滲透測試
- 關注點:軟件配置和部署中的認為錯誤或過程錯誤
- 好的滲透測試是由先前識別出的風險驅動,并設計成直接探測這些風險,以確認可滲透的程度
- 網絡滲透測試 vs 應用程序滲透測試:前者由外而內,后者應利用其它接觸點結果,實現內外結合的高效
- 實際應用(部署和操作)
- 仔細配置軟件并部署在安全防護環境中,將有效增強軟件及系統的安全性
- 運行中針對威脅時間進行安全操作及應急響應,并將累積的安全風險與威脅知識運用到新的軟件構造過程中
SDCL + BSI --> SDL
幾個術語
- COTS 商業現貨軟件
- MSA(Master Service Agreement) 主要服務合同
- SoW (Statement of Work) 工作說明
- SLA (Service Level Agreement) 服務水平合同
- QoS 服務質量
編碼錯誤分類:
- 輸入確認和表示
- 由元字符、交替出現的編碼和數字表示引起的。應使用白名單進行輸入確認。輕信輸入導致的問題包括:緩沖區溢出、SQL注入、緩存中毒(Cache Poisoning) 等 。
- API濫用
- API是調用者與被調用者之間的一種契約。API調用者未能遵守契約。例如:沒有在調用chroot()之后調用chdir()。
- 安全特性
- 軟件安全不等于具有安全性的軟件。例如:用SSL保護數據
- 時間與狀態
- 在分布式計算環境中,為讓多個組件互相通信,就需要共享狀態。用傳統的程/序執行模型描述并行化執行操作,就容易產生與線程、過程、時間和信息之間的意外交互相關的錯誤。
- 錯誤處理
- 現代程系統異常處理機制在一程度上與使用goto語句相似。錯誤和錯誤處理程序是一類編程契約。
- 代碼質量
- 安全性是可靠性的子集。
- 封裝
- 封裝是在事物之間劃清界線并在其間設置屏障。
- *_環境
- 環境包含位于你的代碼之外,但對軟件的安全至關重要的所有事物。應跳到軟件之外,從外向內看。
判斷對錯:
- 我的系統安裝了殺病毒軟件、防火墻、IDS(入侵 檢測系統) 等產品,因此是安全的。
即使安裝了網絡安全防護產品,但如果所防護的軟件(比如瀏覽器)存在漏洞或后門,攻擊者仍然可以通過瀏覽器穿透防護而入侵系統。如果軟件自身存在安全缺陷,就存在穿透外圍的網絡安全防護的風險,系統就不是安全的。
- 微軟的Windows10是最安全的Windows操作系統。 我的電腦預裝win10,因此我的系統就安全了。
預裝系統如果沒有及時升級和修補漏洞,就無法保證是安全的。軟件的隨時在線升級和模塊(插件)動態裝在,使軟件動態化。安全也必須是動態安全。
- 我的系統中采用最好的加密算法,難以破解。因此是安全的。
雖然采用最好地加密算法,但如果在編程實現上存在缺陷,系統也是不安全的。只有(算法)涉及和開發實現都是安全的,才能確保最終安全。
- 我的系統采用了可信計算體系,因此是安全的。
可信計算依靠環環相扣的信任鏈,如果其中的軟件存在安全缺陷,就有可能被攻擊者利用來騙取信任。 只有(算法)涉及和開發實現都是安全的,才能確保最終安全。
- 我的系統是自己開發的,因此是安全的。
系統雖然是自己開發的,但難免調用第三方構建庫;或者沒有遵循安全的開發過程,都可能導致系統存在安全隱患。
當今商業軟件的開發依賴于全球供應鏈,開發過程需要有一套行之有效的安全保障方法。
- 網絡攻防就是黑客的那些事兒。
當今的網絡入侵事件既有腳本小子的搗鼓,也有國家級高水平、有組織的體系化網絡攻擊。
網絡戰已悄然打響。
- 什么是軟件安全?
軟件安全是網絡空間安全的重要部分,主要研究軟件自身的安全問題 、防護及評估技術,以及軟件安全的工程化保障方法