為確保系統的安全性與穩定性，檢測是現代資訊系統開發過程中不可或缺的一環。透過檢測可以及早發現潛在的安全漏洞、程式缺陷或不符合規範的程式碼，從而降低系統被攻擊或失效的風險。在進行修補時，應注意以下幾點：
優先處理高風險漏洞：根據漏洞對系統的影響與修補難度進行分級，先修補可能導致重大安全威脅的問題。
避免引入新問題：修補後需進行完整的功能測試與安全驗證，避免修補行為引發新的系統錯誤或安全問題。
依循最佳實踐：修補過程應遵循安全開發原則，並參考相關程式語言或框架的最佳實踐指南。
透過完整的源碼檢測與修補，能有效提升系統的安全性與使用者信任度，並符合法規要求，為組織建立穩健的資訊安全基礎。
我們把漏洞分類方式結合了 OWASP Top 10 2021 作為基礎分類標準，適合涵蓋大部分常見漏洞。此外，針對 OWASP Top 10 未涵蓋或需要更細緻劃分的漏洞，補充了自定義類別，以確保分類的全面性與靈活性。分類內容分為兩大部分：
基礎分類 - 參考 OWASP Top 10 2021：這部分包含業界公認的十大常見安全漏洞，適用於大多數系統與應用程式的漏洞檢測與修補建議。
擴展分類 - 自定義類別：這部分用於補充 OWASP Top 10 未涵蓋的安全風險，例如業務邏輯漏洞、記憶體管理問題、前端安全漏洞與第三方工具整合問題等。
透過此分類方式，漏洞的分析與修補建議將更具條理性與針對性，有助於快速識別與解決安全問題。
⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️ ⚠️
在檢測報告中，同一個弱點項目可能會根據具體情境出現不同的風險等級（高、中、低）或是OWASP Top 10 2021分類。這種情況通常取決於以下因素：
弱點的出現位置
弱點在代碼中的位置可能會影響其風險等級。例如，同一類型的 SQL 注入漏洞，如果發生在敏感的認證功能中，可能被標記為高風險；但如果發生在次要功能中，則可能被評為中或低風險。
弱點的觸發條件
如果某弱點需要複雜的條件才能被利用，風險等級可能會降低。反之，若弱點易於觸發且影響廣泛，風險等級會提高。
影響範圍
如果弱點可能導致大規模數據洩露或系統崩潰，通常會被標記為高風險。相反，如果影響範圍有限，則風險等級會降低。
存在的緩解措施
如果該弱點已經有某些緩解措施或保護機制（如防火牆或輸入驗證），風險等級可能會降低。
檢測工具的評估邏輯
不同的源碼檢測工具對風險等級的評估邏輯可能有所不同，可能會根據檢測到的細節為同一弱點分配不同的等級。
可被歸類到owasp 弱點：A01
弱點介紹
是一種常見的安全漏洞，攻擊者可以透過操控應用程式中處理檔案或目錄的路徑，進而存取或操作不應該被存取的檔案與目錄。該漏洞通常出現在以下情況：
應用程式允許使用者提供檔案名稱或路徑作為輸入。
程式未對使用者輸入的路徑或檔案名稱進行驗證和過濾。
程式直接將輸入內容拼接至系統檔案操作的函數中，例如 fs.existsSync() 或 fs.readFile()。
可能風險
未經授權的檔案存取：
攻擊者可以存取應用程式意外暴露的敏感檔案（如設定檔或密碼檔）。
檔案覆寫與執行：
攻擊者可能上傳或修改檔案內容，進一步注入惡意程式碼。
系統權限提升：
攻擊者透過檔案操作，可能擴展到控制伺服器或其他系統資源。
舉例
不安全程式寫法
const fs = require('fs');
const path = require('path');
// 接受使用者提供的檔案名稱
app.get('/download', (req, res) => {
const fileName = req.query.file; // 使用者輸入未檢查
const filePath = __dirname + '/uploads/' + fileName; // 路徑直接拼接
// 檢查檔案是否存在並傳送
if (fs.existsSync(filePath)) {
res.sendFile(filePath);
} else {
res.status(404).send('File not found');
}
});
問題分析
攻擊者可以將 file 參數設為 ../../../../etc/passwd，利用../ 繞過限制，存取系統敏感檔案。
修補方式
1. 限制輸入值：
驗證和過濾使用者提供的路徑或檔案名稱，僅允許合法名稱。
2. 最小權限原則：
限制應用程式只能存取必要的目錄和檔案。
確保應用程式的執行帳號不具備管理員或高權限操作。
可被歸類到owasp 弱點：A02
弱點介紹
是指應用程式未能妥善保護使用者或系統的敏感資訊，導致未經授權的個人資料存取或洩漏。此類漏洞對使用者隱私和系統安全構成重大威脅，並可能違反資料保護法規(如 GDPR 或 CCPA等）。
常見情境
資料未經加密： 敏感資料以明文形式傳輸或存儲，易受竊聽攻擊。
缺乏存取控制： 無效的驗證或授權機制，允許未授權存取使用者資料。
日誌洩露： 程式錯誤記錄中包含敏感資訊(如密碼或信用卡號碼)。
過度暴露 API 資訊： API 返回過多使用者資料或缺乏適當篩選。
可能風險
資料洩漏與濫用： 個人識別資訊 (PII) 和機密資料可能被攻擊者利用，用於詐騙或身份盜用。
法律與合規風險： 違反資料保護法規可能導致巨額罰款和訴訟。
信譽損失： 資料洩露事件將嚴重影響品牌信譽和客戶信任。
修補方式
1. 加密敏感資料：
傳輸層加密 (TLS/SSL)： 使用 HTTPS 確保資料傳輸安全。
靜態資料加密： 存儲敏感資料時，使用 AES-256 或更高級別加密。
2. 實施存取控制與驗證：
強化身份驗證： 使用多因素認證 (MFA)。
存取控制： 根據角色或屬性限制敏感資料存取。
3. 保護 API 資訊：
限制 API 返回的資料範圍，避免暴露不必要資訊。
使用速率限制 (Rate Limiting) 和認證 (Token-based Authentication)。
4. 最小權限原則與防禦機制：
限制資料存取帳號的權限，確保應用程式只具有最低存取權限。
定期更新安全性設定與版本，修復已知漏洞。
可被歸類到owasp 弱點：A02
弱點介紹
指應用程式在資料傳輸過程中未使用加密通訊協定 (如 HTTPS)，而是透過明文協定 (如 HTTP) 傳輸資料，導致敏感資訊容易被竊聽、竄改或劫持。
此類漏洞特別危險，因為攻擊者可以進行中間人攻擊 (Man-in-the-Middle Attack, MITM)來攔截資料流量。
常見情境
應用程式使用 HTTP 而非 HTTPS 傳輸敏感資料 (如密碼、信用卡等資訊)。
應用程式接受或重定向到不安全的 HTTP 連線。
未強制使用安全標頭防止降級攻擊。
風險影響
資料洩漏： 敏感資料在傳輸過程中被未授權的第三方攔截和讀取。
資料完整性受損： 攻擊者可能竄改傳輸中的資料，導致用戶端與伺服器信任受損。
身分竊取與認證攻擊： 密碼、session Cookie 等認證資料被竊取後可能造成未授權存取。
修補方式
1. 啟用 HTTPS：
安裝和配置 SSL/TLS 憑證，確保所有網頁和 API 使用 HTTPS 傳輸。
確保伺服器僅接受 TLS 1.2 或更新版本。
2. 強制 HTTPS 重定向：
在應用程式層面強制 HTTP 請求轉為 HTTPS
3. 啟用 HTTP 安全標頭：
使用 HSTS (HTTP Strict Transport Security) 防止降級攻擊
4. 驗證 SSL/TLS 憑證：
檢查伺服器的 SSL 憑證是否有效且配置正確。
禁用自簽名憑證及過期憑證。
5. 移除不安全的傳輸協定和加密算法：
禁止使用舊版 SSL/TLS，例如 TLS 1.0 和 1.1。
僅允許強加密算法 (如 AES-GCM) 和安全金鑰長度 (至少 2048 位元)。
6. 測試和監控：
使用工具 (如 SSL Labs 或 Qualys) 測試 HTTPS 安全性配置。
定期檢查和更新 SSL/TLS 憑證及配置。
可被歸類到owasp 弱點：A02
弱點介紹
是指應用程式將加密金鑰直接嵌入程式碼中，這是一種嚴重的安全漏洞。
硬編碼(hard-coding)的加密金鑰可能導致敏感數據和系統資源遭受未經授權的存取，進一步引發數據洩露和系統攻擊。
※硬編碼(hard-coding)：白話文的說法是「程式寫死」，將相關的參數直接寫進程式碼當中。
風險影響
密鑰洩露： 硬編碼的金鑰很容易被攻擊者透過程式碼檢查或逆向工程獲取。
數據洩漏： 攻擊者可利用洩露的金鑰解密敏感數據或未經授權地存取數據庫。
系統完整性破壞： 攻擊者可能利用金鑰進行未經授權的簽名驗證或執行其他攻擊行為。
修補方式
1.避免硬編碼金鑰：
範例： 使用環境變數或密鑰管理工具來存取金鑰。
// 從環境變數中載入金鑰
const encryptionKey = process.env.ENCRYPTION_KEY;
if (!encryptionKey) {
throw new Error("Encryption key is not defined");
}
2.實施加密金鑰輪替策略：
定期更換加密金鑰，並確保舊金鑰不可用。
建立密鑰版本控制策略，確保只有最新的密鑰可用於加密和解密。
3. 實施最小權限原則：
僅授權需要存取金鑰的應用程式或服務。
使用角色基礎存取控制 (RBAC) 限制金鑰的存取範圍。
4. 加密金鑰的儲存與傳輸：
確保金鑰在靜態存儲時被加密保護，例如使用 AES-256 加密。
在金鑰傳輸過程中使用 TLS 保護。
⚠️⚠️掃描掃到參數名為"key"，會誤判為加密金鑰，將參數名稱改掉即可。⚠️⚠️
可被歸類到owasp 弱點：A03
弱點原因
此弱點與 Java Naming and Directory Interface (JNDI) 相關，當應用程序允許非預期的 JNDI 查詢且未對輸入進行適當的驗證時，攻擊者可通過注入惡意的 JNDI 參考來誘導應用程序執行未經授權的遠程代碼。
JNDI 引用注入漏洞通常涉及以下情況：
不受控制的動態代碼執行：應用程序接受用戶輸入並直接用於 JNDI 查詢或其他動態操作。
未正確過濾 JNDI 資源：未能限制 JNDI 查詢只在信任的命名上下文中進行。
遠程代碼執行風險：攻擊者可通過惡意的 JNDI URL 加載惡意代碼，例如 LDAP 或 RMI。
修補方式
1.禁用危險的 JNDI 功能
2.限制 JNDI 資源的範圍
僅允許 JNDI 查詢訪問本地資源，禁止外部資源(如 LDAP/RMI)。
3.驗證與過濾用戶輸入
對所有用戶輸入進行嚴格的驗證，特別是那些可能被用於動態代碼執行的輸入。
採用 白名單策略，明確允許的輸入格式。
免直接使用用戶輸入作為 JNDI 查詢參數
4.更新依賴與使用安全版本
5.啟用安全策略
在運行時環境中啟用安全策略(SecurityManager)，限制 JNDI 加載不受信任的代碼：security.Security.setProperty("networkaddress.cache.ttl", "0");
可被歸類到owasp 弱點：A05
弱點介紹
是指應用程式設定的 Cookie 使用過於寬泛的網域 (Domain) 屬性，允許該網域下的所有子網域存取該 Cookie。這會導致安全性風險，例如：子網域攻擊或跨站請求偽造攻擊 (CSRF)。
常見情境
Cookie 被設置為 Domain=.example.com，導致所有子網域 (如 sub1.example.com 和 sub2.example.com) 都可讀取該 Cookie。
若子網域受到攻擊或遭入侵，攻擊者可以透過該 Cookie 模擬合法使用者的身份進行攻擊。
未對 Cookie 添加安全屬性 (如 Secure 和 HttpOnly)，進一步加劇風險。
風險影響
會話劫持： 攻擊者透過子網域取得會話 Cookie，冒充合法使用者執行未授權操作。
資料洩漏： 敏感資料可能被攻擊者竊取，進一步濫用。
跨站攻擊： 攻擊者利用子網域漏洞執行跨站腳本攻擊 (XSS) 或跨站請求偽造攻擊 (CSRF)。
修補方式
1. 限制 Cookie 的 Domain 屬性
避免使用過於寬泛的 Domain 屬性。例如：
錯誤示範：document.cookie = "sessionId=abc123; Domain=.example.com; Path=/; HttpOnly; Secure";
修正示範：document.cookie = "sessionId=abc123; Domain=sub.example.com; Path=/; HttpOnly; Secure";
2. 啟用 Secure 和 HttpOnly 屬性：
Secure: 確保 Cookie 僅在 HTTPS 連線下傳輸，防止中間人攻擊。
HttpOnly: 防止 JavaScript 存取 Cookie，減少 XSS 攻擊風險。
3. 啟用 SameSite 屬性：
可選擇 Strict 或 Lax：
Strict: Cookie 僅適用於第一方請求，不允許跨站請求存取。
Lax: Cookie 在大部分跨站請求中被阻止，但允許安全的導航請求。
可被歸類到owasp 弱點：A05
弱點介紹
是指應用程式將敏感的密碼或憑證資訊直接存儲在配置檔案中。這種做法可能導致敏感資訊暴露，特別是在配置檔案被意外推送到版本控制系統或被未授權的使用者存取時。
常見情境
在應用的 config.json 或 application.yml 等配置檔案中存儲明文密碼：
{
"database": {
"user": "admin",
"password": "P@ssw0rd123"
}
}
配置檔案被推送到 Git 等版本控制系統，導致敏感資料洩露。
未對配置檔案的存取權限進行限制，導致敏感資料暴露。
風險影響
資料洩露： 配置檔案中的密碼一旦被攻擊者獲取，可能導致數據庫或其他敏感資源被未授權存取。
系統被攻擊： 攻擊者可能利用洩露的密碼進一步發起攻擊，甚至取得伺服器控制權限。
合規問題： 此類漏洞可能違反 GDPR、CCPA 等資料保護法規，導致法律責任。
修補方式
避免使用 Password 相關關鍵字在配置檔案中。
避免將密碼存儲在配置檔案中：
最佳實踐： 使用環境變數來存儲敏感資訊，確保其不會被推送到版本控制系統。
// 從環境變數中讀取密碼
const dbPassword = process.env.DB_PASSWORD;
if (!dbPassword) {
throw new Error("Database password is not set");
}
使用加密保護配置檔案中的敏感資料：
若必須存儲敏感資訊，應對其進行加密處理：
const crypto = require('crypto');
function encrypt(text, key) {
const cipher = crypto.createCipher('aes-256-cbc', key);
let encrypted = cipher.update(text, 'utf8', 'hex');
encrypted += cipher.final('hex');
return encrypted;
}
⚠️掃描掃到參數名為"Password"的關鍵字，會誤判為密碼或是明碼，將其名稱改掉即可。⚠️
可被歸類到owasp 弱點：A01、A08
弱點原因
Mass Assignment 是指在某些框架中，允許將 HTTP 請求的參數自動綁定到對應的類型模型屬性中。如果沒有正確限制允許的屬性，攻擊者可能通過這種方式操控敏感數據，從而造成數據洩露或權限提升等安全問題。
常見情境
現代的開發框架為了提高效率，支持將 HTTP 請求參數自動綁定到物件屬性中，並自動完成對應屬性名稱與請求參數的對應。然而，如果開發者未明確配置哪些屬性是允許被綁定的，攻擊者可能利用這一點，在請求中加入額外的參數，從而修改本不應被用戶操作的敏感屬性。例如：
權限提升攻擊：攻擊者可能通過請求直接修改類型模型中的角色屬性，將自己提升為管理員。
數據完整性破壞：攻擊者可能修改其他用戶的敏感訊息，如餘額、隱私設置等。
修補方式
明確屬性白名單：僅允許指定屬性被綁定，避免敏感屬性暴露給外部。
驗證請求數據：在後端進行數據驗證，確保只有合法數據被更新。
使用 DTO(資料傳輸物件)：透過拆分數據模型，將內部的敏感屬性與外部的可編輯屬性分離。
禁用全域綁定：在框架配置中限制自動綁定功能，改用手動綁定以提高控制力。
可被歸類到owasp 弱點：A10
弱點原因
此漏洞屬於 Server-Side Request Forgery (SSRF) 攻擊類型。攻擊者利用 SSRF 漏洞誘使服務器發送未經驗證的請求，可能導致以下後果：
內部網絡掃描或存取： 攻擊者可以利用服務器存取內部系統或其他受保護的資源。
數據洩漏： 攻擊者可透過服務器存取敏感資料或 API 資源。
遠程代碼執行 (RCE)： 若與其他漏洞結合，可能會導致遠端代碼執行風險。
建議修改
1.輸入驗證與過濾：
僅允許白名單內的 URL、IP 或域名。
禁止直接使用用戶輸入來構造請求地址。
2.網絡級別防護：
限制內部網絡和受保護資源的存取權限。
使用防火牆或網絡分段來保護內部資源。
3.禁用不必要的功能與協議：
停用不需要的 URL handlers（如 file://, gopher:// 等）。
4.適用安全庫與框架：
使用支持安全功能的 HTTP 客戶端庫，例如限制重定向或響應解析。
可被歸類到owasp 弱點：A07
弱點原因
是指應用程式將敏感密碼或認證資訊直接嵌入程式碼中，這是一種常見但嚴重的安全漏洞。此類密碼可能被惡意攻擊者獲取，進而用於未授權存取應用程式或系統。
常見情境
在應用程式中直接以明文形式硬編碼密碼：
const password = "P@ssw0rd123"; // Hardcoded密碼
認證資料被硬編碼進設定檔案或程式碼庫。
程式碼中包含第三方服務的 API 金鑰或密鑰，未實施加密保護。
密碼意外暴露在版本控制系統 (如 Git) 中。
風險影響
密碼洩露： 硬編碼的密碼容易被發現並利用，尤其是當程式碼被意外暴露或被逆向工程。
未授權存取： 攻擊者可以使用洩露的密碼未授權地存取敏感系統或數據。
擴散性風險： 若相同密碼被多處重複使用，攻擊者可能藉此擴大攻擊範圍。
修補建議
實施加密保護：
如果必須儲存密碼，應對密碼進行加密處理，密碼加密時，應確保加密金鑰的存取安全，並考慮使用憑證管理工具來保護金鑰。
限制存取範圍與權限：
僅允許最低限度的權限來存取密碼和敏感資料。
實施角色基礎存取控制 (RBAC)。
限制存取範圍與權限：
僅允許最低限度的權限來存取密碼和敏感資料。
可被歸類到owasp 弱點：A03
弱點原因
是一種嚴重的安全漏洞，指應用程序執行了未經驗證或受控的用戶輸入命令，導致攻擊者能夠執行任意系統命令。這種漏洞允許攻擊者完全接管受影響的系統，執行惡意指令，並可能進一步攻擊其他系統。
常見情境
命令串接漏洞：應用程序將用戶輸入直接串到命令中，攻擊者可以輸入指令，去執行他想要執行的事情。
文件操作命令注入：攻擊者利用注入修改文件或目錄的權限，訪問敏感資料。
Web Shell 安裝：攻擊者通過命令注入執行下載惡意程序的指令，進一步控制伺服器。
風險影響
系統控制權限提升：攻擊者能直接操作系統，例如執行任意命令、刪除資料、安裝惡意程序。
數據洩露或破壞：攻擊者通過命令注入訪問或修改敏感數據，例如用戶訊息、下載文件。
業務中斷：攻擊者可利用命令注入造成服務當機或業務功能中斷。
進一步滲透攻擊：攻擊者可能利用受影響系統作為跳板攻擊內部網絡中的其他系統。
修補建議
1.嚴格驗證用戶輸入：
確保所有用戶輸入均經過驗證和過濾，拒絕不符合預期格式的輸入。
使用正規表示式限制輸入的字符集，例如禁止特殊符號（如 ;, &&等）。
2.避免直接執行系統命令：
儘可能使用框架或庫提供的高層級 API，而非直接使用 exec()、system() 等函數。
3.使用參數化執行：
避免將用戶輸入的直接串接到命令中，而是使用參數化方式傳遞輸入。
4.限制命令執行的權限：
限制應用程序執行命令的權限，例如：
使用低權限用戶運行服務。
禁止訪問敏感目錄（如 /etc, /root）。
可被歸類到owasp 弱點：A05
弱點原因
HTTPOnly 是一種 Cookie 屬性，當設置為 true 時，Cookie 僅能通過 HTTP/HTTPS 請求傳輸，無法被 JavaScript 存取。
這是一項重要的安全功能，可防止跨站腳本攻擊(XSS)竊取 Cookie，進而避免敏感資訊(如用戶身份驗證憑證)被盜用。
風險影響
跨站腳本攻擊(XSS)：攻擊者通過注入的惡意腳本，讀取用戶的 Cookie，並利用其中的敏感資訊冒充合法用戶執行未授權操作。
用戶身份盜用：攻擊者獲取會話 ID 後，可以偽裝成受害者，繞過身份驗證，執行敏感操作。
資料洩露：未保護的 Cookie 如果包含應用關鍵訊息，可能導致整個應用的安全被攻擊者破解。
修補建議
1.設置 HTTPOnly 屬性：確保在設置 Cookie 時，啟用 HTTPOnly 屬性，防止 JavaScript 訪問 Cookie。
2.結合其他安全屬性：
除了設置 HTTPOnly，建議同時啟用以下屬性：
(1)Secure 屬性：
確保 Cookie 僅能在 HTTPS 連線中傳輸，防止 Cookie 在未加密的 HTTP 連線中被竊取。
(2)SameSite 屬性 ：
防止跨站請求攜帶 Cookie，以降低 CSRF（跨站請求偽造）的風險。
SameSite: Strict：僅允許同一站點的請求攜帶 Cookie。
SameSite: Lax：允許部分跨站請求
3.避免存儲敏感數據：
即使啟用了 HTTPOnly，也應避免在 Cookie 中直接存儲敏感數據，例如：
密碼
金鑰
個資(PII)
建議僅存儲安全性 Token 或會話 ID，並將敏感數據存儲在伺服器端。
可被歸類到owasp 弱點：A05
弱點原因
Overly Broad Domain 問題是指將 Cookie 的 Domain 屬性設置得過於廣泛，例如 .example.com，這樣的設置會使該 Cookie 在該域名下的所有子網域都能訪問，而不僅限於特定子網域。
風險影響
敏感資料洩露：Cookie 包含身份驗證訊息(如 Session ID 或 Token)，攻擊者可以通過不安全子網域竊取這些訊息。
跨站點腳本攻擊 (XSS)：如果某個子網域存在 XSS 漏洞，攻擊者可以利用該子網域讀取共享的 Cookie。
CSRF 攻擊：攻擊者利用共享 Cookie 在其他子網域執行未授權的請求，冒充合法用戶操作。
應用隔離性失效：不同應用之間的 Cookie 相互干擾，可能導致用戶體驗不一致或資料混亂。
修補建議
1.限制 Cookie 的 Domain：確保 Cookie 僅在需要的子網域上有效，避免設置 .example.com，而是指定具體的子網域。
2.將應用程序隔離：不同子網域的應用程序應使用獨立的 Cookie，確保應用程序之間互不干擾。
3.使用 SameSite 屬性：設置 SameSite=Strict 或 SameSite=Lax，防止跨站請求攜帶 Cookie。
4.啟用其他 Cookie 安全屬性：
結合使用以下屬性：
HTTPOnly：防止 JavaScript 訪問 Cookie。
Secure：僅允許 HTTPS 傳輸。
Path：限制 Cookie 僅在特定路徑有效。
5.減少子網域共享 Cookie 的需求：如果確實需要共享 Cookie，建議僅將共享 Cookie 用於跨子網域的非敏感資訊(如偏好設置)。
6.定期審核 Cookie 配置：定期檢查所有應用程序的 Cookie 設置，確保沒有過於廣泛的 Domain 配置。
可被歸類到owasp 弱點：A07
弱點原因
硬編碼的 API 認證是指將敏感憑證(如 API 金鑰、密碼、用戶名、權限 Token 等)直接嵌入到程式碼中，例如在程式碼中明文保存。
這種做法存在以下問題：
難以更新和更改：一旦這些憑證被嵌入到程式碼中，更新或更換它們變得非常困難，需要修改程式碼並重新部署應用。
高暴露風險：如果程式碼被洩露(如推送到公開的 GitHub 儲存庫)，攻擊者能夠輕易地獲取這些憑證。
共享敏感信息：團隊內部開發者可能無意間將敏感憑證暴露給不應該擁有這些資訊的成員，增加安全風險。
無法限制使用環境：硬編碼的憑證無法針對特定的執行環境(如開發、測試或生產)進行隔離。
風險影響
敏感數據洩露：攻擊者可以使用硬編碼的憑證訪問受保護的數據(如用戶資料、交易記錄)。
系統遭受未授權的操作：攻擊者可能利用 API 憑證對系統進行破壞性操作(如刪除數據、操控配置)。
經濟損失：第三方服務(如雲端存儲)可能因攻擊者濫用 API 認證而產生高額費用。
品牌聲譽損害：憑證洩露可能導致數據外洩事件，進一步影響品牌的公信力。
修補建議
1. 移除硬編碼憑證：將所有敏感憑證從程式碼中移除，改用更安全的管理方式。
2.使用憑證管理工具：採用專門的憑證管理工具(如 AWS Secrets Manager、Azure Key Vault 或 HashiCorp Vault)來管理和分發敏感憑證。
3.使用環境變數：在部署環境中設置憑證為環境變數，並在應用程式中動態讀取：
const API_KEY = process.env.API_KEY;
fetch(`https://api.example.com/data?key=${API_KEY}`);
確保不同環境(如開發、測試、生產)使用不同的環境變數。
4.設置最低權限：確保 API 憑證僅擁有完成任務所需的最低權限，避免不必要的權限過多。
5.定期更換憑證：即使沒有發生洩露，也應該定期輪換憑證，降低風險。
可被歸類到owasp 弱點：A06
弱點原因
Cross-Frame Scripting(CFS)是一種瀏覽器安全問題，主要發生在應用程式允許其內容被嵌入到其他網站的 <iframe> 或框架中，並且未對框架中的內容執行安全控制。此問題可能導致：
1.點擊劫持(Clickjacking)：
攻擊者嵌入應用程式的網頁到惡意網站中，誘導用戶點擊被覆蓋的按鈕或鏈接。
2.敏感數據洩露：
如果應用程式允許跨框架訪問數據，攻擊者可能通過腳本操控框架來竊取用戶數據。
3.惡意腳本執行：
攻擊者通過框架操縱執行惡意腳本，危害用戶或應用程式的安全。
修補方式
1.啟用 HTTP 標頭來防範框架嵌入
使用瀏覽器安全標頭禁止或限制應用程式被嵌入到框架中：
X-Frame-Options：
在伺服器的 HTTP 響應中添加 X-Frame-Options 標頭：
DENY：完全禁止此網頁被嵌入框架。
SAMEORIGIN：僅允許同源網站嵌入此網頁。
X-Frame-Options: SAMEORIGIN
Content-Security-Policy (CSP)：
使用 CSP 的 frame-ancestors 指令控制誰可以嵌入此頁面：
Content-Security-Policy: frame-ancestors 'self';
2.JavaScript 防護機制：
在頁面中加入檢查邏輯，確保不允許被嵌入：
if (window.top !== window.self) {
window.top.location = window.self.location;
}
可被歸類到owasp 弱點：A03
弱點原因
DOM-based XSS 是一種特殊的跨站腳本攻擊(XSS)，它發生在應用的客戶端(瀏覽器)，並由 JavaScript 直接操作 DOM(文檔物件模型)時產生，無需經過伺服器端的參與。
DOM-based XSS 的主要成因是：
不信任的用戶輸入未經驗證或過濾：程式直接將 URL、查詢參數、錨點等外部來源的數據插入到 DOM 中，沒有進行任何安全檢查。
無伺服器端參與：攻擊發生完全在瀏覽器端，伺服器端對這些惡意腳本完全不知情。
JavaScript 直接插入 HTML：使用不安全的方式如 innerHTML、document.write() 或 eval() 插入內容，導致攻擊者可執行任意腳本。
風險影響
敏感數據洩露：攻擊者可以通過惡意腳本竊取用戶的 Cookie、Session 或其他敏感訊息。
用戶身份盜用：攻擊者利用竊取的用戶憑證冒充受害者執行未授權操作。
瀏覽器劫持：攻擊者可以使用 XSS 攻擊重定向用戶到惡意網站。
系統進一步滲透：攻擊者通過 DOM-based XSS 獲取初始訪問權限，進一步對應用發動滲透攻擊。
修補建議
1.驗證和過濾用戶輸入：
嚴格過濾和驗證所有來自 URL 查詢參數、錨點等外部來源的數據。
移除不必要的特殊符號(如 <, >, ', " 等)。
2.使用安全的 DOM 操作方法：避免使用 innerHTML、document.write() 或 eval() 等不安全的方法。
3.啟用內容安全策略(CSP)：
配置 CSP(Content Security Policy)頭，限制執行外部或內聯腳本：
Content-Security-Policy: script-src 'self';
4.編碼用戶輸入：將用戶輸入進行編碼，避免惡意腳本執行。
可被歸類到 owasp 弱點：A03
弱點原因
持久型跨站腳本攻擊(Persistent XSS)是一種嚴重的 Web 應用程式安全漏洞，又稱Stored XSS(儲存型 XSS)，攻擊者可以將惡意 JavaScript 永久儲存在伺服器上，並且當其他用戶存取受影響的頁面時，這段惡意代碼會自動執行。
這種攻擊特別危險，因為它不需要攻擊者誘導受害者點擊惡意連結，而是當受害者瀏覽受影響的頁面時，惡意 JavaScript 會自動執行，進一步竊取敏感資訊或控制用戶行為。
常見情境
1.留言板或論壇
攻擊者發表含有惡意 JavaScript 代碼的留言
當其他用戶閱讀留言時，JavaScript 代碼自動執行
可以竊取使用者的 Cookie 或重新導向到惡意網站
2. 用戶個人檔案
如果網站允許用戶自訂「暱稱」或「個人簽名」，但未過濾輸入內容，攻擊者可以在這些欄位中插入 XSS 代碼
當其他用戶查看該用戶的個人檔案時，攻擊者的 JavaScript 代碼將自動執行
3. 管理員面板
攻擊者提交惡意 XSS 代碼到客服回報系統
當管理員檢視這些回報內容時，JavaScript 代碼執行，竊取管理員的身份驗證 Cookie
攻擊者可利用這些 Cookie 取得管理員權限，控制網站
風險影響
1. 用戶 Cookie 竊取
透過 document.cookie，攻擊者可以竊取用戶的身份驗證 Cookie，導致帳號被盜
2. Session 劫持
如果攻擊者獲取了用戶的 session ID，可以冒充該用戶進行未授權操作
3. 惡意重定向
XSS 可用來將受害者重定向到釣魚網站，誘導其輸入敏感資訊(如密碼、信用卡號)
4. 惡意行為注入
攻擊者可透過 XSS 修改網頁內容，植入鍵盤側錄器、加載惡意廣告、發送未經授權的請求(CSRF)等
修補建議
輸入驗證(Input Validation)
限制可接受的輸入格式，例如禁止 <script>、<iframe> 等標籤。
若系統允許 HTML，則應使用 白名單過濾，僅允許安全的標籤與屬性。
使用內容安全策略(CSP)
設置 HTTP Content-Security-Policy 標頭來限制 JavaScript 執行：
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-randomvalue'
避免直接插入用戶輸入
如果必須允許 HTML，請使用可信的 HTML 清理庫，例如：
Python: Bleach
Java: JSoup
Node.js: DOMPurify
可被歸類到 owasp 弱點：A03
弱點原因
反射型 XSS（Cross-Site Scripting）是由於使用者輸入未經適當驗證或編碼，直接輸出至網頁回應中，導致攻擊者可注入惡意腳本並被瀏覽器執行。
發生條件通常包括：
使用者透過 URL、表單提交等方式傳送資料。
伺服器將輸入資料立即「反射」回瀏覽器中。
網頁未對輸入資料進行輸出編碼（Output Encoding）。
常見情境
1.URL 中的參數未處理
https://example.com/search?q=<script>alert(1)</script>
則使用者瀏覽該頁時會自動執行惡意 JavaScript。
2.欄位回填
<!-- 錯誤示範（未編碼） -->
<input name="username" value="<?php echo $_POST['username']; ?>">
若未使用 htmlspecialchars()，有機會被注入惡意腳本。
風險影響
竊取使用者 Cookie / Session
偽造 UI 操作、跳轉至惡意網站（Phishing）
誘使已登入使用者執行未授權操作
損害企業信任、導致資安事件與法規責任
修補建議
輸出編碼：
輸出資料時，應根據用途選擇正確的編碼方式（HTML、屬性、JavaScript、URL 等）
echo htmlspecialchars($_GET['q'], ENT_QUOTES, 'UTF-8');
Content Security Policy(CSP)：
Content-Security-Policy: default-src 'self'; script-src 'self';
輸入驗證：
不要只做輸出轉義，對輸入資料本身也應該「限制格式」，例如：
Email：使用 regex 驗證格式
數字欄位：限定為 is_numeric() 或 preg_match('/^\d+$/')
選單欄位：只能從白名單中選取(如 in_array())
過濾 JavaScript 語法
使用安全函式庫：
1.OWASP 提供的 Java Encoder Project
2.DOMPurify(JS 中過濾 HTML)
可被歸類到owasp 弱點：A02
弱點原因
不加密的傳輸方式：
應用透過未加密的 HTTP 協議加載外部腳本(JavaScript 文件)。HTTP 是一種不安全的協議，數據在傳輸過程中未被加密，容易被攔截和修改。
受中間人攻擊 Man-in-the-Middle(MiTM)攻擊影響：
攻擊者可以攔截未加密的傳輸，插入或替換腳本內容，讓惡意代碼執行在受害者的瀏覽器中。
缺乏來源驗證：
如果腳本加載自第三方網站且未透過 HTTPS 或其他方式驗證來源完整性，可能會被攻擊者利用。
常見情境
1.透過 HTTP 加載第三方 JavaScript 文件
情境：
在網頁中，開發者使用如下的腳本標籤從第三方來源加載資源：
<script src="http://example.com/js/library.js"></script>
當資源透過 HTTP 加載時，攻擊者可以攔截請求，插入惡意代碼。
攻擊者可能通過 DNS 欺騙或 MITM 攻擊替換 library.js，並插入惡意代碼。
問題： 攻擊者可以替換腳本內容，導致惡意代碼在用戶瀏覽器中執行。
風險影響
惡意代碼執行：攻擊者可以在受害者的瀏覽器中執行惡意腳本，例如竊取 Cookie、Session Token、用戶憑證等敏感資訊。
用戶劫持：攻擊者可以劫持用戶會話，冒充用戶進行未授權操作。
數據洩露：攻擊者透過腳本收集和傳輸用戶數據(例如表單內容、密碼)，造成數據洩露。
品牌信譽損害：用戶認為網站本身安全性不足，對其品牌或服務的信任度降低。
修補建議
1.強制使用 HTTPS：
所有外部資源(包括腳本)必須使用 HTTPS 協議加載，防止資料在傳輸過程中被攔截或篡改。
2.使用 Subresource Integrity (SRI)：
為外部腳本資源添加完整性檢查，確保加載的腳本未被篡改：
<script src="https://example.com/js/library.js" integrity="sha384-abc123..." crossorigin="anonymous"></script>
3.避免依賴不可信的第三方腳本：
減少對第三方腳本的依賴，特別是來自不可信來源的腳本。
如果必須使用，應對來源進行審核，並啟用 SRI。
4.啟用內容安全策略 (CSP)：
配置 CSP 限制可執行的腳本來源：Content-Security-Policy: script-src 'self' https://trusted-cdn.com;
5.審查和測試程式：
定期審查應用程式，檢查是否有不安全的資源加載方式。
測試應用是否存在 MITM 攻擊漏洞。
6.使用自托管腳本 ：
將所需的第三方腳本下載到本地伺服器，避免直接加載遠程資源：
<script src="/assets/js/library.js"></script>
可被歸類到owasp 弱點：A03
弱點原因
Unicode 雙向覆寫(BiDi)控制字元可能被攻擊者用來在原始程式碼中進行隱藏惡意邏輯的攻擊，這類型攻擊也被稱為 Trojan Source 攻擊。
攻擊者可利用這些語言的編譯行為來隱藏有害程式碼，進而影響程式行為，造成未授權存取、邏輯欺騙或繞過安全檢查。
BiDi(Bidirectional)控制字元是一組 隱藏在程式碼中的 Unicode 字元，用於影響文字顯示方向，例如：
RLI（Right-to-Left Isolate，U+2067）
LRI（Left-to-Right Isolate，U+2066）
PDI（Pop Directional Isolate，U+2069）
RLE（Right-to-Left Embedding，U+202B）
LRE（Left-to-Right Embedding，U+202A）
攻擊者可將 BiDi 控制字元插入註解、變數名稱或字串中，使得程式碼在顯示和編譯時呈現不同的效果，從而繞過安全審查或誤導開發人員。
風險影響
隱藏惡意邏輯：攻擊者可在原始碼中隱藏關鍵的 Early Return、條件判斷、授權繞過或安全檢查繞過，審查時不易察覺。
影響原始碼審查：開發人員無法在 IDE 或 Git Diff 工具中清楚識別惡意程式碼，降低程式碼審查的可信度。
跨語言攻擊：多種程式語言的編譯器或直譯器都可能受到影響，使攻擊範圍擴大。
修補建議
1. 強化程式碼檢查
在版本控制系統(如 Git)中啟用 Unicode 控制字元警告，避免 BiDi 字元無意中進入程式碼。
使用 靜態程式碼分析工具(如 ESLint、Checkmarx、Semgrep)來掃描 Unicode BiDi 控制字元，並標記為潛在風險。
在 IDE(如 VSCode、JetBrains IDE)中啟用 隱藏字元顯示，確保程式碼的可視性與可讀性。
2. 強制開發流程規範
限制 Unicode 控制字元的使用，例如在審查時，加入 BiDi 控制字元檢查。
在 CI/CD 流程(如 GitHub Actions、GitLab CI)中加入 自動掃描規則，發現可疑 Unicode 字元時發出警告。
3. 保護開發與審查環境
在程式碼審查工具(如 GitHub Code Review、Phabricator)中強制顯示不可見控制字元。
在 Pull Request 或 Merge Request 時，自動檢測是否包含 BiDi 控制字元，避免惡意代碼進入主幹分支。
4. 教育與意識提升
培訓開發人員 識別 BiDi 控制字元攻擊，提升對於 Unicode 程式碼安全風險的認識。
在企業內部或開發團隊中，建立安全程式指南，涵蓋 Unicode 風險防範及程式碼審查規範。
可被歸類到owasp 弱點：A07
弱點原因
空白密碼(Empty Password)是一個嚴重的身份驗證漏洞，如果系統允許使用者註冊或登入時不設置密碼，將導致攻擊者可以輕易存取帳戶，甚至利用這一漏洞進行進一步攻擊。
空白密碼允許攻擊者輕鬆地：
繞過身份驗證機制
存取敏感數據
發動橫向攻擊(Lateral Movement)
利用受害者帳戶執行未授權的操作
這不僅會影響個人用戶，還可能導致企業內部系統被未經授權地存取，造成 數據洩漏、業務中斷。
風險影響
1. 無密碼保護的帳戶可能被入侵
如果攻擊者發現某個帳戶允許空白密碼，他們可以直接登入並存取所有資料。
這對於管理員帳戶或 API 金鑰存取來說尤為危險。
2. 系統容易被大規模攻擊
攻擊者可以使用自動化腳本來測試所有帳戶是否允許空白密碼(Credential Stuffing)。
若某些帳戶允許空白密碼，攻擊者可以輕易存取系統，甚至刪除數據或執行惡意操作。
3. 法規合規性問題
資通安全責任等級分級辦法附表十資通系統防護基準之身分驗證管理措施有相關的規定。
修補建議
1. 禁止使用空白密碼
在前端與後端都應該檢查密碼是否為空
2. 設置密碼強度要求
密碼應至少包含 8 個字元
應包含 大小寫字母、數字、特殊字元
使用正則表達式(Regex)來強制執行密碼規則
3. 在 API 層面強制密碼驗證
如果應用程式使用 API 來驗證身份，確保 API 禁止空白密碼登入
4.檢查舊系統是否允許空白密碼
使用 SQL 查詢來檢查資料庫中是否有使用者帳戶使用空白密碼
如果發現有帳戶允許空白密碼，應該立即修正並強制所有用戶更新密碼
可被歸類到owasp 弱點：A02
弱點原因
弱加密(Weak Encryption)指的是使用 過時、不安全或密碼強度不足的加密演算法來保護敏感數據。這些演算法因為計算能力的進步，已經無法提供足夠的安全性，攻擊者可以輕易破解加密數據，導致：
敏感資訊洩漏
未經授權的數據存取
常見的不安全加密演算法包括：
DES
3DES
MD5
SHA-1
這些演算法在過去曾被廣泛使用，但現代計算技術已經能夠快速破解這些加密機制，因此它們不應再用於保護敏感資訊。
風險影響
1.敏感數據洩漏
攻擊者可以透過暴力破解(Brute-force Attack)或彩虹表攻擊(Rainbow Table Attack)解密資料。
如果用於存儲密碼、支付資訊或身份驗證，攻擊者可以獲取使用者帳號、金融資訊。
2.供應鏈攻擊
如果應用程式依賴的第三方庫仍然使用弱加密，攻擊者可以利用這個弱點來破壞整個生態系統。
例如：某些 IoT 設備、舊版 VPN、舊版 SSL/TLS 通訊仍然可能使用弱加密，導致攻擊者可以輕易破解通訊內容。
修補建議
1. 禁用所有已知的弱加密演算法
應用程式應該全面禁用 DES、3DES、MD5、SHA-1，並改用更強的加密演算法，如 AES 和 SHA-256。
2.使用 AES 進行對稱加密
AES-256 是目前安全的對稱加密標準。
3.使用 SHA-256 進行雜湊
如果應用程式需要存儲密碼，應該 使用 SHA-256 或更強的演算法
4. 在 TLS/SSL 設定中禁用弱加密
如果應用程式涉及 HTTPS 或 VPN 連線，應該確保 TLS 設定不使用弱加密套件
可被歸類到 owasp 弱點：A01
弱點原因
ASP.NET MVC 控制器行為(Controller Actions)如果允許 任何 HTTP 動詞(GET、POST、PUT、DELETE)存取，可能會導致未經授權的資料被變更，並且增加跨網站請求偽造攻擊CSRF(Cross-Site Request Forgery)的風險。
在安全的設計中，數據變更應該僅允許使用 POST、PUT、PATCH 或 DELETE，且應加強驗證，但如果開發者未加限制，攻擊者可能：
利用惡意網站發送 GET 請求來修改數據(CSRF 攻擊)
繞過身份驗證機制執行未經授權的請求
導致敏感資料洩漏或被修改
風險影響
1.跨網站請求偽造(CSRF)攻擊
攻擊者可以誘導受害者點擊惡意連結，觸發未經授權的請求，修改帳戶資訊、變更密碼，甚至刪除數據。
2.API 未經授權的請求
允許 GET 請求修改數據，會讓攻擊者繞過安全性驗證。
可能影響後端 API、IoT 設備、管理系統等敏感應用程式。
3. 資料洩漏與篡改
如果沒有正確的 HTTP 限制，攻擊者可以透過簡單的自動化工具批量測試 API，並修改重要資料。
修補建議
1.限制 HTTP 請求
透過 [HttpPost] 屬性限制控制器僅允許 POST 請求。
2. 啟用 CSRF 保護
為了防止 CSRF 攻擊，應使用防護機制，例如 ASP.NET MVC 提供的 AntiForgeryToken。
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult UpdateWidget(Model model)
{
// 受保護的更新邏輯
}
並在 前端表單中加入 @Html.AntiForgeryToken()
<form method="post" action="/UpdateWidget">
@Html.AntiForgeryToken()
<input type="text" name="widgetValue" />
<button type="submit">更新</button>
</form>
這樣，後端會檢查 CSRF Token，確保請求是來自受信任的來源，而不是惡意網站。
可被歸類到 owasp 弱點：A03
弱點原因
在 ASP.NET MVC 應用程式中，模型(Model)可以包含必填屬性(Required)和選填屬性(Optional)。如果開發者未妥善處理這些屬性，可能會導致：
業務邏輯繞過攻擊(Business Logic Bypass)
權限升級攻擊(Privilege Escalation)
資料完整性風險
攻擊者可以利用這個漏洞，透過惡意請求操控模型中的選填屬性，影響伺服器的處理邏輯。例如：
繞過必填欄位驗證，提交未完整的資料
透過變更選填欄位，執行未授權的操作，例如：提升權限
利用模型綁定(Model Binding)機制，向伺服器提交額外的參數來影響業務邏輯
風險影響
1.權限繞過攻擊(Privilege Escalation)
攻擊者可以在請求中傳遞額外的選填屬性(如IsAdmin=true)來獲取更高的權限。
這可能導致普通用戶帳戶被提升為管理員，從而控制系統。
2. 業務邏輯繞過(Business Logic Bypass)
如果模型允許部分屬性為選填，攻擊者可能透過不填寫關鍵欄位來繞過驗證。
3. 數據完整性問題
如果某些重要欄位(例如 AccountBalance)是選填的，那麼攻擊者可能能夠繞過 API 直接修改數據。
修補建議
1. 移除選填的敏感屬性
如果某些屬性(如 IsAdmin)不應該被用戶修改，則應該將其從模型中移除，並在後端處理。
2. 限制模型綁定(Model Binding)
使用 [Bind] 限制控制器接收的屬性，避免攻擊者透過請求傳遞額外的參數。
3.在 API 層進行額外的身份驗證
對於 API 端點，應該：
不依賴前端傳遞的(如 IsAdmin)屬性
使用身份驗證機制來決定用戶的權限
4.啟用伺服器端驗證
使用 ASP.NET MVC 的 ModelState.IsValid 確保請求資料符合預期。
可被歸類到 owasp 弱點：A03
弱點原因
在 ASP.NET MVC 中，模型可以包含其他子模型(Submodel)。如果這些子模型是可選的(Optional)，但內部屬性卻標記為 [Required]，這可能會導致：
繞過必填屬性驗證
意外的業務邏輯繞過
數據完整性問題
這種錯誤的模型設計可能允許攻擊者在不滿足 Required 條件的情況下，透過不同的請求方式繞過驗證機制。
舉個例子
想像你在網路上申請會員帳號，表單長這樣：
使用者名稱(UserName)：*必填
地址(Address)：選填
街道(Street)： *地址內的必填欄位
城市(City)：*地址內的必填欄位
⚠️如果你填了「地址」，那麼「街道」和「城市」就一定要填寫。
⚠️但如果你不填「地址」，那麼「街道」和「城市」就完全不用填，甚至根本不會被檢查。
問題來了：
如果「地址」沒填，後端就不會檢查「街道」和「城市」是不是空的。
這可能讓攻擊者用不完整的資料繞過系統檢查。
風險影響
1. 業務邏輯繞過(Business Logic Bypass)
攻擊者可以透過完全省略子模型(如 Address)來繞過內部 Required 屬性。
例如：如果 Address 用於帳單或寄送地址，攻擊者可能會成功註冊用戶但無法提供必要資訊。
2. 數據完整性問題
伺服器可能接受不完整的數據，導致後續數據處理發生錯誤，例如：
電商系統允許註冊帳號但無法結帳，因為缺少地址
銀行帳戶開戶允許提交，但缺少重要的身份資訊
3. 影響身份驗證與安全
如果子模型包含 驗證相關的欄位(如 EmailVerification、IsAdmin)，攻擊者可能能夠繞過這些驗證步驟並獲取帳號存取權限。
修補建議
1.確保子模型不是可選的
如果子模型 包含 Required 屬性，則應確保它是必填的，如果 Address 未提供，請求將被拒絕。
2.在控制器中手動檢查 null 值
public ActionResult Register(UserModel model)
{
if (model.Address == null)
{
return BadRequest("Address is required.");
}
if (!ModelState.IsValid)
{
return View(model);
}
return Ok("User registered successfully");
}
這樣即使 子模型是可選的，伺服器仍然會驗證 Address 是否為 null。
3.針對 API 使用 JSON Schema 驗證
如果這個模型用於 API，則可以使用 JSON Schema 驗證來確保數據完整性：
{
"type": "object",
"properties": {
"UserName": { "type": "string" },
"Address": {
"type": "object",
"properties": {
"Street": { "type": "string" },
"City": { "type": "string" }
},
"required": ["Street", "City"]
}
},
"required": ["UserName", "Address"]
}
這樣即使在 JSON 格式的 API 中，也可以防止 Address 被省略。
4.使用 BindRequired 屬性
在 ASP.NET Core 中，你可以使用 [BindRequired] 強制要求子模型不能為 null：
public class UserModel
{
public string UserName { get; set; }
[BindRequired] // ✅ 這樣 `Address` 必須存在，否則請求將被拒絕
public AddressModel Address { get; set; }
}
這樣即使 Address 未在請求中提供，伺服器仍然會拒絕請求。
可被歸類到 owasp 弱點：A05
弱點原因
此漏洞表明網站的 Session Cookie 沒有透過 SSL(HTTPS)傳輸，導致攻擊者可以攔截這些 Cookie 並進行會話劫持(Session Hijacking)。
在安全的 Web 應用程序中，所有涉及身份驗證的 Session Cookie 都應該：
透過 HTTPS 安全傳輸
設置 Secure 屬性，確保 Cookie 只能透過安全連線傳輸
設置 HttpOnly 屬性，防止 JavaScript 讀取 Cookie，降低 XSS 風險
如果 Session Cookie 允許透過 HTTP(非加密)傳輸，攻擊者可以透過中間人攻擊(MITM, Man-in-the-Middle)竊取用戶的身份驗證資訊，進一步發動未授權存取攻擊。
風險影響
1.會話劫持(Session Hijacking)
攻擊者可以截取用戶的 Session Cookie，然後冒充用戶登入應用程式，進行未授權的操作。
2. 身份盜用(Identity Theft)
如果 Session Cookie 被竊取，攻擊者可以存取 受害者的帳戶、敏感數據，甚至進一步攻擊其他用戶。
3. 中間人攻擊(MITM)
若 Session Cookie 透過 HTTP 傳輸，攻擊者可以透過 網路封包攔截技術(如 ARP Spoofing)來竊取 Cookie。
修補建議
1.強制所有 Cookie 透過 HTTPS 傳輸
應該在 Cookie 設置中添加 Secure 屬性，確保 Cookie 只能透過 HTTPS 進行傳輸。
2.強制網站使用 HTTPS
在 ASP.NET 中，透過 web.config 強制重定向到 HTTPS。
3.在 ASP.NET Core 中啟用 HTTPS 和 Cookie 安全屬性
在 Startup.cs 設置 Cookie 安全屬性，所有的身份驗證 Cookie 都會透過 HTTPS 傳輸，避免被攔截：
services.ConfigureApplicationCookie(options =>
{
options.Cookie.SecurePolicy = CookieSecurePolicy.Always; // ✅ 確保 Cookie 只能透過 HTTPS 傳輸
options.Cookie.HttpOnly = true; // ✅ 防止 XSS 攻擊
options.Cookie.SameSite = SameSiteMode.Strict; // ✅ 防止 CSRF 攻擊
});
4.啟用 CSP(Content Security Policy)
為了防止 XSS 攻擊導致的 Cookie 竊取，可以設定 Content Security Policy(CSP)：
app.Use(async (context, next) =>
{
context.Response.Headers.Add("Content-Security-Policy", "default-src 'self'; script-src 'self'");
await next();
});
瀏覽器將只允許加載來自相同來源(self)的資源，降低 JavaScript 竊取 Session Cookie 的風險。
可被歸類到 owasp 弱點：A03
Header Manipulation(標頭操縱)是一種安全漏洞，攻擊者可以通過操縱 HTTP 請求或回應標頭來執行惡意行為，如 開啟 XSS 攻擊、Cookie 竊取、HTTP Response Splitting(HTTP 回應拆分) 或 Open Redirect(開放式重定向)
弱點原因
Header Manipulation 主要發生於伺服器允許不受控制地修改 HTTP 標頭，特別是當用戶輸入的內容直接用於構建標頭時。常見的原因包括：
未對用戶輸入進行驗證，允許惡意數據插入標頭。
不安全的重定向機制，如 Location 標頭直接使用用戶輸入。
未對回應標頭進行適當過濾，導致 HTTP Response Splitting 攻擊。
常見情境
開放式重定向(Open Redirect)
若應用允許用戶控制 Location 標頭，攻擊者可利用這一漏洞進行 釣魚攻擊：
header("Location: " . $_GET['redirect_url']);
攻擊者可以傳遞惡意網址：
https://example.com/redirect.php?redirect_url=https://evil.com
當用戶點擊該連結時，將會被導向至惡意網站。
HTTP Response Splitting(HTTP 回應拆分)
如果應用允許用戶輸入換行符(如 \n或 %0d%0a)，攻擊者可在標頭中插入額外的 HTTP 回應，劫持網頁內容：
header("Set-Cookie: user=" . $_GET['user']);
攻擊者可以發送：
https://example.com/page.php?user=admin%0D%0AContent-Length: 0%0D%0A%0D%0A<script>alert('XSS');</script>
這可能導致 XSS 攻擊，或者讓伺服器返回偽造的 HTTP 回應。
Cookie 竊取與篡改
如果應用允許用戶控制 Set-Cookie 標頭，攻擊者可能會：
降低 Cookie 安全性(移除 HttpOnly 和 Secure 標誌)。
劫持用戶 Session(透過 XSS 攻擊竊取 Cookie)。
執行 CSRF 攻擊(利用被操縱的 Cookie 發送請求)。
風險影響
1. 釣魚攻擊與社交工程
攻擊者可利用 開放式重定向，將受害者引導至假冒網站，竊取密碼或金融資訊。
2. XSS 攻擊
HTTP Response Splitting 可導致 惡意 JavaScript 被插入，允許攻擊者執行 XSS 攻擊。
3. 伺服器端資訊洩露
攻擊者可能透過操縱 Host 標頭來發現伺服器內部 API 或資源，進一步發動攻擊。
繞過安全機制
篡改 Referer、User-Agent、Origin 等標頭，可能繞過身份驗證、API 安全檢查，或 Bypass CSRF 保護機制。
修補建議
限制用戶輸入
避免直接使用用戶輸入來構造標頭，特別是 Location、Set-Cookie、Content-Type 等敏感標頭。
轉義 HTTP 標頭中的用戶輸入
確保輸入的 URL 不包含換行符 (\n 或 %0d%0a)，避免 HTTP Response Splitting。
function sanitize_header($value) {
return str_replace(["\r", "\n"], '', $value);
}
header("Location: " . sanitize_header($_GET['redirect_url']));
設置安全的 Cookie
設置 HttpOnly、Secure 和 SameSite 屬性，以防止 Cookie 竊取：
setcookie("session", $session_id, [
'HttpOnly' => true,
'Secure' => true,
'SameSite' => 'Strict'
]);
實施內容安全策略(CSP)
設置 Content-Security-Policy，防止惡意 JavaScript 執行：
Content-Security-Policy: default-src 'self'; script-src 'self'
限制 Host 標頭操縱
應該檢查 Host 標頭是否來自允許的域名：
$allowed_hosts = ['example.com', 'api.example.com'];
if (!in_array($_SERVER['HTTP_HOST'], $allowed_hosts)) {
die('Invalid Host Header');
}
可被歸類到 owasp 弱點：A02
這個漏洞指的是在程式碼中 硬編碼(Hardcoded)加密密鑰，導致攻擊者可以通過代碼分析、反向工程或源碼洩露來獲取密鑰，進而解密敏感數據或發動其他攻擊。
弱點原因
硬編碼加密密鑰的問題通常來自以下幾個原因：
開發方便：開發人員為了測試或簡化部署，直接在代碼中寫死密鑰。
缺乏密鑰管理機制：未使用安全的密鑰管理服務(如 KMS、HSM)。
錯誤的安全假設：開發者認為應用程式的源碼不會洩漏，實際上攻擊者可以透過 反向工程、存儲分析、記憶體提取等方式獲取密鑰。
使用不安全的加密方式：例如 對稱加密(AES)密鑰、JWT 簽名密鑰、API Token 等被直接寫入程式碼。
常見情境
源碼內部硬編碼密鑰
開發人員直接將加密密鑰寫入程式碼，例如：
import base64
from Crypto.Cipher import AES
SECRET_KEY = "myhardcodedkey123" # ❌ 硬編碼密鑰
cipher = AES.new(SECRET_KEY.encode(), AES.MODE_ECB)
encrypted_data = cipher.encrypt("SensitiveData1234")
攻擊者可以透過存取源碼或 靜態分析工具 來獲取這個密鑰。
硬編碼 JWT 簽名密鑰
應用程式使用 JSON Web Token(JWT)時，可能會在代碼中直接寫入密鑰：
String JWT_SECRET = "supersecurejwtsecret"; // ❌ 硬編碼密鑰
String token = Jwts.builder()
.setSubject("user123")
.signWith(SignatureAlgorithm.HS256, JWT_SECRET)
.compact();
如果攻擊者獲取這個密鑰，就可以 偽造 JWT，繞過身份驗證。
移動應用的反向工程
在 Android / iOS 應用中，攻擊者可以透過 APK 反編譯(如 JADX)、動態分析(如 Frida) 來獲取硬編碼密鑰。例如：
public class EncryptionUtils {
private static final String ENCRYPTION_KEY = "HardCodedKey1234"; // ❌
}
攻擊者可以透過 grep、strings 等工具在二進制文件中找到這個密鑰。
風險影響
1. 資訊洩露
攻擊者一旦取得密鑰，即可解密儲存或傳輸中的敏感資訊，如用戶密碼、信用卡資訊、API Token 等。
2. 身份驗證繞過
硬編碼的 JWT 密鑰洩露後，攻擊者可以偽造合法 Token，繞過身份驗證系統，甚至獲得管理員權限。
3. API 安全問題
如果 API Token 或加密密鑰被硬編碼，攻擊者可直接濫用 API，執行未授權請求。
惡意軟體或後門
攻擊者可利用已知密鑰對程式碼進行篡改，並重新簽名，部署含有後門的惡意應用。
修補建議
使用環境變數存儲密鑰
避免在代碼中直接寫入密鑰，改用 環境變數：
import os
SECRET_KEY = os.getenv("SECRET_KEY") # 從環境變數讀取
部署時，可以將密鑰設置為環境變數：
export SECRET_KEY="mysecurekey123"
使用安全的密鑰管理系統
企業級應用應該使用專門的密鑰管理服務（KMS）：
AWS Secrets Manager
Google Cloud KMS
Azure Key Vault
HashiCorp Vault
使用硬體安全模組(HSM)
對於高安全性應用，應考慮使用 HSM(硬體安全模組) 來存儲和處理密鑰，例如：
AWS CloudHSM
YubiHSM
Thales Luna HSM 這些模組可確保密鑰 永不暴露於應用內存，提高安全性。