Operazioni sicure con contenuto non attendibile

Adobe AIR 1.0 e versioni successive

Il contenuto non assegnato alla sandbox dell'applicazione può fornire funzionalità aggiuntive per la creazione di script alla vostra applicazione, ma solo che soddisfa i criteri di sicurezza del runtime. In questo argomento viene descritto il contratto di sicurezza di AIR per il contenuto non dell'applicazione.

Security.allowDomain()

Le applicazioni AIR limitano l'accesso con script per il contenuto non dell'applicazione in modo più rigido rispetto al modo in cui il plug-in Flash Player per browser limita l'accesso con script per il contenuto non attendibile. Nel browser in Flash Player, ad esempio, quando un file SWF assegnato alla sandbox local-trusted chiama il metodo System.allowDomain() , l'accesso con script viene concesso a qualsiasi file SWF caricato dal dominio specificato. L'approccio analogo dal contenuto application non è consentito nelle applicazioni AIR, in quanto verrebbe concesso al file non dell'applicazione un livello di accesso eccessivo nel file system dell'utente. I file remoti non possono accedere direttamente alla sandbox dell'applicazione, indipendentemente dalle chiamate al metodo Security.allowDomain() .

Creazione di script tra contenuto dell'applicazione e non dell'applicazione

Le applicazioni AIR che creano script tra contenuto dell'applicazione e non dell'applicazione sono previsti schemi di sicurezza più complessi. Ai file non presenti nella sandbox dell'applicazione è consentito l'accesso solo alle proprietà e ai metodi dei file presenti nella sandbox dell'applicazione mediante l'uso di un bridge sandbox. Un bridge sandbox funge da gateway tra il contenuto dell'applicazione e il contenuto non dell'applicazione, consentendo un'interazione esplicita tra i due file. Quando vengono usati correttamente, i bridge sandbox forniscono un ulteriore livello di sicurezza, impedendo al contenuto non dell'applicazione di accedere ai riferimenti agli oggetti che fanno parte del contenuto dell'applicazione.

Il vantaggio che deriva dall'uso dei bridge sandbox è illustrato più chiaramente da un esempio. Supponete di voler fare in modo che un'applicazione AIR per un negozio di musica fornisca un'API agli inserzionisti che desiderano creare file SWF personalizzati con cui l'applicazione possa quindi comunicare. Il negozio intende mettere a disposizione degli inserzionisti i metodi per la ricerca di artisti e CD nel negozio, isolando al contempo alcuni metodi e proprietà dal file SWF di terze parti, per motivi di sicurezza.

Questa funzionalità può essere fornita con un bridge sandbox. Per impostazione predefinita, il contenuto caricato esternamente in un'applicazione AIR in fase di runtime non dispone dell'accesso ad alcun metodo o proprietà nell'applicazione principale. Con un'implementazione di bridge sandbox personalizzato, lo sviluppatore può fornire i servizi al contenuto remoto senza esporre tali metodi e proprietà. Considerate il bridge sandbox come un percorso tra il contenuto attendibile e quello non attendibile, che fornisce la comunicazione tra il contenuto caricante e quello caricato senza esporre i riferimenti agli oggetti.

Per ulteriori informazioni sull'uso di bridge sandbox in modo sicuro, consultate Creazione di script tra contenuti in diversi domini .

Protezione dalla generazione dinamica di contenuto SWF non sicuro

Il metodo Loader.loadBytes() consente a un'applicazione di generare contenuto SWF da un array di byte. Tuttavia, gli attacchi mediante introduzione, o injection, di codice nei dati caricati da origini remote possono causare gravi danni durante il caricamento del contenuto, in particolare quando i dati vengono caricati nella sandbox dell'applicazione dove il contenuto SWF generato può accedere all'intero set di API AIR.

Vi sono tuttavia casi in cui l'uso del metodo loadBytes() è consentito, senza generare codice SWF eseguibile. Potete usare il metodo loadBytes() , ad esempio, per generare i dati di un'immagine per controllare la tempistica di visualizzazione dell'immagine. Vi sono anche usi consentiti che si basano effettivamente sull'esecuzione di codice, ad esempio per la creazione dinamica di contenuto SWF per la riproduzione audio. In AIR, per impostazione predefinita, il metodo loadBytes() non consente di caricare il contenuto SWF; consente solo di caricare il contenuto dell'immagine. In AIR, la proprietà loaderContext del metodo loadBytes() dispone di una proprietà allowLoadBytesCodeExecution , che potete impostare su true per consentire esplicitamente all'applicazione di utilizzare loadBytes() per caricare contenuto SWF eseguibile. Il codice riportato di seguito mostra come utilizzare questa funzione:

var loader:Loader = new Loader(); 
var loaderContext:LoaderContext = new LoaderContext(); 
loaderContext.allowLoadBytesCodeExecution = true; 
loader.loadBytes(bytes, loaderContext);

Se chiamate loadBytes() per caricare contenuto SWF e la proprietà allowLoadBytesCodeExecution dell'oggetto LoaderContext è impostata su false (il valore predefinito), l'oggetto Loader genera un'eccezione SecurityError.

Nota: in una futura versione di Adobe AIR questa API potrebbe essere modificata. In tal caso, potreste dover ricompilare il contenuto che utilizza la proprietà allowLoadBytesCodeExecution della classe LoaderContext.