Chrome擴展程序，內容腳本和XSS攻擊

Question

我聽說一個網站可能會出現危險的XSS攻擊，例如eval允許用戶輸入JS。我打算爲我的文本擴展擴展名（類型一些文本 - >按熱鍵 - >文本擴展）做類似的事情。

我將允許用戶粘貼一個普通的html字符串文本，然後以不錯的格式化方式查看它。它旨在用於粗體，下劃線等。爲此，我將在div中使用.innerHTML。我非常瞭解，惡意用戶會將邪惡的<script>元素置於純文本中，並試圖破壞我的擴展。這是我所關心的。

我的問題：

1. 我的擴展將以此爲HTML數據，並將其粘貼到其他網站內容編輯的要素（如Gmail，利用innerHTML與內容腳本）文本增加。 XSS也可能會影響這些網站。我應該關心這些網站嗎？ Imho，他們有責任清理他們的內容。
2. 我自己的擴展本身不會與任何服務器通信，除了鉻同步存儲服務器，其中它將以純文本形式存儲此數據。但是，我仍然在我的options.html頁面中使用innerHTML（提供交互式文本擴展操場）。 XSS也會以任何方式影響我的擴展嗎？根據我的理解，他們（黑客）將使用拷貝的我的擴展文件自己的電腦與自己的瀏覽器。我無法分辨出他們在這個意義上可能造成的傷害。

---

我希望有人有兩個鍍鉻的擴展和XSS如何工作可以拋出一些輕知識。如果我錯過了任何細節/不清楚，請告訴我。

更新：我剛剛意識到腳本元素不是通過innerHTML執行的，只有內聯事件處理程序。我知道使用CSP可以幫助我防止內部事件處理程序在我的擴展中執行。但是，其他網站，其中我的擴展將粘貼代碼。他們是否也不執行內聯事件處理程序js函數？在擴展

Answer 1

使用不慎的innerHTML會導致幾個（安全）問題，包括：

• 同一產地旁路（包括通用XSS，又名UXSS）。
• 特權升級。
• 隱私違規（例如引薦泄漏）。

您的建議使用innerHTML（從不受信任的來源獲取HTML並將其插入另一個沒有消毒的網站的contentEditable元素中）是不安全的。從理論上講，腳本不應該在contentEditable元素中執行，但如果不是這種情況，則會出現瀏覽器錯誤（例如in Firefox和in Chrome）。
對於記錄 - 將不可信內容分配給innerHTML是不安全的，除非文檔未與視圖關聯（例如，這種無視圖文檔可以使用DOMParser或document.implementation.createHTMLDocument）創建。請注意，儘管在這些文檔中分配innerHTML是安全的，但是完全不安全要將這些文檔中的元素插入到具有視圖的文檔中。有關XSS的一般信息，請參閱XSS article at OWASP。

當不可信內容管理在擴展的上下文中執行時，可能會發生特權升級。在內容腳本中，這僅限於跨網絡請求和一些其他擴展API，在擴展頁面中，這包括訪問擴展具有權限的所有擴展API。這具有深遠的影響，XSS在擴展中並不罕見。爲此，Chrome enforces a default content security policy for extensions using "manifest_version": 2。這大大降低了XSS在擴展中的影響，但它不是100％完美無瑕，您不應該使用CSP作爲不正確清理您分配給innerHTML的數據的藉口。

（一旦塵埃落定，我可以分享一些有影響力的現實世界的安全事故與CSP繞過）

對於您的具體情況（複製DOM樹到CONTENTEDITABLE元素在另一個文件），我建議的一個以下方法：

• 白名單：遞歸枚舉元素的所有子節點，如果它是一個安全元件（例如，「b」，「強」，「EM」只克隆元素，「我」，等等），並且只有在屬性是安全屬性時才複製該屬性。
• 黑名單：深入克隆一棵樹，並刪除所有不安全的元素和不安全的屬性（練習讀者：什麼是不安全的元素？提示：答案不容易，它取決於屬性）。

如果您沒有開始的DOM樹，請使用先前建議的方法之一（例如DOMParser）解析HTML。在選擇你選擇接受的元素和屬性時要小心。例如，this safeResponse.js file似乎是一個很好的開始（因爲它除去了一些看似安全的屬性以外的腳本標記和所有屬性），但事實並非如此。有人可以使用style屬性使元素透明並位於整個文檔的頂部，然後將鏈接置於href屬性中（鏈接前的空格被瀏覽器剝離）。當用戶點擊頁面中的任何位置時，腳本將在頁面的上下文中運行。 This patch for sendResponse.js解決了這個問題，並且結果可能對XSS是安全的（雖然例如可以通過style屬性中的CSS引用外部內容，但對隱私違規並不安全）。