深入解析JavaScript XSS防禦函數的常見漏洞與改進策略

本文深入探討了自定義JavaScript XSS防禦函數中常見的安全漏洞，特別是字符轉義不完整和基於關鍵字的過濾易被繞過的問題。通過分析一個示例函數，揭示了引號、反引號等關鍵字符未處理的風險，以及代碼混淆技術如何規避簡單關鍵詞檢測。文章強調了上下文敏感轉義的重要性，並建議採用成熟的庫和多層防禦策略，以構建更健壯的安全防護。

XSS（跨站腳本）攻擊是Web應用中最常見的安全漏洞之一，它允許攻擊者在受害用戶的瀏覽器中執行惡意腳本。為了防範此類攻擊，開發者通常會對用戶輸入進行轉義處理。然而，編寫一個真正安全的自定義轉義函數並非易事，稍有疏忽便可能引入新的漏洞。本文將深入分析一個常見的JavaScript XSS防禦函數，揭示其潛在的安全隱患，並提供更健壯的防禦策略。

現有防禦函數的局限性分析

考慮以下一個嘗試進行XSS防禦的JavaScript函數：

 function escape(s) {
    s = s.toString()
    if (s.length > 100) { throw new Error("Too long!") }
    s = s.replace(/./g, function(x) {
        return { '': '>', '&': '&amp'}[x] || x;
    });
    if (s.match("prompt") || s.match("alert")) { throw new Error("XSS caught") }
    return "<div>" s "</div>"
}

這個函數旨在通過以下方式增強安全性：

1. 將輸入轉換為字符串。
2. 限制輸入長度，防止過長的惡意載荷。
3. 將HTML特殊字符、& 轉義為對應的HTML實體。
4. 檢查並阻止包含"prompt" 或"alert" 關鍵字的輸入。
5. 將處理後的字符串包裹在
   標籤中返回。

   儘管該函數採取了一些防禦措施，但仍存在以下關鍵漏洞：

   1. 不完整的HTML實體轉義

   當前函數僅轉義了 和&。然而，在HTML上下文中，尤其是在屬性值中，單引號（'）、雙引號（"）和反引號（`）同樣是至關重要的。如果用戶輸入被放置在HTML屬性中（例如 或），而這些引號未被轉義，攻擊者可以輕易地閉合屬性並註入新的屬性或事件處理器。

   示例攻擊場景：假設上述escape 函數的輸出

   ...

   後來被嵌入到另一個元素的屬性中，例如：

   如果userInput 為test" onclick="alert(1)，則escape(userInput) 返回

   test" onclick="alert(1)

   。當其被嵌入到data-content 屬性時，最終的HTML會變成：

   這裡的" 會提前閉合data-content 屬性，onclick="alert(1) 將作為新的屬性被瀏覽器解析執行。

   即使escape 函數明確返回

   標籤，一個更全面的HTML轉義函數也應該考慮轉義所有可能導致上下文逃逸的字符，以確保其在任何HTML上下文中的安全性。

   2. 基於關鍵字的過濾易被繞過

   函數中對"prompt" 和"alert" 關鍵字的檢查是一種常見的防禦嘗試，但這種基於黑名單的過濾方法非常脆弱。攻擊者可以通過多種方式混淆惡意代碼，從而繞過此類檢測：

   • 字符串拼接： pro mpt
   • 編碼：使用HTML實體編碼（alert）、URL編碼（alert）、JavaScript Unicode轉義（\u0061\u006c\u0065\u0072\u0074）或十六進制轉義。
   • 函數引用： window['al' 'ert'](1) 或[].find.constructor('alert(1)')()。
   • 模板字符串： alert\1`` （如果反引號未被轉義）。

   這些方法使得簡單的字符串匹配變得毫無意義，攻擊者可以輕鬆地執行alert() 或prompt() 等函數，而不會觸發防禦機制。

   3. 長度限制的局限性

   雖然限制輸入長度（如100字符）是一個良好的實踐，有助於緩解某些類型的攻擊（如內存耗盡或SQL注入），但對於XSS而言，短小精悍的惡意代碼同樣可以造成巨大危害。例如， 這樣的載荷通常遠低於100字符，卻足以執行攻擊。因此，長度限制不能替代嚴格的輸入驗證和轉義。

   構建更健壯的XSS防禦策略

   鑑於上述漏洞，構建一個真正安全的XSS防禦機制需要更全面和上下文敏感的方法。

   1. 採用上下文敏感的轉義

   XSS防禦的核心原則是“輸出編碼”，即根據數據將被插入的HTML上下文來選擇正確的編碼方式。

   • HTML內容：當數據插入到HTML元素內部（如
     內容
     ）時，需要轉義、&。
   • HTML屬性：當數據插入到HTML屬性值中（如）時，需要轉義"、'、&。對於URL屬性，還需要進行URL編碼。
   • JavaScript上下文：當數據插入到<script> 標籤內部或事件處理器中時，需要進行JavaScript字符串轉義，將所有非字母數字字符轉義為\xHH 或\uHHHH 形式。</script>

   一個更全面的HTML內容轉義函數應至少包含對引號和反引號的轉義：

    function escapeHtmlContent(s) {
       s = String(s); // 確保是字符串// 轉義HTML特殊字符，包括引號和反引號return s.replace(/[&"'`]/g, function(c) {
           switch (c) {
               case '': return '>';
               case '&': return '&';
               case '"': return '"';
               case "'": return '''; // 或'
               case '`': return '`'; // 或`
               default: return c;
           }
       });
   }
   
   // 示例使用// console.log("<div>" escapeHtmlContent("<img  src="x" onerror="'alert(1)'" alt="深入解析JavaScript XSS防禦函數的常見漏洞與改進策略" >") "</div>");
   // 輸出: <div><img  src="x" onerror="'alert(1)'" alt="深入解析JavaScript XSS防禦函數的常見漏洞與改進策略" ></div>

   請注意，即使是上述函數，也僅適用於將數據作為純HTML內容插入的情況。如果數據要插入到JavaScript代碼中，則需要完全不同的轉義策略。

   2. 優先使用成熟的XSS防護庫或API

   自行編寫XSS防禦函數極易出錯且難以維護。強烈建議使用經過安全專家審查和廣泛測試的第三方庫或瀏覽器原生API：

   • DOMPurify：這是一個功能強大且高度安全的HTML淨化庫，它通過白名單的方式移除所有潛在的惡意內容，只保留安全的HTML。
   • Google Caja (HTML Sanitizer API)：雖然更複雜，但

以上是深入解析JavaScript XSS防禦函數的常見漏洞與改進策略的詳細內容。更多資訊請關注PHP中文網其他相關文章！