2011-11-22 110 views
9

我们正在为HTML5游戏设计一个在线游戏。用户可以上传包含他们游戏的zip文件。允许用户上传HTML/JS文件的风险

在上传时,拉链是由服务器解压缩每个文件进行循环检查它的扩展对一个白名单允许:

  • 的.html
  • 的.js
  • png格式
  • 。 JPG
  • .appcache
  • .M4A
  • .OGG

(游戏必须在导出这些文件的游戏编辑器中制作)。这应该防止人们上传zip文件,服务器端脚本文件等等。

然后游戏被移到我们的静态无Cookie域(scirra.net)。当我们在scirra.com页面上玩游戏时,游戏显示在指向scirra.net域的iframe中。这应该可以防止恶意JS访问scirra.com cookie。

这是iframe技术和白名单足够全面,以防止任何恶意的做法?请注意,我们不能真正筛选每个JS文件,因此我们应该假设人们将尝试上传恶意JS。

+5

我知道这可能会导致一些瑕疵,但您需要一个类似苹果的审批流程。 –

+0

我认为这也取决于您感兴趣的安全类型。您是否仅对保护您的服务器感兴趣,或者您是否有兴趣确保不会将恶意代码托管给游戏玩家。如果您正在考虑这两种情况,那么您可能需要做更多的工作来验证用户是否在制作(即使在您的编辑器中)一些可能会利用游戏玩家的狡猾JavaScript。 – RLH

+0

@Daniel,这对我们来说并不现实。我们有大量的人想要使用它,并想要一种方式来对每个游戏进行沙盒处理,以保证它的安全。我只是真的想知道,如果一个JS运行在不同域的框架上可能会造成任何损害。 –

回答

4

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应用程序中处理域名。

+1

如果您将所有提交的应用程序托管在同一个域中,则可能已针对您的域停止存储(并反映)xss,但是一个恶意应用程序可以对所有其他应用程序执行xss攻击。从他们自己动态生成的域名中提取每个域名,并尝试并说服开发人员始终将他们的Cookie设置为myapp.scirra.net,并且从不设置scirra.net。 – Cheekysoft

+0

@Cheekysoft是的,这是一个很好的观点。我没有考虑这个媒介,可能有其他应用程序或脱机js存储系统中存储的有价值的信息。 – rook

1

如何在您提供的游戏编辑器中加入一些筛选功能?屏蔽掉对外部URL的引用,执行代码验证,检查编码等。

您将不得不锁定zip文件以防止篡改,但无论如何,这可能是个好主意。

0

为别人读这篇文章,有一个实验/测试的iFrame沙盒属性:

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox

注意它目前只适用于Chrome和Opera。这使您可以指定一些限制功能。

但是,在我们的问题的情况下,我们已经放弃了这个想法,并决定,因为我们处于有一个游戏创作者程序的优势地位,我们可以简单地让用户上传Json数据,这是保证是安全的核心引擎功能由我们托管。

任何插件,我们可以手动审查和批准使用这是一个比手动批准每一个游戏小得多的工作。