We're designing an online aracade for HTML5 games. The users can upload a zip file which contains their game.

On upload, the zip is unpacked by the server and each file is looped checking it's extension against a white list allowing:

• .html
• .js
• .png
• .jpg
• .appcache
• .m4a
• .ogg

(Games must be made in our game editor which exports those files). This should prevent people uploading zips, server side script files etc etc.

The games are then moved onto our static cookieless domain (scirra). When the game is played on our scirra page the game is displayed in an iframe pointing to the scirra domain. This should prevent malicious JS from accessing scirra cookies.

Is this iframe technique and whitelist prehensive enough to prevent anything malicious from being done? Note we can't really screen each JS file so we should assume people are going to try uploading malicious JS.

We're designing an online aracade for HTML5 games. The users can upload a zip file which contains their game.

On upload, the zip is unpacked by the server and each file is looped checking it's extension against a white list allowing:

• .html
• .js
• .png
• .jpg
• .appcache
• .m4a
• .ogg

(Games must be made in our game editor which exports those files). This should prevent people uploading zips, server side script files etc etc.

The games are then moved onto our static cookieless domain (scirra). When the game is played on our scirra. page the game is displayed in an iframe pointing to the scirra domain. This should prevent malicious JS from accessing scirra. cookies.

Is this iframe technique and whitelist prehensive enough to prevent anything malicious from being done? Note we can't really screen each JS file so we should assume people are going to try uploading malicious JS.

• javascript
• security
• iframe
• whitelist

• 5 i know this might cause some flack, but you need an apple-like approval process. – Daniel A. White Commented Nov 22, 2011 at 14:28
• I think it also depends on what type of security are you interested in. Are you interested solely in protecting your servers or are you also interested in being sure that you are not hosting malicious code to your game players. If you are considering both cases, then you may have to do a bit more work to verify that the user isn't crafting (even within your editor) some crafty JavaScript that might exploit the gamer. – RLH Commented Nov 22, 2011 at 14:34
• @Daniel, it's just not really realistic for us. We have a large audience of people who would want to use this and would like a way to sandbox each game so that it's safe. I'm just really wondering if a JS run in a frame on a different domain can do any damage. – Tom Gullen Commented Nov 22, 2011 at 14:34
• @RLH what sort of JS could exploit the gamer? We're interested in both. – Tom Gullen Commented Nov 22, 2011 at 14:35
• 2 @Tom: window.location = http://somevirusinfestedsite. for starters. while (true) alert('haha'); (and it's variants) to stick another one out there. – Matt Commented Nov 22, 2011 at 14:49

3 Answers 3

The origin inheritance rules for iframes will prevent the scirra iframe from interfering with scirra..

This however, does not prevent all attacks. In effect you are introducing a stored XSS vulnerability. XSS can be used to introduce browser based attacks, such as exploiting buffer overflows in ActiveX ponents. Exploiting falws in Flash, Adobe reader or Microsoft Office.

You should consider running an anti-virus on the scirra content. Although this won't prevent all attacks. The ifram'ed page could redirect or introduce another iframe that contains malicious content.

As Cheeksoft pointed out. Apps will be able to affect each other with XSS. A malcious app could gain access to another application offline storage or obtain other data embedded in another app. Forcing each app to have its on sub-domain will mitigate this issue. You could setup a DNS record to point *.scirra to your server and take care of the domain name within your web app.

For anyone else reading this, there is an experimental/beta iFrame sandbox attribute:

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

Note it only currently works on Chrome and Opera. This allows you to specify some restricting features.

However in the case of our question we've scrapped the idea and have decided that because we are in the advantageous position of having a game creator program we can simply get the user to upload the Json data which is guaranteed to be safe with the core engine features being hosted by us.

Any plugins we can manually review and approve for use which is a much smaller job than manually approving every game.

What about incorporating some screening features in the game editor that you supply? Screen out references to external URLs, perform code validation, check for encoding, etc.

You would have to lock down the zip file to prevent tampering, but that might be a good idea anyway.