Beyond XSS 6-1~6-5

[Yo0GuitarIT]

Beyond XSS 6-1~6-5

Case study - 有趣的攻擊案例分享

• 日期：2025/02/06 @Tech-Book-Community
• 導讀人：Lulu
• 筆記工：Yo0
• Slider Here

6-1 差一點的 Figma XSS 章節回顧

1. 在 Figma 的 XSS 漏洞中，為何即使開發人員沒有將惡意內容插入 document，仍然會觸發 onerror 事件？

由於 innerHTML 的隱藏機制

let div = document.createElement("div");
div.innerHTML = "<img src=x onerror=alert(1)>";

即使 div 沒有插入到 document，瀏覽器仍然會嘗試載入圖片，並執行 onerror 事件處理程序！
也就是說，只要有一瞬間，攻擊者的輸入被放進 innerHTML，XSS 就可以被觸發。

2. Figma 在這次 XSS 測試中為何沒有真正被攻破，僅獲得「差一點成功的 XSS」回報？

Figma 的 CSP（內容安全政策）救了它：

script-src 'unsafe-eval' 'nonce-PVEIuETDG3R+8hIA6PqgIQ==' 'strict-dynamic';

沒有 unsafe-inline，所以即使成功觸發 onerror，XSS 還是無法真正執行惡意腳本。

6-2 繞過層層防禦：Proton Mail XSS 章節回顧

1. Proton Mail 的 XSS 漏洞是如何成功繞過原本的 DOMPurify sanitization？

• 由於不同於 HTML，SVG 解析方式不同，導致兩段程式碼解析結果完全不同

• 在 <div> 中：

  <div>
      <style>
          <a id="a"></a>
      </style>
  </div>

• 在 <svg> 中：

  <svg>
      <style>
          <a id="a"></a>
      </style>
  </svg>

• 瀏覽器解析：

  1. <div> 瀏覽器解析<style>：<a> 會被當成普通文字。
  2. <svg>瀏覽器解析<style>：<a> 會被當成標籤。

• 利用 <style> 內的屬性來，逃逸出原本的 HTML 限制，原本應該被當成 ID 屬性的內容，卻變成了一個 <img>標籤，成功 XSS。

  <svg>
      <style>
          <a id="</><img src=x onerror=alert(1)>"></a>
      </style>
  </svg>

2. 在 Proton Mail 的攻擊鏈中，結合那些攻擊？

✅ Sanitization Bypass（SVG 解析異常）

✅ Sandbox Bypass（新開視窗逃逸）

✅ CSP Bypass（Blob URL 內容檢查疏漏）

✅ CSS Injection（洩漏 Blob URL）

6-3 隱藏在 Payment 功能中的 Chrome 漏洞 章節回顧

1. 為什麼 Chrome 的 Payment Request API 會導致 XSS 漏洞？

• 瀏覽器收到 Payment Request API 的請求時，會去解析 金流服務的 URL，並且搜尋 manifest 檔案，這個過程包含以下步驟：

• 如果攻擊者可以控制這些 JSON 檔案，就能偷偷註冊惡意的 service worker！

  1. 讀取 Link header，獲取 payment-manifest.json

  2. 讀取 app_manifest.json，找到 service worker

  3. 透過 service worker 控制付款流程

2. 攻擊者如何利用 Payment Request API 來執行 XSS？

1. 攻擊者上傳三個 JSON 檔案與 service worker 到開放上傳的網站
   (files.example.com)：manifest.json / app_manifest.json / sw.js（惡意 Service Worker）。

2. 在惡意網站上 發送 Payment Request API 請求，指向 https://files.example.com/huli123/manifest.json。

3. 瀏覽器誤以為這是一個正常的支付請求，開始載入這些檔案。

4. 瀏覽器安裝攻擊者的 惡意 Service Worker，攻擊者即可攔截請求，並回傳 任意 JavaScript，觸發 XSS。

6-4 從 Prototype Pollution 到 Bitrix24 XSS 章節回顧

1. Bitrix24 的 XSS 漏洞是怎麼產生的？

// Todo: Answer

2. 在 Bitrix24 XSS 漏洞中，攻擊者如何進一步擴大影響？

// Todo: Answer

6-5 PHP 底層 bug 引發的 Joomla! XSS 章節回顧

1. Joomla! 的 XSS 漏洞是如何發生的？

• 處理多字節字串（像是中文、日文）時，會使用 mb_ 系列函式，因為像 substr() 這種函式是以 byte 為單位，可能會截斷 UTF-8 字元，導致亂碼問題。

• 如果字元編碼不合法，不同的函式會有不同的處理方式。

  $input = "\xE4\xBD\x61\x62\x63\x64<"; // UTF-8 編碼錯誤的字串
  $pos = mb_strpos($input, '<'); 
  $sub = mb_substr($input, 0, $pos);
  echo $sub;

  1. mb_strpos() 會忽略錯誤的 UTF-8 字元，因此它認為 < 在 第六個字
  2. mb_substr() 直接把錯誤的 UTF-8 當作合法字元處理，所以 < 變成了第五個字

• 錯誤的 mb_substr() 會取出未經處理的 <，導致 XSS。

2. Joomla! 最後是如何修復這個漏洞的？

1️. Joomla! 修復方式：
改用 strpos() 和 substr()，避免 mb_ 函式的不一致性

2️. PHP 修復方式：
修正 mb_substr() 的行為，讓它與 mb_strpos() 一致，確保不會誤判字串長度

問題不在 Joomla! 本身，而是在 PHP 的底層實作，所以 PHP 官方也發布了更新修復這個問題！

討論

1.Payment Request API 的安全漏洞解析

漏洞原理

• Payment Request API 原本允許直接從 response 讀取 manifest
• 修復後改為必須透過 HTTP Header 傳遞 manifest URL
• 這個改動的原因是為了防止跨站攻擊

攻擊手法詳解

前提條件

1. 目標網站 (victim.com) 允許上傳 .json 和 .js 檔案
2. 上傳的檔案可以透過 URL 訪問，但不會被執行
3. 攻擊者可以在任意網站執行 JavaScript

攻擊流程

1. 在 victim.com 上傳兩個檔案：

   • 惡意的 manifest.json
   • 惡意的 service worker (sw.js)

2. 從任意網站發起攻擊：

   • 使用 Payment Request API 請求 victim.com 的 manifest
   • 觸發 victim.com 註冊並執行惡意 service worker

攻擊特點

• 不需要在 victim.com 上執行 JavaScript
• 可以從任意網站發起攻擊
• 繞過了一般的 XSS 防護機制

安全修復方案

• 限制 manifest 只能透過 HTTP Header 傳遞
• 因為攻擊者通常無法控制 response header
• 有效防止了跨站的 service worker 註冊攻擊

URL 編碼與 API 參數處理

常見問題

1. 特殊字元造成的參數解析錯誤：
   • & 字元會被誤解為新參數的分隔符
   • + 字元會被解析為空格
   • / 字元在某些情況下需要編碼

範例說明

未編碼的問題

// 錯誤示範
fetch("/api/search?name=" + name)

// 當 name = "&a" 時：
// 變成 /api/search?name=&a
// 結果：name 變成空值，多出一個參數 a

正確處理方式

// 方法一：手動編碼
fetch("/api/search?name=" + encodeURIComponent(name))

// 方法二：使用現代 HTTP 客戶端
axios.get("/api/search", {
    params: {
        name: "要搜尋的字串"
    }
})

URL 編碼對照

• & → %26
• + → %2B
• / → %2F
• 空格 → %20 或 +

最佳實踐

1. 使用現成的 HTTP 客戶端（如 axios）

   • 自動處理參數編碼
   • 只需傳入物件即可

2. 如果要手動處理

   • 使用 encodeURIComponent()
   • 避免直接字串拼接

這樣的處理可以避免因特殊字元造成的參數解析錯誤，確保 API 呼叫的正確性。