OWASP Top 10：最新的 Web 安全風險與防範措施（2021 版）

更新日期： 2025 年 3 月 4 日

隨著 Web 應用程式的發展，網路安全威脅也日益增加。

為了幫助開發者與安全專業人員識別和防範最常見的安全風險，開放式 Web 應用程式安全計畫（OWASP） 定期發布 OWASP Top 10，列出當前最關鍵的 Web 安全漏洞。

這些風險可能導致敏感資料洩露、伺服器遭駭、用戶帳戶盜用等嚴重問題，因此了解並採取適當的防範措施至關重要。

以下是 OWASP Top 10（2021 版） 的最新安全風險，以及詳細的說明與防範措施。

存取控制失敗（Broken Access Control）

存取控制是一種安全機制，確保使用者只能執行符合其權限的操作。

例如，一般使用者只能查看自己的帳戶，而管理員才能修改系統設定。

然而，許多網站的存取控制機制存在漏洞，使攻擊者能夠繞過權限限制，執行未經授權的操作。

根據 OWASP 的統計，94% 的應用程式存在這類問題，可能導致以下風險：

• 個資外洩：攻擊者存取或竊取其他用戶的資料
• 帳戶被盜：攻擊者假冒其他用戶，執行未經授權的操作
• 系統被入侵：攻擊者取得管理員權限，甚至刪除或篡改系統數據

常見攻擊方式

水平權限提升（Horizontal Privilege Escalation）

攻擊目標：存取或修改其他用戶的資料

舉例：
假設 API 請求如下：

GET /user/12345

這是用戶 A 的帳戶資訊，但如果攻擊者將 12345 修改為 12346，卻能夠查看用戶 B 的帳戶資訊，表示系統未正確驗證使用者身份，導致權限繞過。

垂直權限提升（Vertical Privilege Escalation）

攻擊目標：讓低權限用戶獲取更高層級的權限，例如從一般用戶變成管理員

舉例：
某些網站允許使用者透過 URL 存取管理員介面，例如：

GET /admin/dashboard

如果系統沒有驗證該使用者是否具有管理員權限，攻擊者可能透過直接輸入網址的方式進入管理後台，進而修改系統設定。

未授權 API 存取

攻擊目標：透過開放的 API 存取敏感數據

舉例：
某些開發者為了方便內部測試，可能會開放 API 來存取所有用戶資料，例如：

GET /admin/all_users

如果這個 API 沒有適當的存取控制，攻擊者就能輕易請求該 API，取得所有用戶的個資。

如何防範這類攻擊？

採用「最小權限原則」（Least Privilege Principle）

確保每個使用者只能存取其職責範圍內的資源，不應給予不必要的權限。

伺服器端強制執行存取控制

許多開發者會在前端進行權限驗證，例如隱藏管理員選單，但攻擊者仍然可以透過直接請求 API 來繞過這些限制。

因此，存取控制應該在伺服器端執行，而非僅依賴前端驗證。

使用安全框架進行身份驗證與授權

可使用 Spring Security、OAuth2、JSON Web Token（JWT）等安全框架來管理用戶身份，確保 API 僅允許授權的使用者存取。

限制 API 存取

• 為 API 設定適當的身份驗證與授權機制，例如 OAuth2 或 API 金鑰
• 在 API 層級進行權限驗證，確保請求者具備適當權限才可執行操作
• 避免返回過多錯誤訊息，以防止攻擊者獲取敏感資訊

加密失敗（Cryptographic Failures）

加密的目的是保護敏感資料，確保只有授權的人才能讀取。

但如果加密方式不安全，或者根本沒有加密，攻擊者就能輕易竊取或破解資料，造成個資外洩或系統被入侵。

許多應用程式在處理密碼、信用卡資訊、個人身份資料（PII）時，沒有正確使用加密技術，甚至直接把資料「明文存儲」，讓駭客能直接讀取，這是一個嚴重的安全風險。

常見的安全漏洞

使用 HTTP 傳輸敏感資料

如果網站使用 HTTP 而不是 HTTPS，所有數據在網路上都是「裸奔」的，任何人都可以看到，就像人在沒有穿衣服的情況下在公開場所行走一樣，毫無遮掩。

駭客可以透過中間人攻擊（MITM, Man-In-The-Middle Attack） 截取並竊取資料。

例如，當使用者在 HTTP 網站上輸入密碼時，攻擊者可以輕易攔截並記錄下這組密碼。

使用過時或弱加密方式

一些舊的加密演算法（如 MD5、SHA-1）已被證明不安全，攻擊者可以透過彩虹表（Rainbow Table） 或 暴力破解 輕易解密。

例如，如果一個網站仍然使用 MD5 來儲存密碼，駭客可以透過現有的破解工具在幾秒鐘內解密並取得使用者密碼。

金鑰管理不當

即使使用了強加密，但如果金鑰沒有妥善保護，攻擊者還是可以輕易解密資料。

常見錯誤包括：

• 將金鑰硬編碼在應用程式內，例如在程式碼中寫死加密金鑰： encryption_key = "my_secret_key" 如果駭客取得應用程式的程式碼，就能輕易找到金鑰，解密所有資料。
• 將金鑰存放在不安全的伺服器，如公開的 GitHub 儲存庫、未加密的設定檔等。

如何防範這類攻擊？

強制使用 HTTPS

• 所有網頁、API 必須使用 HTTPS（TLS 1.2 或以上），確保資料在傳輸過程中被加密，避免被攔截。
• 可使用 HSTS（HTTP Strict Transport Security） 強制瀏覽器只允許 HTTPS 連線。

使用安全的加密演算法

• 資料加密：使用 AES-256（高強度對稱加密）來保護敏感數據。
• 密碼儲存：密碼應該加鹽（Salt），並使用 bcrypt、PBKDF2 或 Argon2 進行安全雜湊（Hashing）。
• 避免使用 MD5、SHA-1，這些演算法已經被證明不安全。

妥善管理加密金鑰

• 使用 專門的金鑰管理服務（KMS），如 AWS KMS、Google Cloud KMS，確保金鑰不會暴露。
• 不要將金鑰存放在程式碼內或公開儲存庫，可以使用環境變數或安全儲存解決方案（如 HashiCorp Vault）。

避免將敏感資料儲存在應用程式內

• 不要將密碼、信用卡資訊存放在 Cookie 或本地儲存（Local Storage），因為攻擊者可以透過 XSS（跨網站腳本攻擊）竊取這些資訊。
• 若必須存儲敏感資訊，應加密後再存放，並確保金鑰的安全性。

程式注入（Injection）

注入攻擊是一種駭客透過惡意輸入來欺騙伺服器，讓它執行不該執行的指令。

例如，攻擊者可以輸入一段特殊的代碼，來竄改資料庫、控制伺服器，甚至取得網站管理權限。

這類攻擊非常普遍，根據 OWASP 的研究，94% 的網站都有這種漏洞，而且駭客還能透過自動化工具大規模攻擊，影響範圍極大。

SQL 注入（SQL Injection）

目標：控制資料庫，盜取或篡改數據

範例：
假設有一個登入系統，會根據使用者輸入的帳號密碼來查詢資料庫：

SELECT * FROM users WHERE username = 'admin' AND password = 'password';

如果駭客輸入 admin' -- 作為帳號，SQL 會變成：

SELECT * FROM users WHERE username = 'admin' --' AND password = 'password';

因為 -- 會讓後面變成註解，SQL 只會檢查 admin，不再驗證密碼，駭客就能繞過密碼驗證登入系統。

跨網站指令碼攻擊（XSS，Cross-Site Scripting）

目標：讓其他使用者的瀏覽器執行惡意 JavaScript

範例：
如果網站允許用戶輸入留言，而沒有做安全過濾，攻擊者可能會輸入：

<script>alert('你的帳號已被駭！');</script>

當其他人查看這則留言時，他們的瀏覽器就會執行這段 JavaScript，可能會竊取 Cookie、控制使用者帳戶，甚至植入釣魚網站。

命令注入（Command Injection）

目標：讓伺服器執行惡意指令，甚至刪除整個系統

範例：
某些網站允許用戶輸入指令來執行系統功能，例如查詢伺服器狀態。如果程式沒有正確過濾輸入，攻擊者可能輸入：

; rm -rf /

這條指令會刪除伺服器上的所有檔案，導致系統完全崩潰。

如何防範這些攻擊？

使用預備語句（Prepared Statements）或 ORM，避免 SQL 注入

cursor.execute("SELECT * FROM users WHERE username = ? AND password = ?", (username, password))

這種方法確保輸入的內容不會被當作 SQL 指令執行，而是單純的參數。

對所有輸入進行驗證與過濾

• 使用白名單（Allowlist）機制，只允許合法的輸入格式，例如電子郵件只能包含 @ 和 .，不能有 " 或 <script>。

防止 XSS 攻擊

• 對用戶輸入的內容進行 HTML 轉義，讓 <script> 變成純文字，而不會被瀏覽器執行。
• 使用內容安全政策（CSP，Content Security Policy），限制 JavaScript 的來源，避免惡意腳本執行。

防止命令注入

• 不要直接執行使用者輸入的指令，應該使用安全的 API，例如 subprocess.run() 而非 os.system()。
• 限制應用程式的權限，即使駭客成功執行指令，也無法刪除重要系統文件。

不安全的設計（Insecure Design）

「不安全的設計」指的是應用程式在一開始設計時，沒有考慮到安全性，導致後續即使增加防護措施，仍然容易被攻擊。

想像你建了一棟房子，但忘了裝門鎖，之後即使安裝警報系統，門鎖本身的缺陷仍然讓小偷能輕易進入。

這就是不安全設計的問題：如果根本設計有漏洞，後面再補救也無法真正防止駭客攻擊。

這種問題在 2021 年被列入 OWASP Top 10，因為很多應用程式在開發時，沒有把安全性當成優先考量，導致後續出現各種漏洞，例如未設計好權限管理、驗證機制不嚴格、業務邏輯有漏洞 等。

常見的不安全設計問題

沒有事先分析安全風險（未進行威脅建模）

問題：開發時只關注功能，沒有考慮可能的安全漏洞。

結果：駭客容易發現設計上的缺陷，例如未經授權的存取、API 竄改等。

忽略業務邏輯攻擊

問題：應用程式的流程設計不夠嚴謹，允許攻擊者透過修改請求繞過重要步驟。

範例：

• 網購網站沒有確認付款狀態，導致駭客透過竄改 API 直接獲得商品，而不付錢。
• 註冊系統允許同一個 Email 重複註冊，導致攻擊者可用機器人大量註冊帳號，進行詐騙或洗版攻擊。

沒有考慮安全驗證（缺乏安全設計模式）

問題：某些重要功能沒有適當的身份驗證，導致駭客可以輕易入侵。

範例：

• 密碼重設漏洞：如果系統允許用戶直接輸入新密碼，而不需驗證身份（如 Email 確認碼或 SMS 驗證碼），駭客可以輕易竄改他人密碼，盜取帳戶。
• 管理員後台無額外保護：如果一個網站的管理後台 admin/dashboard 沒有額外身份驗證，攻擊者可以透過暴力測試或猜測網址來進入管理介面。

如何防範不安全的設計？

在開發初期就進行「威脅建模」（Threat Modeling）

• 預測系統可能遭遇的攻擊，分析高風險區域，並在設計階段就建立相應的防禦機制。

遵循安全設計模式

• 使用 OWASP Security by Design 原則，確保系統的每個功能都考慮了安全性，例如強化身份驗證、加密重要數據、設計完整的存取控制機制。

建立清晰的安全需求文件

• 在設計時就明確規範哪些功能需要額外的安全驗證，例如付款、密碼重設、管理員存取等關鍵操作應有更強的安全保護。

安全設定錯誤（Security Misconfiguration）

「安全設定錯誤」指的是系統的安全配置沒有設定好，導致駭客可以輕易入侵。

現在的應用程式和伺服器功能越來越多，設定選項也越來越複雜。

開發者或管理者如果沒有仔細檢查，可能會留下預設帳號、開啟不必要的功能、顯示敏感錯誤資訊，這些都可能成為駭客攻擊的漏洞。

這就像你買了一個新保險箱，但沒有改預設密碼，結果小偷只要輸入「0000」就能打開它。

常見的安全設定錯誤

使用預設帳號和密碼

問題：許多系統在安裝時，會有「預設帳號和密碼」，如果沒有修改，駭客可以輕鬆登入系統。

範例：

• MySQL 預設的管理員帳號是 root，如果密碼沒改，駭客就能直接存取資料庫。
• 企業的伺服器可能預設帳密是 admin/admin，如果沒有修改，駭客就能遠端登入控制整個系統。

啟用不必要的功能或端口

問題：某些 API、伺服器功能或網路端口沒有用到，卻被開啟，讓駭客有更多機會攻擊。

範例：

• 伺服器開啟 FTP、Telnet、未加密的 HTTP，但這些功能根本不需要，駭客可以利用這些端口發動攻擊。
• API 中包含 測試模式或管理員後門，駭客發現後可以直接存取管理功能。

顯示詳細錯誤訊息

問題：當系統發生錯誤時，應該只顯示「發生錯誤，請聯繫管理員」，但有些系統會顯示詳細的錯誤資訊，讓駭客知道系統的架構，進而找到攻擊方式。

範例：

• 某個網站登入錯誤時，回傳訊息：「Incorrect password for user admin」，這讓駭客知道 admin 是存在的帳號，接下來就可以嘗試破解密碼。
• 如果系統顯示 Database connection failed: MySQL version 5.6 error，駭客就知道網站使用的是 MySQL 5.6，然後去找對應的漏洞來攻擊。

如何防範這些錯誤？

變更預設帳號和密碼，並強制使用強密碼

• 安裝完系統後，立即修改所有預設密碼，並使用長度至少 12 位，包含大小寫字母、數字、特殊符號的密碼。
• 啟用 雙因素驗證（2FA），提升帳號安全性。

關閉不必要的功能、端口與 API

• 如果不用 FTP、Telnet、未加密 HTTP，就應該關閉，避免駭客入侵。
• 定期檢查 開放的 API，確保只有必要的功能對外公開。

隱藏錯誤訊息，避免洩露系統資訊

• 只顯示「發生錯誤，請聯繫管理員」，不要直接回傳 資料庫錯誤、伺服器版本、程式碼細節 等訊息。
• 使用 日誌系統（Logging System） 來記錄錯誤，但不應將錯誤資訊直接顯示給使用者。

易受攻擊和過時的元件（Vulnerable and Outdated Components）

現在的應用程式通常不會從零開始開發，而是依賴大量開源函式庫、第三方框架和 API 來節省開發時間。

但這些元件如果沒有定期更新，或本身存在已知漏洞，駭客就能利用這些弱點入侵系統。

就像你用了一把二手鎖來保護你的房子，但這把鎖已經被破解過，駭客知道怎麼開，這樣你的房子就很容易被闖入。

例子：

• Log4j 漏洞（2021 年）：Log4j 是 Java 應用程式常用的日誌記錄工具，但舊版本存在漏洞，攻擊者可以透過這個漏洞遠端控制伺服器，執行惡意程式（這類攻擊稱為 遠端程式執行，RCE）。
• jQuery 舊版本漏洞：許多網站使用 jQuery 來處理 JavaScript，但舊版本存在跨網站指令碼（XSS）漏洞，攻擊者可以植入惡意腳本，竊取用戶資料或劫持瀏覽器行為。

常見的攻擊方式

使用過時的第三方套件

問題：應用程式使用的函式庫或框架過舊，存在已知的安全漏洞，但開發者沒有更新。

範例：

• 使用舊版的 jQuery，駭客可以透過 XSS 攻擊植入惡意 JavaScript 竊取用戶資料。
• 使用未更新的 WordPress 插件，攻擊者可以利用已知漏洞取得管理員權限。

沒有定期更新系統與依賴函式

問題：很多開發團隊部署完系統後，沒有持續關注安全更新，導致應用程式長期處於不安全狀態。

範例：

• 某個 API 框架新版本修復了一個嚴重漏洞，但因為系統沒有更新，攻擊者仍能利用舊版漏洞入侵。
• 伺服器上的作業系統或 Docker 映像檔版本過舊，導致已知安全問題沒有被修補。

如何防範這類問題？

定期更新所有依賴元件

• 使用 自動化工具（如 Dependabot、Snyk） 監測程式碼中的安全漏洞，並提醒開發者更新套件。

限制使用過時的函式庫，優先選擇官方支援的長期更新版本（LTS）

• LTS（Long-Term Support，長期支援版本） 會持續接收安全修補，因此應該優先使用，而不是使用已停止維護的舊版本。

使用容器（如 Docker）時，確保映像檔是最新版本

• 如果使用 Docker、Kubernetes 來部署應用程式，應該定期更新映像檔，確保其中的系統元件和函式庫都是最新的安全版本。

身份驗證和認證失敗（Identification and Authentication Failures）

身份驗證的目的就是確認使用者的身份，確保只有授權的人可以登入系統並執行操作。

如果身份驗證機制不夠安全，駭客就有機會冒充使用者、盜取帳戶，甚至控制整個系統。

想像一下，如果你的銀行帳戶允許「123456」作為密碼，或者沒有限制錯誤登入的次數，那麼駭客只要不斷嘗試不同密碼，就能輕鬆登入你的帳戶，轉走你的錢。

這類問題常見於密碼管理不當、登入機制太弱、會話（Session）管理不嚴格，讓攻擊者有機會繞過身份驗證，取得帳戶控制權。

常見的身份驗證漏洞

使用弱密碼

問題：系統允許使用者設定簡單的密碼，例如 123456 或 password，這些密碼很容易被猜到。

風險：駭客可以用字典攻擊（Dictionary Attack） 或 暴力破解（Brute Force Attack），快速試出密碼，輕鬆入侵帳戶。

沒有限制登入嘗試次數

問題：某些網站沒有設定登入失敗次數限制，駭客可以不斷嘗試不同的密碼，直到成功登入。

風險：駭客可以用「暴力破解攻擊（Brute Force Attack）」，透過自動化工具每天嘗試數百萬組密碼，直到找到正確密碼。

範例：
如果一個網站允許無限次登入嘗試，駭客可以用工具輸入幾百萬個密碼，總有一天會猜中你的密碼。

會話管理不當

問題：使用者登入後，網站會分配一個會話令牌（Session Token），但如果這個令牌沒有適當保護，駭客就可以竊取使用者的會話，冒充該用戶執行操作。

風險：駭客可以透過 XSS（跨網站腳本攻擊） 或 Session Fixation（會話固定攻擊），盜取會話令牌，然後在另一台裝置上登入受害者的帳戶。

範例：

• 使用者登入後，網站沒有設定「閒置時間過長自動登出」，導致攻擊者可以在受害者離開電腦時，直接操控其帳戶。
• 會話令牌（Session Token）沒有設置 HttpOnly 或 Secure 標誌，導致駭客可以透過 JavaScript 讀取並盜用。

如何防範這類攻擊？

要求使用強密碼

• 設定 最少 12 位數，包含 大小寫字母、數字、特殊字元，避免簡單密碼。
• 禁止使用常見密碼，如 password123、qwerty、12345678 等。
• 提供 密碼強度檢測，引導使用者設定更安全的密碼。

啟用雙因素驗證（2FA）

• 使用 Google Authenticator、SMS 驗證碼、Email 驗證碼 等第二層驗證，防止駭客即使取得密碼也能輕鬆登入。

限制登入嘗試次數

• 設定 登入失敗 5 次後，帳戶短時間內無法再嘗試登入，防止暴力破解攻擊。
• 可以透過 CAPTCHA 驗證 阻止機器人自動嘗試登入。

確保會話管理安全

• 設定會話自動過期機制，當使用者閒置一段時間（例如 15 分鐘）後，自動登出。
• 啟用 HttpOnly 和 Secure 標誌，確保 Session Token 不能被 JavaScript 讀取或透過非加密連線傳輸。
• 強制重要操作時重新驗證身份，例如變更密碼、交易時需要重新輸入密碼或 2FA。

軟體和資料完整性失敗（Software and Data Integrity Failures）

這類漏洞的問題在於軟體或數據可能被竄改，而系統沒有適當的機制來檢查這些變更是否安全。

如果沒有驗證軟體的真實性，駭客就有機會偷偷植入惡意程式，讓受害者在不知情的情況下安裝它們。

想像你在手機上下載了一個應該是官方的 App 更新，但由於下載來源未經驗證，結果下載到的是被駭客修改過的版本，導致你的個資被竊取，這就是軟體完整性遭破壞的例子。

常見風險情境

軟體更新被駭客竄改

問題：應用程式沒有檢查更新來源的真實性，導致使用者可能安裝到惡意更新。

範例：

• 某應用程式會自動下載更新，但它沒有檢查更新檔案的簽名，駭客可以假冒官方伺服器，讓使用者安裝包含惡意程式的更新檔。
• 在 2017 年 NotPetya 攻擊 中，駭客入侵了某會計軟體的更新伺服器，讓所有安裝該軟體的電腦都自動下載到惡意程式，導致大規模企業系統癱瘓。

開發流程（CI/CD）遭入侵

問題：如果軟體的開發或部署管道（CI/CD，持續整合/持續部署）沒有適當的安全防護，駭客可以偷偷植入惡意程式碼，讓最終產品變成有漏洞的版本。

範例：

• 2020 年的 SolarWinds 供應鏈攻擊，駭客入侵了 SolarWinds 公司的開發系統，在其官方更新包中植入惡意程式碼，最終影響了美國政府機構和全球許多企業。

如何防止這類攻擊？

使用數位簽章驗證軟體更新

• 確保每次更新的軟體都附有數位簽章，只有來自官方的更新才會被安裝，避免安裝到駭客竄改的版本。
• 例如，Windows 和 macOS 會檢查軟體的簽章，如果簽章無效，系統就會阻止安裝。

確保 CI/CD 管道安全

• 限制開發人員和自動化工具的存取權限，防止駭客竄改程式碼或部署流程。
• 使用多因素驗證（MFA）來保護開發環境，確保只有授權人員能夠更改軟體。
• 定期掃描 CI/CD 管道中的依賴程式（如第三方函式庫）是否含有已知漏洞。

安全記錄和監控失敗（Security Logging and Monitoring Failures）

這類問題指的是，系統沒有正確記錄重要的安全事件，或者沒有即時監控異常行為。

導致攻擊發生後沒有人察覺，讓駭客可以長時間滲透系統，甚至竊取大量資料。

想像你家裡裝了監視器，但攝影機沒開、錄影沒存檔，等到有小偷來過後，你卻找不到任何證據，甚至不知道到底發生了什麼事。

這就是缺乏安全記錄與監控的風險。

這類問題特別容易發生在企業系統或雲端環境中，如果沒有適當的日誌（Log）管理與異常監控。

駭客可以長時間潛伏在系統內，進行持續性攻擊（APT, Advanced Persistent Threat），導致機密資料被竊取，甚至影響業務運作。

為什麼沒有記錄與監控很危險？

駭客入侵後，沒有人發現

• 如果沒有記錄登入紀錄、管理員操作、異常請求等，駭客可以入侵系統，卻不留下任何痕跡，管理者完全不會察覺。
• 例如，攻擊者獲得某位使用者的帳戶後，持續使用該帳戶存取敏感資料，但系統從未記錄或警告這種異常行為。

攻擊發生後，找不到線索

• 企業發現系統出問題時，如果沒有詳細的日誌，就無法追蹤駭客的攻擊路徑，也無法知道攻擊者偷走了哪些資料。

駭客可以長期滲透系統（APT 攻擊）

• 在某些 APT 攻擊中，駭客可能會潛伏數個月甚至數年，不斷蒐集資訊、竊取資料。如果沒有監控異常行為，這類攻擊可能在很久之後才被發現，甚至永遠不被察覺。

如何防範這類問題？

集中管理日誌（Logging），確保所有事件都有記錄

• 使用 ELK（Elasticsearch、Logstash、Kibana） 或 Splunk 來統一收集系統日誌，確保所有登入、異常行為、管理操作都被記錄下來。
• 確保日誌存放在安全的地方，避免駭客入侵後刪除記錄。

使用 SIEM 系統即時監控異常行為

• SIEM（Security Information and Event Management） 例如 Splunk、IBM QRadar、Azure Sentinel，可以自動分析日誌，發現可疑活動，例如：
  • 有人連續 10 次登入失敗，可能是暴力破解攻擊。
  • 使用者突然從異常 IP（如國外）登入，可能是帳戶被盜。
  • 伺服器有大量的異常流量，可能是 DDoS 攻擊。

伺服器端請求偽造（SSRF，Server-Side Request Forgery）

SSRF（伺服器端請求偽造）是一種駭客利用網站伺服器，幫助它發送惡意請求的攻擊方式。

通常，伺服器可以存取內部系統，例如資料庫、內部 API 或管理介面，而這些系統一般不對外開放。

但 SSRF 攻擊可以繞過這些限制，讓伺服器自己攻擊自己的內部網路。

想像你家有個嚴格的門禁系統，外人進不來，但如果駭客能讓你家的 智能助理（伺服器） 自己幫他開門，那他就能輕鬆進入。

這就是 SSRF 的危險之處！

SSRF 會造成什麼風險？

存取內部系統

問題：伺服器通常能夠存取內部資源，例如資料庫、雲端管理介面、Kubernetes API 伺服器等，而攻擊者可以利用 SSRF 來存取這些敏感資源。

範例：

• 透過 SSRF，駭客可以讓伺服器請求 http://localhost:8000/admin，進入系統管理介面。
• 如果伺服器在雲端（如 AWS、GCP），駭客可以透過 SSRF 存取內部 API，例如 AWS 的 http://169.254.169.254/latest/meta-data/，竊取憑證來控制整個雲端伺服器。

繞過防火牆存取內部網路

問題：企業的內部系統通常有防火牆保護，不允許外部存取。但如果網站伺服器被 SSRF 利用，駭客可以繞過防火牆，讓伺服器幫他存取內部系統。

範例：

• 駭客讓伺服器請求 http://192.168.1.100:3306（內部 MySQL 伺服器），嘗試進行未授權存取。
• 讓伺服器請求內部 DevOps 工具（如 Jenkins、GitLab Runner），嘗試執行惡意指令。

如何防止 SSRF？

限制伺服器的請求範圍，避免存取內部 IP 或敏感 API

• 在程式中設定「只能對外部網站發送請求」，拒絕請求內部 IP，如 127.0.0.1、169.254.169.254、192.168.0.0/16。
• 如果應用程式不需要發送 HTTP 請求，應該完全禁用這類功能，避免成為攻擊目標。

驗證輸入 URL，確保伺服器不會請求未授權的資源

• 確保使用者提供的 URL 只能請求「可信任的網站」，避免請求內部網路。
• 使用 DNS 解析方式來檢查 URL，避免攻擊者利用 http://[email protected] 這種混淆手法繞過檢測。

結論

OWASP Top 10 提供了最新的 Web 安全風險指南，每位開發者應深入了解這些風險，並採取適當的安全措施來保護應用程式。

定期安全測試、持續監控與良好的開發習慣，是確保 Web 應用程式安全的關鍵。🚀