Riscos ao permitir que usuários carreguem arquivos HTML / JS

9

Estamos criando um aracade on-line para jogos em HTML5. Os usuários podem fazer upload de um arquivo zip que contenha seu jogo.

No upload, o zip é descompactado pelo servidor e cada arquivo é colocado em loop, verificando sua extensão em relação a uma lista branca, permitindo:

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

(Jogos devem ser feitos no nosso editor de jogos que exporta esses arquivos). Isso deve impedir que as pessoas façam upload de zips, arquivos de script do servidor, etc. etc.

Os jogos são então movidos para o nosso domínio estático cookieless (scirra.net). Quando o jogo é jogado em nossa página scirra.com, o jogo é exibido em um iframe apontando para o domínio scirra.net. Isso deve impedir que o JS malicioso acesse os cookies do scirra.com.

Essa técnica de iframe e whitelist é abrangente o suficiente para impedir que algo malicioso seja feito? Note que não podemos realmente filtrar cada arquivo JS, então devemos supor que as pessoas tentarão enviar o JS malicioso.

    
por Tom Gullen 22.11.2011 в 15:26

3 respostas

4

As regras de herança de origem para iframes impedirão que o iframe scirra.net interfira com o scirra .com.

Isso, no entanto, não impede todos ataques. Na verdade, você está introduzindo uma vulnerabilidade de XSS armazenada. O XSS pode ser usado para introduzir ataques baseados em navegador, como a exploração de buffer overflows em componentes ActiveX. Explorando falws no Flash, no Adobe Reader ou no Microsoft Office.

Você deve considerar a execução de um antivírus no conteúdo do scirra.net. Embora isso não impeça todos os ataques. A página iframed pode redirecionar ou introduzir outro iframe que contenha conteúdo mal-intencionado.

Como Cheeksoft apontou. Os aplicativos poderão afetar uns aos outros com o XSS. Um aplicativo mal-intencionado poderia obter acesso a outro armazenamento offline ou obter outros dados incorporados em outro aplicativo. Forçar o acesso de cada aplicativo ao subdomínio atenua esse problema. Você pode configurar um registro DNS para apontar * .scirra.net para o seu servidor e cuidar do nome de domínio dentro do seu aplicativo da web.

    
por rook 22.11.2011 / 16:30
1

Que tal incorporar alguns recursos de triagem no editor de jogos que você fornece? Exclua referências a URLs externos, realize a validação de código, verifique a codificação, etc.

Você teria que bloquear o arquivo zip para evitar adulterações, mas isso pode ser uma boa ideia de qualquer maneira.

    
por schroeder 22.11.2011 / 19:20
0

Para qualquer pessoa que esteja lendo isso, há um atributo de sandbox experimental / beta iFrame:

link

Observe que atualmente só funciona no Chrome e no Opera. Isso permite que você especifique alguns recursos de restrição.

No entanto, no caso de nossa pergunta, descartamos a ideia e decidimos que, por estarmos na posição vantajosa de ter um programa de criação de jogos, podemos simplesmente fazer com que o usuário faça o upload dos dados do Json, o que é garantidamente seguro com os principais recursos do mecanismo hospedados por nós.

Qualquer plug-in que possamos revisar e aprovar manualmente para uso é um trabalho muito menor do que aprovar manualmente todos os jogos.

    
por Tom Gullen 22.11.2011 / 19:46