Menu
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:
(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.net). When the game is played on our scirra.com page the game is displayed in an iframe pointing to the scirra.net domain. This should prevent malicious JS from accessing scirra.com cookies.
Is this iframe technique and whitelist comprehensive 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.
622
Upload forms on web pages can be dangerous because they allow attackers to upload malicious code to the web server. Attackers can then use tricks to execute this code and access sensitive information or even take control of the server.
Using a file upload helps the attacker accomplish the first step. The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system or database, forwarding attacks to back-end systems, client-side attacks, or simple defacement.
What are file upload vulnerabilities? File upload vulnerabilities are when a web server allows users to upload files to its filesystem without sufficiently validating things like their name, type, contents, or size.
However many web application does not have proper security check during uploading files and this results in a vulnerability called File Upload Vulnerability. This one simple vulnerability leads to server-side scripting, arbitrary code execution, cross-site scripting, and CSRF attacks.
The origin inheritance rules for iframes will prevent the scirra.net iframe from interfering with scirra.com.
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 components. Exploiting falws in Flash, Adobe reader or Microsoft Office.
You should consider running an anti-virus on the scirra.net 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.net to your server and take care of the domain name within your web app.
54
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
