Riesgos al permitir que los usuarios carguen archivos HTML/JS

Question

Estamos diseñando una aracade en línea para juegos HTML5. Los usuarios pueden cargar un archivo zip que contiene su juego.

En carga, la cremallera es desempaquetado por el servidor y cada archivo se enlaza comprobando su extensión con una lista blanca que permite:

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

(Juegos deben hacerse en nuestro editor de juego que exporta esos archivos). Esto debe evitar que la gente la posibilidad de subir cremalleras, archivos de script del lado del servidor, etc, etc

Los juegos se mueven entonces hacia nuestro dominio sin cookies estática (scirra.net). Cuando el juego se juega en nuestra página scirra.com, el juego se muestra en un iframe que apunta al dominio scirra.net. Esto debería evitar que JS malintencionado acceda a las cookies de scirra.com.

¿Esta técnica iframe y lista blanca es lo suficientemente amplia para evitar que se haga algo malicioso? Tenga en cuenta que realmente no podemos examinar cada archivo JS, por lo que deberíamos suponer que las personas intentarán subir archivos JS maliciosos.

Answer 1

El origin inheritance rules for iframes evitará que el iframe scirra.net interfiera con scirra.com.

Esto sin embargo, no impide todos los ataques. En efecto, está introduciendo una vulnerabilidad XSS almacenada. XSS se puede utilizar para introducir ataques basados ​​en navegador, como la explotación de desbordamientos de búfer en componentes ActiveX. Explotando falws en Flash, Adobe Reader o Microsoft Office.

Debería considerar ejecutar un antivirus en el contenido de scirra.net. Aunque esto no evitará todos los ataques. La página ifram'ed podría redirigir o introducir otro iframe que contenga contenido malicioso.

Como señaló Cheeksoft. Las aplicaciones se podrán afectar entre sí con XSS. Una aplicación malintencionada podría obtener acceso a otra aplicación offline storage u obtener otros datos incrustados en otra aplicación. Obligar a cada aplicación a tener su subdominio mitigará este problema. Puede configurar un registro DNS para apuntar * .scirra.net a su servidor y cuidar el nombre de dominio dentro de su aplicación web.

Answer 2

¿Qué hay de incorporar algunas características de selección en el editor del juego que usted suministra? Elimine las referencias a URL externas, realice validación de código, verifique la codificación, etc.

Debería bloquear el archivo zip para evitar manipulaciones, pero eso podría ser una buena idea de todos modos.

Answer 3

Para cualquier otra persona leyendo esto, hay una experimental/beta iFrame atributo caja de arena:

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

Nota sólo funciona actualmente en Chrome y Opera. Esto le permite especificar algunas características restrictivas.

Sin embargo, en el caso de nuestra pregunta, hemos descartado la idea y hemos decidido que, debido a que estamos en la posición ventajosa de tener un programa creador de juegos, podemos simplemente cargar al usuario los datos de Json garantizados. seguro con las funciones principales del motor alojadas por nosotros.

Cualquier complemento que podamos revisar manualmente y aprobar para su uso es un trabajo mucho más pequeño que la aprobación manual de cada juego.