Web 應用程式介紹

Web 應用程式是指在網頁瀏覽器中執行的軟體程式，透過網頁作為使用者和 Web 伺服器之間的介面。它們允許使用者透過網頁與伺服器進行互動，進行請求、提交以及透過網路從資料庫中檢索資料。

Web 應用程式的特點

1. 介面設計：
   • Web 應用程式提供了一個介面（通常是圖形用戶介面，GUI），使用者可透過鍵盤、滑鼠或觸控設備來輸入資料，並存取應用程式。
   • 它支援多種程式語言，如 JavaScript、HTML 和 CSS，並通常結合 SQL 等其他程式語言來與資料庫進行互動。
2. 動態網頁技術：
   • Web 應用程式通常以動態網頁的形式開發，允許使用者與伺服器進行互動式通信。
   • 它們可執行特定任務，如搜尋資料、傳送郵件、連接朋友、在線購物、追蹤與追查等。
3. 應用環境和執行技術：
   • Web 應用程式執行於各種伺服器上，並透過 HTTP 協議來傳輸資料。
   • 常見的 Web 伺服器包括 Microsoft IIS、Apache HTTP Server、H2O、LiteSpeed 和 Cherokee 等。

Web 應用程式的運作方式 (How Web Applications Work)

1. 用戶端瀏覽器：使用者在瀏覽器中輸入 URL（例如 https://certifiedhacker.com) 來發送登入請求。
2. 伺服器與防火牆：請求經過操作系統的系統呼叫 (OS System Calls) 進入 Web 伺服器。若防火牆允許，則請求會傳遞至資料庫管理系統 (DBMS)。
3. 資料存取與回應：資料庫根據請求進行資料存取，並透過 Web 應用程式伺服器 (Web Application Server) 回傳資料至用戶端。結果顯示在瀏覽器上，如 ID、主題 (Topic)、文本 (Text) 等資訊。

安全性風險

雖然 Web 應用程式執行了某些安全政策，但它們仍然容易受到以下攻擊的威脅：

• SQL Injection (SQL 注入攻擊)
• Cross-Site Scripting (跨站腳本攻擊)
• Session Hijacking (會話劫持)

這些攻擊方式可能會利用 Web 應用程式的漏洞，並對伺服器或應用程式內部資料進行未經授權的存取。

Web 應用程式的應用與服務

許多組織會開發 Web 應用程式來透過網路提供各種服務。使用者通常會透過提交 URL（統一資源識別碼，URI）來訪問這些服務。該 URL 包含網頁應用程式的資源路徑，由瀏覽器將請求發送至伺服器，伺服器接收請求後存取應用程式的資料並回傳結果。

Web 應用程式架構概述

Web 應用程式通常執行於網頁瀏覽器上，並使用多種伺服器端腳本語言（如 Java、C#、Ruby、PHP 等）以及用戶端腳本語言（如 HTML、JavaScript 等）來執行應用程式。Web 應用程式的運作原理依賴於它的架構設計，該架構包含硬體和軟體，負責處理請求（如讀取資料、搜尋、收集和顯示資料）。

Web 應用程式架構的三層結構

Web 應用程式架構通常包括以下三層結構：

1. Client or Presentation Layer (用戶端或展示層)
2. Business Logic Layer (商業邏輯層)
3. Database Layer (資料庫層)

1. 用戶端或展示層 (Client or Presentation Layer)

• 功能：這一層包括所有存在於用戶端的實體設備，如筆記型電腦、智慧型手機和電腦等。這些設備上安裝了作業系統並支援兼容的網頁瀏覽器，允許使用者透過瀏覽器向 Web 應用程式發送請求。
• 流程：使用者透過瀏覽器輸入 URL (例如 https://example.com)，請求會傳遞至 Web 伺服器，然後伺服器回應請求並提取所需的資料，應用程式會以網頁形式將資料顯示給用戶。

2. 商業邏輯層 (Business Logic Layer)

• 組成：商業邏輯層由兩部分組成：
  • Web 伺服器邏輯層 (Web-server Logic Layer)：包含防火牆、HTTP 請求解析器、代理快取伺服器、驗證及登入處理程序、資源處理器等多個元件。
  • 業務邏輯層 (Business Logic Layer)：負責處理應用程式的邏輯運算和業務規則。
• 處理流程：HTTP 請求解析器會解析來自客戶端的請求，然後根據需求傳送回應至客戶端。資源處理器負責處理多個請求的並行處理。當處理完畢後，Web 伺服器會讀取來自資料庫層的資料並回傳給客戶端。

3. 資料庫層 (Database Layer)

• 功能：資料庫層負責管理 Web 應用程式的所有資料存取操作。資料庫層中的資料可供 Web 伺服器讀取並傳遞至用戶端顯示。
• 範例：常見的 Web 伺服器包括 IIS (Internet Information Services) 和 Apache Web Server。

Web 應用程式的運作流程

• 使用者在瀏覽器中輸入 URL 並發送請求至伺服器。
• 請求通過網路進入 Web 伺服器，伺服器根據請求的內容訪問資料庫。
• 資料庫層處理資料並將結果傳遞回 Web 伺服器。
• Web 伺服器將結果回傳至客戶端，並在瀏覽器中以網頁的形式顯示。

Web 應用程式架構的優勢

這種分層架構設計讓 Web 應用程式具備更好的模組化設計，方便後續的擴展與維護。每一層的功能分工明確，有助於提升應用程式的效能和安全性。

使用範例

常見的 Web 伺服器架構設計，如：

• IIS Web Server：由微軟提供的 Internet Information Services，用於執行 ASP.NET 和其他 Web 應用程式。
• Apache Web Server：開源的 HTTP 伺服器，可用於執行 PHP 和其他網頁程式。

層級 1：Security（安全）

• 安全設備（IPS / IDS）：這一層涉及使用入侵預防系統（IPS）和入侵檢測系統（IDS）來防止或檢測網路和系統中的安全威脅。

層級 2：Network（網路）

• 路由器與交換器（Router / Switch）：網路層次中的設備，如路由器與交換器，可能會因配置錯誤或漏洞而成為攻擊目標。攻擊者可能會利用這些漏洞來進行網路竊聽或流量重定向。

層級 3：Operating System（作業系統）

• 作業系統（Windows / Linux / macOS）：作業系統層包含各種操作平台，攻擊者會嘗試利用作業系統中的漏洞（例如權限提升、緩衝區溢位）來取得系統控制權。

層級 4：Database（資料庫）

• 資料庫（Oracle / MySQL / MS SQL）：資料庫層容易成為SQL Injection（SQL注入）等攻擊的目標，攻擊者會利用這些漏洞來竊取、修改或刪除資料庫中的敏感資訊。

層級 5：Web Server（網頁伺服器）

• Apache / Microsoft IIS：這一層涉及到常見的Web Server軟體，例如Apache和IIS。攻擊者會針對這些伺服器進行攻擊，例如利用弱點和錯誤配置來植入惡意代碼或存取未授權的資源。

層級 6：Third-party Components（第三方元件）

• 開源或商業元件（Open Source / Commercial）：第三方軟體元件可能因版本不一致或未及時更新而導致漏洞。例如，未更新的開源框架可能成為跨站腳本（XSS）或遠端代碼執行攻擊的目標。

層級 7：Custom Web Applications（自定義Web應用）

• 業務邏輯漏洞（Business Logic Flaws）與技術性漏洞（Technical Vulnerabilities）：自定義Web應用通常包含特定的業務邏輯，若業務邏輯中存在錯誤，攻擊者可以利用邏輯缺陷進行欺騙或繞過認證流程。技術性漏洞包括跨站腳本（XSS）、SQL Injection、會話劫持（Session Hijacking）等常見Web應用攻擊。

Web Services（網路服務）

網路服務是一種應用程式或軟體，它部署於網際網路上，並使用標準的通訊協定如SOAP、UDDI、WSDL 及 REST 來實現不同平台之間的應用程式通訊。

網路服務通常用來解決分散式應用程式之間的互操作性問題，允許不同語言及平台的應用程式進行資訊交換。

Types of Web Services（網路服務類型）

1. SOAP Web Services
   • SOAP 是基於 XML 格式，用來在服務提供者與服務請求者之間傳遞資料。
   • SOAP 擁有嚴格的標準協定，適合企業級的應用程式整合。
2. RESTful Web Services
   • RESTful Web Services 基於 HTTP 協定中的一組**約束條件（constraints）**來進行通訊，藉此提升效能。
   • REST 更加輕量化且易於使用，適合於較為靈活的Web應用程式開發。

Web Service Architecture（網路服務架構）

• Service Provider（服務提供者）：提供特定服務，並包含服務的描述檔案。
• Service Registry（服務註冊中心）：保存服務描述，允許服務註冊及查詢。
• Service Requester（服務請求者）：提出服務需求，從註冊中心查詢服務描述，並依據描述與服務提供者進行通訊。

OWASP 2021 年十大應用程式安全風險（OWASP Top 10 Application Security Risks - 2021）

1. A01 - Broken Access Control（權限控制失效）

• 定義：
  權限控制失效表示應用程式無法正確地限制用戶存取其不應有權限訪問的資源，攻擊者可能繞過權限控制機制，以未授權的角色執行操作。
• 風險場景：
  • 攻擊者可以直接修改 URL、HTML 欄位或瀏覽器中的 Session Token，以繞過驗證機制存取受限資源。
  • 使用未經適當檢查的 API 請求存取高權限操作（如：刪除或修改資料）。
• 防範措施：
  • 實施強健的授權檢查，確保所有受限資源（如：敏感資料、後端 API）在每個請求中都被檢查。
  • 避免使用基於隱藏欄位、URL 參數或 Cookie 中的權限檢查方式，應採用後端檢查。
  • 實行「最小權限原則」，只授予用戶最低限度的存取權限。

2. A02 - Cryptographic Failures（加密失效）

• 定義：
  加密失效是指敏感資料在傳輸或儲存時未被加密，或是加密機制不當（如：使用過時的加密演算法），導致資料可能被未授權方解密和讀取。
• 風險場景：
  • 傳輸過程中使用 HTTP 而非 HTTPS，可能導致資料在傳輸過程中被攔截和竊取。
  • 使用過時的加密演算法（如：MD5、SHA1），使攻擊者能夠輕易破解密碼。
• 防範措施：
  • 強制使用 HTTPS 保護所有敏感資料的傳輸（例如：登入、交易、個人資料提交）。
  • 使用現代安全的加密演算法（如：AES 256, RSA 2048），並確保加密密鑰的安全儲存和管理。
  • 禁止在 Cookie 中存儲敏感資料，並啟用 Cookie 的安全標誌（如：Secure, HttpOnly）。

3. A03 - Injection（注入漏洞）

• 定義：
  注入漏洞指的是應用程式未正確處理來自使用者的輸入，直接將其作為指令執行（如 SQL 查詢），導致攻擊者能夠插入惡意指令。
• 風險場景：
  • SQL 注入：攻擊者可以利用應用程式中 SQL 查詢的漏洞，進行未授權資料讀取、寫入或刪除。
  • 命令注入：攻擊者將惡意命令注入系統執行（如：Shell Command）。
• 防範措施：
  • 使用參數化查詢或 ORM 來處理使用者輸入，避免直接將使用者輸入嵌入至查詢中。
  • 對所有輸入進行輸入驗證和過濾（如：白名單過濾）。
  • 使用最小權限原則運行資料庫，避免資料庫用戶擁有過多權限。

4. A04 - Insecure Design（不安全設計）

• 定義：
  不安全設計表示在系統設計階段未考慮安全性，缺乏威脅建模、安全設計原則，導致應用程式在開發前期就埋下安全風險。
• 風險場景：
  • 開發過程中未進行威脅建模或風險評估，無法預知和防範潛在風險。
  • 缺乏安全設計原則（如：最小權限、輸入驗證），導致整體系統架構不安全。
• 防範措施：
  • 在設計階段進行威脅建模與風險評估，確保系統架構設計時已考慮潛在風險。
  • 採用安全設計模式，如：多層防禦、最小權限、失敗安全原則。
  • 使用防火牆、隔離區（DMZ）等架構來分隔不同安全等級的區域。

5. A05 - Security Misconfiguration（安全配置錯誤）

• 定義：
  安全配置錯誤是指伺服器、資料庫、應用程式等配置不當，導致預設帳號、未受保護的端點、錯誤的權限設定等問題，使攻擊者能夠輕易利用這些配置錯誤進行攻擊。
• 風險場景：
  • 忘記禁用不必要的功能（如：測試介面、管理介面）或使用預設帳號和密碼。
  • 啟用過多或不安全的協議（如：FTP, Telnet）。
• 防範措施：
  • 定期審查並更新伺服器與應用程式的配置，移除不必要的功能及端點。
  • 停用預設帳號，變更預設密碼，並限制遠端存取。
  • 實施自動化工具（如：CIS 配置基準工具）來檢測和修正配置錯誤。

6. A06 - Vulnerable and Outdated Components（易受攻擊及過時的元件）

• 定義：
  使用含有已知漏洞的第三方元件（如：函式庫、API）或過時元件未被修補，可能被攻擊者利用已知漏洞進行攻擊，影響整個應用程式的安全性。
• 風險場景：
  • 使用包含已知漏洞的第三方套件（如：Struts, Log4j），導致應用程式被入侵或控制。
  • 未能及時更新開源軟體和框架，攻擊者利用已知漏洞入侵。
• 防範措施：
  • 定期檢查並更新所有第三方元件與套件版本，移除不再使用的元件。
  • 使用工具（如：OWASP Dependency-Check, Snyk）來自動檢測依賴性漏洞。
  • 建立元件管理策略，確保所有使用的元件來源可靠且有定期維護。

7. A07 - Identification and Authentication Failures（識別與身份驗證失敗）

• 定義：
  當應用程式未能正確地進行身份驗證或識別，導致攻擊者能夠冒充合法用戶進行未授權操作。
• 風險場景：
  • 使用弱密碼策略或允許重複使用已知弱密碼。
  • 忘記啟用雙因子驗證（2FA）等額外的身份驗證機制。
• 防範措施：
  • 啟用多因子驗證（MFA），強制使用強密碼策略（如：長度、複雜度限制）。
  • 使用身份驗證和授權框架（如：OAuth 2.0, OpenID Connect），確保身份驗證機制安全可靠。
  • 對身份驗證資料進行加密和保護（如：密碼雜湊）。

8. A08 - Software and Data Integrity Failures（軟體與資料完整性失效）

• 定義：
  當應用程式未能確保程式碼和資料的完整性時（如：未簽名的程式碼、無法驗證來源的更新），可能被攻擊者利用來執行惡意程式碼或篡改資料。
• 風險場景：
  • CI/CD 流程中未進行程式碼簽名，導致惡意程式碼被植入至正式環境中。
  • 使用來自不明來源的第三方庫或外部更新，遭到攻擊者篡改。
• 防範措施：
  • 強制程式碼簽名和完整性檢查，確保所有更新和第三方庫的合法性。
  • 使用版本控制系統

9. A09 - Security Logging and Monitoring Failures（安全日誌與監控失效）

• 定義：
  安全日誌與監控失效是指應用程式缺乏足夠的日誌記錄和監控機制，導致在安全事件發生時無法及時發現和應對，或是在安全事件之後無法進行追溯和調查。
• 風險場景：
  • 未對重要操作進行日誌記錄（例如：管理員登入、敏感資料修改、異常行為），使得攻擊行為未被察覺。
  • 日誌中未包含足夠的資訊（如：使用者 ID、時間戳、IP 位址），使得後續調查困難。
  • 日誌沒有定期備份、儲存位置不安全，可能導致日誌資料被篡改或刪除。
• 防範措施：
  • 針對所有重要行為（如登入、管理員操作、異常行為）進行詳細日誌記錄，並包含關鍵資訊（如：操作時間、使用者 ID、IP 地址、操作描述）。
  • 實施自動化日誌分析和監控工具，設置異常行為自動告警機制，以便快速發現和響應潛在威脅。
  • 儲存日誌於安全位置（如：集中式日誌伺服器），設定定期備份與資料保留策略。

10. A10 - Server-Side Request Forgery (SSRF)（伺服器端請求偽造）

• 定義：
  伺服器端請求偽造（SSRF）漏洞發生於應用程式接受使用者輸入並發送後端請求時，未能正確檢查輸入是否可被信任，導致攻擊者可以利用該漏洞替代伺服器發出偽造請求，存取內部系統或執行未預期操作。
• 風險場景：
  • 攻擊者向應用程式提交一個 URL，伺服器端將該 URL 當作請求地址，發送後端請求而未經驗證，導致攻擊者能夠透過 URL 獲取伺服器內部網路或敏感資料。
  • SSRF 可以被用來掃描內部網路端口、讀取內部文件或向內部服務發送未授權請求。
• 防範措施：
  • 限制伺服器端的請求地址，只允許請求白名單中的合法地址，並禁止向內部 IP 網段（如：127.0.0.1, 192.168.0.0/16）發送請求。
  • 對所有外部來源的 URL 輸入進行嚴格的驗證和過濾（如：過濾包含「file://」、「gopher://」、「ftp://」等協議的 URL）。
  • 實施網路隔離策略（如：內部網路與外部網路之間的網路隔離），並針對內部服務設定防火牆規則。