Rischi nel consentire agli utenti di caricare file HTML/JS

Question

Stiamo progettando un aracade online per i giochi HTML5. Gli utenti possono caricare un file zip che contiene il loro gioco.

Sul caricati, la cerniera viene estratto dal server e ogni file è in loop controllando è un'estensione contro una lista bianca che consente:

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

(I giochi devono essere creati nel nostro editor di giochi che esporta quei file). Ciò dovrebbe impedire alle persone di caricare zip, file di script sul lato server ecc.

I giochi vengono quindi spostati nel nostro dominio statico senza cookie (scirra.net). Quando il gioco viene giocato sulla nostra pagina scirra.com, il gioco viene visualizzato in un iframe che punta al dominio scirra.net. Questo dovrebbe impedire a JS malintenzionato di accedere ai cookie di scirra.com.

Questa tecnica e whitelist iframe è sufficientemente completa da impedire che venga fatto qualcosa di malevolo? Nota che non è possibile eseguire lo screening di ogni file JS, quindi dovremmo pensare che le persone provino a caricare JS dannoso.

Answer 1

Il origin inheritance rules for iframes impedirà che l'iframe di scirra.net interferisca con scirra.com.

Ciò tuttavia non impedisce gli attacchi all. In effetti si sta introducendo una vulnerabilità XSS memorizzata. XSS può essere utilizzato per introdurre attacchi basati su browser, come lo sfruttamento dei buffer overflow nei componenti ActiveX. Sfruttare falso in Flash, Adobe Reader o Microsoft Office.

È consigliabile prendere in considerazione la possibilità di eseguire un anti-virus sul contenuto di scirra.net. Anche se questo non impedirà tutti gli attacchi. La pagina ifram potrebbe reindirizzare o introdurre un iframe contenente contenuti dannosi.

Come ha sottolineato Cheeksoft. Le app saranno in grado di influenzarsi a vicenda con XSS. Un'applicazione malcious potrebbe accedere ad un'altra applicazione offline storage o ottenere altri dati incorporati in un'altra app. Costringere ogni app ad avere il suo sottodominio attenuerà questo problema. È possibile impostare un record DNS in modo che punti * .scirra.net sul server e si occupi del nome di dominio all'interno della propria app Web.

Answer 2

Che ne dici di incorporare alcune funzionalità di screening nell'editor di giochi che fornisci? Eliminare i riferimenti agli URL esterni, eseguire la convalida del codice, verificare la codifica, ecc.

Si dovrebbe bloccare il file zip per evitare manomissioni, ma potrebbe comunque essere una buona idea.

Answer 3

Per chiunque altro leggendo questo, c'è un sperimentale/beta iFrame attributo sandbox:

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

Nota solo attualmente funziona su Chrome e Opera. Questo ti permette di specificare alcune funzionalità limitanti.

Tuttavia, nel caso della nostra domanda abbiamo scartato l'idea e abbiamo deciso che, poiché siamo nella posizione vantaggiosa di avere un programma di creazione di giochi, possiamo semplicemente far caricare l'utente sui dati Json che è garantito essere sicuro con le caratteristiche principali del motore che sono ospitate da noi.

Qualsiasi plug-in è possibile esaminare e approvare manualmente per l'uso, che è un compito molto più piccolo rispetto all'approvazione manuale di ogni gioco.