Beyond XSS 2-4 ~ 2-7 #3

steven4program · 2024-12-05T08:00:24Z

steven4program
Dec 5, 2024
Collaborator

《Beyond XSS》從 XSS 開始談前端資安 2-4 ~ 2-7

20241114 2-4~2-7

導讀人：Mi
筆記工：Steven

2-4章節回顧

什麼是 Sanitizer API，主要優缺點和它如何幫助防止XSS？

Sanitizer API 是瀏覽器提供的內建 sanitizer，作用就如同 DOMPurify 的功用一樣，會將不安全的 HTML 內容移除，即使是設定 allow 危險的內容也一樣是會被移除，如下：

<!DOCTYPE html>
<html>
<body>
  <div id="content"></div>
  <script>
    const html = `
      Hello, this is my channel:
      <iframe src=https://www.youtube.com/watch?v=123></iframe>
    `;

    const sanitizer = new Sanitizer({
      allowElements: ['iframe'], // 即使設定 allow，一樣會被過濾掉
      allowAttributes: {
        'iframe': ['src']
      }
    });

    document
      .querySelector("#content")
      .setHTML(html, { sanitizer });
  </script>
</body>
</html>

Sanitizer API 有定義一系列的 allow list，如果想新增的元素不在清單中，那無論如何都無法使用。優點就是不管怎麼用都不會出事，缺點就是會不夠彈性。

Trusted Types 是什麼，它如何防止XSS？

在 CSP 裡面新增 Trusted Types 之後就能啟動並保護 DOM API，強制瀏覽器在插入 HTML 時一定要先經過 Trusted Types 的處理。強制在可能出問題的 DOM API 使用 Trusted Types，以避免忘記處理使用者需求時，直接將未處理的字串當 HTML render 出來。如下：
使用方式：

<!DOCTYPE html>
<html>
<head>
  <meta http-equiv="Content-Security-Policy" content="require-trusted-types-for 'script'">
</head>
<body>
  <div id="content"></div>
  <script>
    // Create a new policy
    const sanitizePolicy = trustedTypes.createPolicy('sanitizePolicy', {
      // Define how to sanitize/escape
      createHTML: (string) => string
        .replace(/</g, "&lt;")
        .replace(/>/g, "&gt;")
    });

    // Generate TrustedHTML, not a plain string
    const safeHtml = sanitizePolicy.createHTML('<h1>hello</h1>');

    // Insert TrustedHTML into the DOM
    document.querySelector("#content").innerHTML = safeHtml;
  </script>
</body>
</html>

Sanitizer API 和 Trusted Types 可以結合使用嗎？
可以，這兩個 API 被視為解決不同問題的互補工具。雖然目前瀏覽器還不支援直接整合，但官方文件推薦在實作上將它們一起使用，以更完善地防止 XSS 攻擊。
為什麼 Sanitizer API 和 Trusted Types 目前僅在少數瀏覽器中支援？
這些新功能還處於早期階段，僅在 Chromium based 瀏覽器(Chrome, Edge, Brave...)中支援，Firefox 和 Safari 尚未支援。由於這些功能需要經過長時間的規範與測試，因此尚未成為主流，但未來有望被廣泛應用。

補充：

功能	Sanitizer API	Trusted Types
用途	清理和過濾不受信任的 HTML，確保插入 DOM 的內容安全	限制開發者對不安全 API 的直接操作，防止無意 XSS 引入
處理對象	使用者或外部輸入的 HTML 內容	開發者撰寫的所有可能引入 XSS 的操作（如 innerHTML、srcdoc）
主要應用場景	清理動態生成的 HTML 內容，如使用者輸入	開發人員開發時對 DOM 操作的限制，防範 XSS
操作方式	提供靈活的清理配置，自訂清理規則並清理插入的 HTML	強制要求「信任」的物件才可進行 DOM 操作
防範措施	過濾不安全標籤和屬性，防範惡意 HTML 注入	在開發時主動阻止不受信任的操作執行

2-5章節回顧

假設你的網站有以下的 Content Security Policy (CSP)設定，這樣的設置安全嗎？
```
<!DOCTYPE html>
<html>
<head>
  <meta http-equiv="Content-Security-Policy" content="default-src 'none'; script-src 'nonce-abc123';">
</head>
<body>
  <div id="userContent">
    <script src="https://example.com/my.js"></script>
  </div>
  <script nonce=abc123 src="app.js"></script>
</body>
</html>
```
Ans:
看起來很安全，但忘記設定一個指示：base-uri，這個標籤的作用是改變所有相對路徑所參考的設置，只要加上<base href="https://example.com/">，那麼 script 載入的腳本就會變為 https://example.com/app.js，攻擊者就可以載入自己 server 上的腳本。阻止的方式就是在 CSP 中加上 base-uri 的規則，如base-uri 'none'。

2-6章節回顧

什麼是 Mutation-based XSS (mXSS)？
藉由瀏覽器渲染 HTML 時自動調整元素位置的特性來實現攻擊。

<svg> 內不應該存在的標籤會被搬出 <svg>
<style> 標籤的內容會被解讀為文字
但若 <style> 的外層有 <svg>，則 <style> 的內容會解讀為 HTML 元素
結果如下

<svg></p><style><a id="</style><img src=1 onerror=alert1()>">

經 Sanitizer 解析為 DOM tree=>

<svg>
    <p></p> <!-- 瀏覽器把 <p> 變成 <p></p>-->
    <style>
        <a id="</style><img src=1 onerror=alert(1)>"></a>
    </style> <!-- 瀏覽器自動閉合 <svg>、<style> 及 <a> -->
</svg>

而上面的字串丟給 innerHTML，mutation 發生，所有的標籤都從 <svg> 跳了出來變成 =>

<svg></svg>
<p></p>
<!-- <style> 跳出來，導致 <a> 變成了純文字，因此 <style> 提前閉合 -->
<style><a id="</style> 
<!-- <img> 也從屬性變成了標籤，最終導致 XSS -->
<img src=1 onerror=alert(1)>
"></a>
</style>

Sanitizer 的主要流程包含以下哪一項？
A. 把輸入 HTML 字串轉為 DOM Tree
B. 自動偵測並修復 HTML 結構錯誤
C. 執行 JavaScript 來處理 HTML

Ans: A. 把輸入 HTML 字串轉為 DOM Tree

Sanitizer 會將輸入的 HTML 字串轉換為 DOM 樹，以便過濾不合法的標籤與屬性，但不會自動偵測和修復 HTML 結構錯誤。
在 <svg><p>hello</svg> 的範例中，瀏覽器的最終解析結果是什麼？
瀏覽器會將 <p> 及 hello 從 <svg> 標籤中「跳出來」，最後形成 <svg></svg><p>hello</p> 的結構。

2-7章節回顧

什麼是 Universal XSS (UXSS)？它與一般的 XSS 攻擊有什麼不同？
- UXSS 是利用瀏覽器或其內建的 plugin 的漏洞來攻擊。
- 過去在 Brave iOS app 上，有動態執行 JavaScript 程式碼，然後這些 JavaScript 程式碼的輸入又沒有經過過濾，於是就導致了 UXSS 的攻擊。程式碼類似於：
```
self.tab?.webview?.evaluateJavaScript("u2f.postLowLevelRegister(\(requestId, \(true) '\(version)')")
// version 是我們可以控制的，而這段程式碼又是執行在 top level
// 所以 sub frame 就可以對 parent 做攻擊，在其他 origin 上執行 XSS
```
- UXSS 與 XSS 的不同在於，XSS 是網站本身的安全性有漏洞導致；但 UXSS 是瀏覽器的漏洞，代表是只要出現，就算是靜態的網頁都可以被執行 XSS，也就是「無論在哪個網站都可以執行程式碼」。所以才會將 UXSS 稱為最強的 XSS，同時也突顯出定期更新瀏覽器到最新版本的重要性。

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Beyond XSS 2-4 ~ 2-7 #3

Uh oh!

{{title}}

Uh oh!

Replies: 0 comments

Select a reply

Uh oh!

Beyond XSS 2-4 ~ 2-7 #3

Uh oh!

steven4program Dec 5, 2024 Collaborator

《Beyond XSS》從 XSS 開始談前端資安 2-4 ~ 2-7

2-4章節回顧

2-5章節回顧

2-6章節回顧

2-7章節回顧

Replies: 0 comments

steven4program
Dec 5, 2024
Collaborator