我們正在爲HTML5遊戲設計一個在線遊戲。用戶可以上傳包含他們遊戲的zip文件。允許用戶上傳HTML/JS文件的風險
在上傳時，拉鍊是由服務器解壓縮每個文件進行循環檢查它的擴展對一個白名單允許：
（遊戲必須在導出這些文件的遊戲編輯器中製作）。這應該防止人們上傳zip文件，服務器端腳本文件等等。
然後遊戲被移到我們的靜態無Cookie域（scirra.net）。當我們在scirra.com頁面上玩遊戲時，遊戲顯示在指向scirra.net域的iframe中。這應該可以防止惡意JS訪問scirra.com cookie。
這是iframe技術和白名單足夠全面，以防止任何惡意的做法？請注意，我們不能真正篩選每個JS文件，因此我們應該假設人們將嘗試上傳惡意JS。
origin inheritance rules for iframes將阻止scirra.net iframe干擾scirra.com。
但是，這並不妨礙全部攻擊。實際上，您正在引入存儲的XSS漏洞。 XSS可用於引入基於瀏覽器的攻擊，例如利用ActiveX組件中的緩衝區溢出。在Flash，Adobe閱讀器或Microsoft Office中開發falws。
您應該考慮在scirra.net內容上運行防病毒軟件。雖然這不會阻止所有攻擊。 ifram的頁面可能會重定向或引入另一個包含惡意內容的iframe。正如Cheeksoft指出的那樣：
。應用程序將能夠通過XSS互相影響。一個有害的應用程序可以訪問另一個應用程序offline storage或獲取嵌入在另一個應用程序中的其他數據。強制每個應用程序在其子域上都可以緩解這個問題。您可以設置DNS記錄，將* .scirra.net指向您的服務器，並在您的Web應用程序中處理域名。
如果您將所有提交的應用程序託管在同一個域中，則可能已針對您的域停止存儲（並反映）xss，但是一個惡意應用程序可以對所有其他應用程序執行xss攻擊。從他們自己動態生成的域名中提取每個域名，並嘗試並說服開發人員始終將他們的Cookie設置爲myapp.scirra.net，並且從不設置scirra.net。 – Cheekysoft
@Cheekysoft是的，這是一個很好的觀點。我沒有考慮這個媒介，可能有其他應用程序或脫機js存儲系統中存儲的有價值的信息。 – rook
如何在您提供的遊戲編輯器中加入一些篩選功能？屏蔽掉對外部URL的引用，執行代碼驗證，檢查編碼等。
您將不得不鎖定zip文件以防止篡改，但無論如何，這可能是個好主意。
爲別人讀這篇文章，有一個實驗/測試的iFrame沙盒屬性：
注意它目前只適用於Chrome和Opera。這使您可以指定一些限制功能。
但是，在我們的問題的情況下，我們已經放棄了這個想法，並決定，因爲我們處於有一個遊戲創作者程序的優勢地位，我們可以簡單地讓用戶上傳Json數據，這是保證是安全的核心引擎功能由我們託管。
任何插件，我們可以手動審查和批准使用這是一個比手動批准每一個遊戲小得多的工作。
我知道這可能會導致一些瑕疵，但您需要一個類似蘋果的審批流程。 –
我認爲這也取決於您感興趣的安全類型。您是否僅對保護您的服務器感興趣，或者您是否有興趣確保不會將惡意代碼託管給遊戲玩家。如果您正在考慮這兩種情況，那麼您可能需要做更多的工作來驗證用戶是否在製作（即使在您的編輯器中）一些可能會利用遊戲玩家的狡猾JavaScript。 – RLH
@Daniel，這對我們來說並不現實。我們有大量的人想要使用它，並想要一種方式來對每個遊戲進行沙盒處理，以保證它的安全。我只是真的想知道，如果一個JS運行在不同域的框架上可能會造成任何損害。 –