安全程式碼撰寫課程重點

# 安全程式碼撰寫課程重點 ## Part 1 軟體安全開發總論 ### Information Security 1. **AAA+NR** * authentication（認證） * Authorization（授權） * Accounting（可歸責性） * Non-Repudiation（不可否認） 2. **多因子認證（Multi-factor aunthentication）** * Somthing you know * Somthing you have * Somthing you are 3. **STRIDE** * **Spoofing 詐騙** * 指某個人或程序通過偽造數據成功識別出另一個人或程序，從而獲得非法利益的情況 * **Tempering 竄改** * 主要是**改變資料**，對資料造成汙染 * 篡改可以指多種形式的破壞活動，但該術語通常用於表示以故意修改產品的方式，使其對消費者產生有害影響。 * 與刑法有關 * **Repudiation 否認** * 攻擊者隱匿蹤跡，使追查者無法歸咎於肇事者 * **Information Disclosure 資訊洩漏** * 洩漏隱私數據(ex：信用卡號、密碼等等...) * **Denial of Service 服務阻斷(DOS)** * 讓資源耗竭(ex：向目標機器或資源中註入多餘的請求來實現，使系統超載並阻止某些或所有合法請求得到滿足) * 可針對Internet、處理器效能、磁碟空間做攻擊 * ==**DOS相當容易匿名發動**，難以判斷是否為惡意攻擊== * **Elevation of Privilege 權限提高** * 特權升級意味著用戶獲得他們無權獲得的特權 * ***Vertical privilege escalation(垂直特權升級)***，也稱為特權提升，其中較低特權用戶或應用程序訪問為較高特權用戶或應用程序保留的功能或內容（例如，網上銀行用戶可以訪問站點管理功能，或者可以繞過智能手機的密碼。） * **Horizontal privilege escalation(水平特權升級)**，其中普通用戶訪問為其他普通用戶保留的功能或內容（例如，網上銀行用戶A訪問用戶B的互聯網銀行帳戶） ## Part 2 風險管理概述 ### OWASP Risk Rating Methodology > 風險利用弱點對資產造成影響的機率 * Risk(風險)=Likelihood(機率)*Impact(影響) 1. 識別風險 2. 估計可能性的因素 * 一旦測試人員確定了潛在風險並想弄清其嚴重程度，第一步就是估計“可能性”。在最高級別上，這是對攻擊者發現和利用此特定漏洞的可能性的粗略度量。在此估算中不必過於精確。通常，識別可能性是低，中還是高就足夠了。 3. 估算影響的因素 * 考慮成功攻擊的影響時，重要的是要意識到有兩種影響。首先是對應用程序，其使用的數據及其提供的功能的==技術影響==。另一個是對運行應用程序的企業和公司的==業務影響==。 4. 確定風險的嚴重程度 5. 決定修復什麼 * 在對應用程序的風險進行分類之後，將有一個優先解決問題的列表。通常，應首先確定最嚴重的風險。 6. 自定義風險評級模型 * 漏洞(弱點)產生之時機 * 超過八成的問題是在開發階段產生的 * 部分弱點問題會再測試階段發現 * 修改成本隨著時間指數成長 ## Part 3 安全程式設計原則 ### Security by Design Principles according to OWASP 1. **Minimize attack surface area(減少攻擊層面)** * 程序員每次向其應用程序添加功能時，都會增加安全漏洞的風險。 * ==最小化攻擊表面積==的原則限制了允許用戶訪問的功能，以減少潛在的漏洞。 * ex：在app裡加入了網路檢索功能，增加了SQL指令注入的風險，以限制會員使用的方式來最小化攻擊表面積 2. **Establish secure defaults(建立安全機制)** * 輸入資料驗證應於==可信任之系統邊界==內執行(限制活動範圍) * 於加密通道中傳輸Cookie資訊時，應設定==Secure屬性==(只允許Https連線，強迫 Cookie 在傳輸時使用 SSL 加密機制) * 設定Cookie的==HttpOnly屬性==(指示Cookie只供瀏覽器與WebServer之間之網頁溝通使用，避免用戶端以JavaScript存取Cookie) 3. **Least privilege(最小權限)** * 使用最小權限做事就好，可完成任務即可，不需要過多權限 * 關閉系統中預設管理者權限，包含Admin、Root等預設帳號 * 一般使用者存取資料庫時，只允許存取對應的資料表權限即可 4. **Defense in depth(縱深防禦)** * 乳酪理論(多層防護) * 避免被單點突破 5. **Fail securely(安全機制)** * ==以安全的方式失敗(需特別定義)== 6. **Don't trust services(不信任的服務)** * 若使用第三方服務，應不要信任，且須檢視有無惡意程式碼存在 * 存取受管控檔案時，應以==代碼==(加解密技術、雜湊技術、簽章)傳遞參數，並進行==存取控制==(白名單機制、憑證綁定) * ==為確保流程的順序性，應於可信任之系統內進行流程控制== 7. **Separation of duties(權責分離)** * 不管在==商業邏輯==或==系統邏輯==，都應做到權責分離 8. **Avoid security by obscurity(避免安全隱患)** * 定期檢測第三方套件(Open Source) * 敏感性資訊避免Hardcode於程式碼或文檔中 * Database密碼處理 1. 使用==Salted Password Hashing==，降低遭RainbowTable破解的機率 2. 使用單向雜湊(SHA-256) 9. **Keep security simple(保持簡單)** * Error = (More Code)平方 10. **Fix security issue correctly(正確解決安全議題)** ## Part 4 弱點掃描原理與工具說明 * **靜態檢測分析(Static Application Security Testing)** * 又稱==白箱測試== * 分析程式碼可能的所有執行路徑，找出其中的風險(Data Flow => Control Flow => Tainted Analysis) * 會有==誤報(False Posistive)(假陽性)==，需確認檢測結果 * **動態檢測分析(Dynamic Application Security Testing)** * 又稱==黑箱測試== * 操作系統所有畫面、所有欄位，針對輸入欄位進行攻擊(比對HTTP Request和HTTP Response，判斷攻擊成敗) * 錄製腳本 * 會有==漏報(False Negative)(假陰性)==;對系統效能會造成影響;會將資料寫入資料庫(需備份) * **主機弱點檢測(Host-based Vulnerability Assessment)** * 又稱主機檢測、弱點評估 * ==屬於動態分析的一種方式==，掃描網路設備中各種網路設備與系統主機，檢測是否存在已知的弱點 * 送出各種類型之網路封包或攻擊指令，以測試目標系統之回應 * **開放原始碼安全檢測(Open Source Security)** * 是一套針對Open Source元件管理工作 > 只能將風險降低 > 安全測試只能證明系統已存在弱點 > 軟體是死的，駭客是活的 > 工具無法精準的對系統「邏輯思想」進行測試 * **白帽測試(Penetration)** * 模擬駭客的行為進行攻擊 ## Part 5 常見網路應用弱點簡介 * **OWASP Top 10 2021 proposal** * **A1. Injection注入攻擊** * 輸入不可信任的資料作為命令或查詢語句的一部分 * 建議使用**Store Procedure**(預存程序)來做資料存取 * **A2. Broken Authentication無效身分認證** * 身分認證和Session管理相關的應用程式以不正確的方式執行，導致攻擊者可以破壞密碼、密鑰、Session Token或攻擊其他漏洞去冒充其他用戶的身分 * 情境：暴力破解攻擊、憑證填充攻擊、Session ID暴露於URL中 * 防範方式： * 認證錯誤時，不指名是帳號或密碼錯誤 * 使用Multi-factor Authentication(多因子認證) * 使用圖形辨識 * 設計好密碼重設流程 * Cookie連線管理設定(Secure、HttpOnly) * 連線管理(Session Management) * 使用者登出後，交談識別碼(Session ID)應該失效 * 連線使用期間，週期性更換Session ID，並使舊的失效 * **A3. Sensitive Data Exposure 敏感資料外洩** * 情境： * 資料傳輸未採用安全加密方式(HTTPS) * 商品價格由客戶端傳給伺服器，有竄改機會 * 未以雜湊(Hash)方式進行資料儲存 * 未移除HTTP標頭中有關作業系統、網頁伺服器版本和應用程式框架的相關資訊 * 伺服器端所支援的加密協定建議採用**TLS1.1**(含)以上加密標準，SSL為TLS前身 * **A4. XML External Entities (XXE) XML外部處理器漏洞** * 情境： * 在XML文檔裡加入惡意內容，欺騙XML Parser並訪問未開放的資源 * 防範方式： * ==以JSON取代XML== * 更新XML Parser與library * ==使用SOAP1.2(含)以上版本== * 若可能，取消XML external entity與DTD功能 * **A5. Broken Access Control 無效的存取控管** * ==對各個角色的授權限制控管有漏洞，攻擊者可利用這些缺陷來訪問未經授權的功能或數據== * SSL IIS 6.0以前的版本常預設==WebDAV==服務開啟，容易造成網頁被順利瀏覽與複製 * 防範方式： * 伺服器應關閉檔案目錄列表功能 * 不以檔名或易猜測的條件當作參數傳遞 * 避免在用戶端進行存取判斷，避免遭受竄改回傳 * **A6. Security Misconfiguration 不安全的組態設定** * 安全配置錯誤是最常見的問題，許多設定的預設值並不是安全的，因此，必須定義、實施和維護這些設定 * 情境： * 帳密預設、啟用或安裝了不必要的功能、錯誤訊息帶有系統資訊、==利用robot.txt檔案來隱藏網站的重要目錄== * 防範方式： * 訊息不應揭露敏感訊息 * 關閉不必要的功能 * ==最小權限原則== * **A7. Cross-Site Scripting(XSS) 跨站腳本攻擊** * 是一種網站應用程式的安全漏洞攻擊，是==代碼注入==的一種。它允許惡意使用者將程式碼注入到網頁上，其他使用者在觀看網頁時就會受到影響 * ==XSS允許攻擊者在受害者的瀏覽器上執行腳本==，進而劫持Session、或將使用者導向惡意網站 * 防範方式： * ==驗證輸入資料(Input Validation)，輸入、輸出資料編碼(Encoding)==，避免XXS或==跳脫字元攻擊== * **A8. Insecure Deserialization 不安全的反序列化漏洞** * 導致遠程代碼執行 * 重送攻擊、注入攻擊、授權提升攻擊等等... * 防範方式： * 只接受來自可信任來源的serialized object * 當參照現存檔案時，不應使用黑名單限制允許的檔案名稱和類型 * 上傳檔案不可保存在與應用程式相同的Web環境與目錄下 * 對serialized object做integrity check * 紀錄反序列化的異常和失敗 * 非預期的結果狀況應排除(不要過度依賴程式語言的垃圾回收機制) * **A9. Using Components with Known Vulnerabilities 使用已知漏洞元件** * 一整包環境或有使用到帶有漏洞的元件，即會對系統造成影響 * 防範方式：定期更新套件、確認套件在==CVE Details==無已知安全性漏洞 * CVE 公共漏洞和暴露，到此網站輸入套件與版本號即可查詢有無漏洞 * **A10. Insufficient Logging & Monitoring 紀錄與監控不足風險** * 防範方式： * 確保所有登錄、訪問控制失敗和服務器端輸入驗證失敗都可以有足夠的上下文進行紀錄，以識別可疑或惡意用戶 * ==確保以一種可以被集中式日誌管理且容易理解的解決方案產生日誌== *