iT邦幫忙

2024 iThome 鐵人賽

DAY 28
1
Security

資安這條路:系統化學習網站安全與網站滲透測試系列 第 28

資安這條路:Day 28 SSDLC 安全開發軟體生命週期─開發階段與 OWASP 標準(OWASP Top 10、OWASP ASVS、OWASP Developer Guide)

  • 分享至 

  • xImage
  •  

前言

上一篇文章我們提到透過設計階段以威脅建模的方式列出常見的威脅,而下一階段則是開始實作與開發。
可以參考一些規範協助我們開發的過程,能開發出更安全的程式碼。

第三個階段:開發階段

  • 為了將設計階段的安全需求規格轉換為實際的程式碼,並確保開發出來的系統能夠抵擋常見的資安威脅。

開發階段要做什麼

這個階段需要開發者了解安全的開發原則,並參考常見的資安威脅,避免開發出來的系統容易被攻擊。

  • 開發者需要了解安全開發原則:
    • 了解如何保護敏感資訊,例如個人資訊 (PII)、銀行帳戶資訊、健康記錄等
    • 學習如何確保業務持續,避免系統故障或漏洞導致核心系統中斷
    • 熟悉如何防範法律風險,例如遵守資料保護和隱私的法律要求
    • 了解如何增加民眾信任,提供安全的系統以增強民眾對組織的信任和忠誠度
    • 學習如何對抗網路威脅,實施持續的安全更新和漏洞管理
  • 開發者需要參考常見的資安威脅:
    • 了解常見的攻擊手法,例如 SQL 注入、跨站腳本攻擊 (XSS) 等
    • 熟悉常見的漏洞類型,例如緩衝區溢位、跨站請求偽造 (CSRF) 等
    • 學習如何避免這些安全威脅,例如進行輸入驗證、輸出編碼等

開發階段的目標是什麼

  • 減少漏洞的發生: 透過安全的開發原則和參考常見的資安威脅,可以減少系統的漏洞數量
  • 提高系統的抵抗力: 安全的系統能夠更好地抵擋惡意攻擊,降低資料外洩、系統中斷等風險
  • 降低維運成本: 安全的系統可以減少安全事件的發生,降低後續維運的成本。

開發階段完成後,就可以進入測試階段,確保開發出來的系統沒有問題,並且可以抵擋攻擊。

開發階段的實際做法

除了瞭解安全開發原則和參考常見資安威脅外,開發階段還需要做到以下幾點:

  1. 挑選安全的程式語言和框架
    • 選用內建安全功能的語言,如 C#、Java、Python 等
    • 這些語言通常提供現成的加密、驗證等功能,讓開發更安全方便
  2. 撰寫安全程式碼
    • 遵循安全的程式碼規範
    • 使用安全的函式庫和 API
    • 避免常見程式碼漏洞
  3. 做好版本控制
    • 用版控系統追蹤程式碼變更
    • 限制只有授權人員可存取程式碼
    • 方便回復到先前版本,以應對安全問題
  4. 設定安全預設值
    • 確保系統預設是安全的,如強制密碼和停用不必要服務
    • 避免使用容易被猜到的預設密碼
    • 提醒使用者初次使用時更改預設設定
  5. 縮小攻擊面
    • 關閉或移除不需要的功能、埠口和服務
    • 減少系統可能被攻擊的點
    • 降低整體被攻擊風險
  6. 進行程式碼審查
    • 請其他開發者或資安專家審視程式碼
    • 及早找出並修復潛在安全漏洞
    • 避免漏洞被駭客利用
  7. 執行整合測試
    • 在整合不同模組時進行測試
    • 確保各元件能安全互動
    • 及早發現並解決相容性問題
  8. 進行資安測試
    • 在開發過程中持續做資安測試
    • 找出並修補安全漏洞
    • 驗證系統的安全控制是否有效

如何執行開發階段任務

開發階段主要是將設計轉為程式碼,並確保符合資安標準。

  • 具體步驟
    1. 程式碼導覽
      • 資安團隊與開發人員和系統架構師一起審視程式碼
      • 開發人員說明程式碼邏輯和流程
      • 審查團隊對程式碼有整體認識
      • 目的是瞭解程式碼架構,不是深入檢查資安問題
    2. 程式碼審查
      • 測試人員檢查程式碼是否有資安缺陷
      • 根據以下清單進行靜態程式碼審查:
        • 業務需求:可用性、機密性和完整性
        • OWASP 指南或十大清單:檢查常見技術漏洞
        • 語言或框架特定問題:如 PHP 的 Scarlet、ASP.NET 的微軟安全程式碼清單
        • 產業特定需求:如 Sarbanes-Oxley 404、COPPA、ISO 27002 等
      • 靜態程式碼審查投資報酬率高,不太依賴審查者技能
  • 其他注意事項
    • 許多設計決策是在寫程式時做出的
    • 要有足夠的政策、標準和文件來指導開發人員

OWASP Top Ten

背景與意義

OWASP Top Ten 是由開放網路應用程式安全計劃(OWASP)發布的重要文件,
自2003年首次發布以來,已成為網路應用程式安全領域最具影響力的指南之一。
這份文件識別並排序了當前最關鍵的網路應用程式安全風險,為開發者、安全專業人員和組織提供了重要參考。

OWASP Top Ten 的重要性

  • 提供清晰的安全優先順序
  • 幫助組織聚焦最重要的安全問題
  • 為安全培訓和意識提升提供基礎
  • 成為許多安全標準和法規的參考基礎

演變歷程

OWASP Top Ten 並非靜態文件,而是隨著技術發展和威脅形勢變化不斷更新:

  • 2003年: 首次發布
  • 2004年、2007年、2010年、2013年、2017年: 進行多次更新
  • 2021年: 最新版本發布,引入新的風險類別

每次更新都反映了網路應用程式安全領域的最新趨勢和挑戰。

2021版 OWASP Top Ten

A01: 存取控制失效 (Broken Access Control)

  • 定義: 應用程式無法正確限制未經授權的使用者存取受保護資源。
  • 影響: 可能導致資訊洩漏、未經授權的功能存取,甚至系統完全被接管。
  • 預防措施:
    • 實施最小權限原則
    • 集中化存取控制機制
    • 定期審核存取權限
    • 強制執行適當的會話管理

A02: 加密機制失效 (Cryptographic Failures)

  • 定義: 敏感資料在存儲或傳輸過程中未得到適當的加密保護。
  • 影響: 可能導致敏感資訊洩漏,包括個人身份資訊、金融資料等。
  • 預防措施:
    • 使用強大的加密演算法
    • 安全地管理加密金鑰
    • 確保所有敏感資料在傳輸和存儲時都經過加密
    • 定期更新加密協議以應對新的威脅

A03: 注入式攻擊 (Injection)

  • 定義: 不受信任的資料被作為命令或查詢的一部分發送到解釋器。
  • 影響: 可能導致資料損壞、資料洩漏,甚至遠端程式碼執行。
  • 預防措施:
    • 使用參數化查詢
    • 實施輸入驗證和淨化
    • 使用安全的 API
    • 限制特殊字元的使用

A04: 不安全的設計 (Insecure Design)

  • 定義: 在軟體開發生命週期的早期階段未能考慮安全性。
  • 影響: 可能導致系統級的安全漏洞,難以通過簡單的程式碼修復解決。
  • 預防措施:
    • 在設計階段進行威脅建模
    • 使用安全設計模式和最佳實踐
    • 實施安全開發生命週期(S-SDLC)
    • 定期進行安全架構審查

A05: 安全組態錯誤 (Security Misconfiguration)

  • 定義: 系統、框架、資料庫等組件的安全設置不當或使用了不安全的預設設置。
  • 影響: 可能為攻擊者提供未經授權的系統存取或敏感資訊的洩漏。
  • 預防措施:
    • 使用安全的預設配置
    • 實施最小化原則,只啟用必要的功能
    • 定期進行安全配置審核
    • 自動化配置和補丁管理流程

A06: 易受攻擊和過時的元件 (Vulnerable and Outdated Components)

  • 定義: 使用具有已知漏洞的元件或未及時更新的軟體版本。
  • 影響: 可能使應用程式易受已公開的攻擊,導致各種安全問題。
  • 預防措施:
    • 定期掃描和更新依賴項
    • 實施軟體組成分析(SCA)
    • 訂閱相關安全公告
    • 制定快速回應和補丁策略

A07: 身分認證和驗證失效 (Identification and Authentication Failures)

  • 定義: 應用程式無法正確保護使用者憑證和會話標識。
  • 影響: 可能導致身分冒用、未經授權的存取和資料洩漏。
  • 預防措施:
    • 實施多因素身分驗證
    • 使用強密碼策略
    • 實施安全的會話管理
    • 防止暴力破解攻擊

A08: 軟體和資料完整性失效 (Software and Data Integrity Failures)

  • 定義: 軟體更新、關鍵資料和CI/CD流程缺乏完整性驗證。
  • 影響: 可能導致未經授權的軟體更新、惡意程式碼注入或資料竄改。
  • 預防措施:
    • 使用數位簽章驗證軟體更新
    • 確保CI/CD流程的安全性
    • 監控第三方資料庫和套件的完整性
    • 實施完整性檢查機制

A09: 安全記錄和監控失效 (Security Logging and Monitoring Failures)

  • 定義: 系統無法或不足以記錄、檢測、分析和警告潛在的惡意活動。
  • 影響: 可能導致安全事件的延遲檢測,增加攻擊的持續時間和影響。
  • 預防措施:
    • 實施集中化的日誌管理系統
    • 確保記錄敏感操作和安全事件
    • 使用自動化工具進行日誌分析和警報
    • 制定和測試事件回應計劃

A10: 伺服器端請求偽造 (Server-Side Request Forgery, SSRF)

  • 定義: Web 應用程式從遠端獲取資源而未驗證使用者提供的 URL。
  • 影響: 可能導致內部服務暴露、資料洩漏或遠端程式碼執行。
  • 預防措施:
    • 實施對使用者提供 URL 的嚴格驗證
    • 使用允許列表而非阻止列表來過濾 URL
    • 禁止 HTTP 重定向
    • 實施網路分段和存取控制

實施建議

為有效應對這些風險,組織應該:

  • 將 OWASP Top Ten 納入安全策略和開發流程
  • 定期進行安全評估和滲透測試
  • 為開發團隊提供持續的安全培訓
  • 實施自動化安全掃描工具
  • 建立安全事件回應計劃
  • 與資安社群保持聯繫,及時了解新興威脅

如何在開發階段整合規範:以 OWASP Top 10 作為標準

雖然 OWASP Top 10 主要用於提升資安意識和認知,
但許多企業仍將其作為應用程式安全標準。

但是,使用 OWASP Top 10 作為標準時,
必須了解它只是最低限度的指標,僅作為起點。

OWASP Top 10 的局限性

  • 難以測試
    • OWASP Top 10 列出的是應用程式安全風險,但並非所有風險都容易測試
    • 例如,「A04:2021-不安全的設計」難以透過測試來驗證
  • 無法涵蓋所有安全規範
    • OWASP Top 10 並非完整的安全規範
    • 不應期望它涵蓋所有安全需求。

如何在開發階段整合 OWASP Top 10

  • 教育訓練
    • OWASP Top 10 可作為開發人員安全意識培訓的基礎教材
  • 程式碼審查和程式碼審閱
    • 在程式碼審查和程式碼審閱階段,可以使用 OWASP Top 10 作為檢查清單,找出程式碼中潛在的安全漏洞
    • 審查時可參考 OWASP Top 10 中列出的風險,例如注入攻擊、失效的身份驗證和損壞的存取控制
  • 安全測試
    • 在安全測試階段,可以參考 OWASP Top 10 設計測試案例,驗證系統是否能抵禦常見的攻擊

OWASP ASVS 的優勢

  • 可測試性和可驗證性
    • OWASP 應用安全驗證標準 (ASVS) 專為可測試和可驗證而設計。
  • 涵蓋整個 SDLC
    • ASVS 可應用於安全軟體開發生命週期的所有階段

建議

  • 使用 OWASP ASVS 作為應用程式安全標準
    • 因為它比 OWASP Top 10 更全面且易於測試

如何有效學習 OWASP Top 10

從概念理解到實際應用,再到問題分析和解決方案,
形成一個完整的學習循環的方法如下:

  1. 先了解該對應的基本概念
    • 用自己的話解釋什麼是OOOO(弱點名稱)
    • 嘗試自己列舉日常生活中關於OOOO(弱點名稱)的例子
    • OOOO(弱點名稱)在資訊安全扮演什麼角色
    • 為什麼OOOO(弱點名稱)對於資訊系統很重要
  2. 何謂常見的漏洞
    • 列出五種常見的漏洞種類或範例
    • 針對每一種的漏洞撰寫對應的情境與場景
    • 這些漏洞可能會導致什麼樣的資安問題
    • 有哪些因素可能導致這些漏洞的出現
  3. 不安全的程式碼範例
    • CWE 資料庫如何撰寫對應的漏洞範例
    • 對於自己使用的程式語言、框架的是否有範例
    • 這些漏洞如何被惡意使用者利用
  4. 程式碼的安全問題分析
    • 對每個問題,解釋為什麼他是漏洞
    • 導致什麼影響
    • 如果你是駭客,你會如何利用這些漏洞
  5. 如何寫出改善的程式碼
    • 修改程式碼,找到常見的解決方法
    • 整理措施來改善這個弱點
    • 還有哪些其他的安全措施可以考慮實施
  6. 反思與總結
    • 總結你學到的主要概念和技巧
    • 思考在實際專案中如何應用這些知識

OWASP ASVS

介紹

  • ASVS 是 OWASP 的旗艦專案之一
  • 全名為 Application Security Verification Standard
  • 用於指導 Web 應用程式的安全驗證過程

目的

  • 設定 Web 應用程式安全驗證的覆蓋範圍和嚴謹程度
  • 提供測試技術安全控制的基礎,以保護應用程式免受漏洞影響

歷史

  • 最早版本於 2008 年發布
  • 持續得到社群支持和更新

ASVS 驗證等級

ASVS 定義了三個安全驗證等級:

  • 等級 1: 低保證等級應用程式,完全可滲透測試
  • 等級 2: 包含敏感資料需要保護的應用程式,大多數應用程式的推薦等級
  • 等級 3: 最關鍵的應用程式,需要最高信任等級

ASVS 主要章節

ASVS 分為 14 個主要章節

  • V1.1 安全軟體開發生命週期:確認使用涵蓋所有開發階段安全性的安全軟體開發生命週期
  • V1.2 認證架構:確認應用程式中使用的認證機制安全可靠
  • V1.3 工作階段管理架構:確認應用程式中使用的的工作階段管理機制安全可靠
  • V1.4 存取控制架構:確認應用程式中使用的存取控制機制安全可靠
  • V1.5 輸入和輸出架構:確認應用程式處理輸入和輸出資料的方式安全可靠
  • V1.6 加密架構:確認應用程式中使用的加密機制安全可靠
  • V1.7 錯誤、日誌記錄和審計架構:確認應用程式錯誤處理、日誌記錄和審計機制安全可靠
  • V1.8 資料保護和隱私架構:確認應用程式中使用的資料保護和隱私機制安全可靠
  • V1.9 通訊架構:確認應用程式中使用的通訊機制安全可靠
  • V1.10 惡意軟體架構:確認應用程式中使用的惡意軟體防護機制安全可靠
  • V1.11 業務邏輯架構:確認應用程式中使用的業務邏輯機制安全可靠
  • V1.12 文件和資源架構:確認應用程式中使用的文件和資源管理機制安全可靠
  • V1.13 API 和 Web 服務架構:確認應用程式中使用的 API 和 Web 服務機制安全可靠
  • V1.14 設定架構:確認應用程式中使用的設定管理機制安全可靠

ASVS 驗證要求

  • 最新版本 (4.0.3) 包含 286 項驗證要求
  • 這些要求由廣泛的資安社群建立和同意

ASVS 適用場景

  • 作為 Web 應用程式安全驗證的基礎
  • 指導開發人員建立滿足應用安全要求的安全控制
  • 用於確定驗證過程中應包含的要求類別

ASVS 使用方法

  • 選擇適當的驗證等級 (1、2 或 3)
  • 將 ASVS 作為指南,而不是試圖實施每一個可能的控制
  • 使用如 SecurityRAT 等工具建立更易管理的 ASVS 要求子集
  • 參考 OWASP Cheat Sheets 作為文件,幫助決定是否將某個要求類別納入驗證

使用建議

  • 大多數應用程式應針對等級 2
  • 僅有進行高價值交易或包含敏感醫療數據的應用程式才需要等級 3

ASVS 的優勢

  1. 全面性
    • 涵蓋 Web 應用程式安全的各個方面
    • 提供詳細的驗證要求清單
  2. 社群支持
    • 由廣泛的資安社群共同建立和維護
    • 持續更新以應對新興的安全威脅
  3. 靈活性
    • 提供不同的驗證等級,適用於不同安全需求的應用程式
    • 可根據具體需求選擇性使用
  4. 實用性
    • 提供具體的驗證要求,便於實施和檢查
    • 與 OWASP Cheat Sheets 等資源相結合,提供實用指用

使用

簡介

  1. 指南概述
    • 介紹安全概念
    • 為應用程式和系統開發者提供參考
    • 不深入特定主題,而是提供相關連結
    • 內容力求易懂,介紹實用安全概念
    • 提供足夠細節讓開發者上手OWASP工具和文件
  2. 目標讀者
    • 各領域的應用程式開發者
      • 網頁
      • 桌面
      • 移動
      • API
      • 雲端
  3. 歷史
    • 與OWASP Top Ten同為OWASP最早的資源之一
    • 2001年OWASP成立後不久發布
    • 2002年發布1.0版
    • 2005年發布2.0版
    • 2023-2024年經過討論和迭代,更新以適應現代安全環境
  4. 版本管理
    • 定期將草稿版標記並發布到正式區域
    • 草稿版為進行中的工作,可能有大規模和頻繁的變動

總結

在本篇文章中,我們將深入探討安全軟體開發的第三個階段——開發階段。我們將介紹開發者在此階段應該如何了解並應用安全開發原則,避免常見的資安威脅。同時,我們詳細說明了如何在開發過程中整合 OWASP Top 10 和 ASVS 等安全標準,確保開發出的系統能夠抵禦各種攻擊,提升系統的安全性和可靠性。

小試身手

  1. 在軟體開發的開發階段,以下哪一項不是開發者需要執行的任務?

    A. 了解安全開發原則
    B. 參考常見的資安威脅
    C. 進行威脅建模
    D. 撰寫安全的程式碼

    答案: C

    解析: 威脅建模通常在設計階段進行,而開發階段的重點在於實際撰寫安全的程式碼,並應用安全開發原則和參考資安威脅。

  2. 以下哪一項是 OWASP Top Ten 2021 中列為第一位的安全風險?

    A. 不安全的設計 (Insecure Design)
    B. 注入式攻擊 (Injection)
    C. 存取控制失效 (Broken Access Control)
    D. 安全組態錯誤 (Security Misconfiguration)

    答案: C

    解析: 在 OWASP Top Ten 2021 中,A01 為「存取控制失效 (Broken Access Control)」,被列為最嚴重的安全風險。

  3. 為了縮小系統的攻擊面,下列哪一項是適當的做法?

    A. 啟用所有功能以提升使用者體驗
    B. 關閉或移除不必要的功能、埠口和服務
    C. 使用預設的管理員密碼
    D. 開放所有網路埠口供外部存取

    答案: B

    解析: 縮小攻擊面應該關閉或移除不必要的功能和服務,以減少被攻擊的可能性。

  4. 以下關於 OWASP ASVS 的描述,哪一項是不正確的?

    A. 提供全面的安全驗證要求
    B. 適用於不同安全需求的應用程式
    C. 僅適用於高安全需求的關鍵應用程式
    D. 由資安社群共同建立和維護

    答案: C

    解析: OWASP ASVS 提供不同的驗證等級,適用於各種安全需求的應用程式,不僅僅是高安全需求的應用。

  5. 在開發階段整合 OWASP Top 10 時,以下哪一項是建議的最佳實踐?

    A. 將 OWASP Top 10 作為開發人員安全培訓的教材
    B. 將 OWASP Top 10 作為唯一的安全標準
    C. 忽略 OWASP Top 10 的局限性
    D. 只在開發完成後再考慮 OWASP Top 10

    答案: A

    解析: OWASP Top 10 可用於提升開發人員的安全意識,但不應該被視為唯一的安全標準,應結合其他資安規範。


上一篇
資安這條路:Day 27 SSDLC 安全開發軟體生命週期─設計階段與威脅建模
下一篇
資安這條路:Day 29 SSDLC 安全開發軟體生命週期─測試階段與 OWASP Web Security Testing Guide
系列文
資安這條路:系統化學習網站安全與網站滲透測試30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言