Controlli di autorizzazione

Flash Player 9 e versioni successive, Adobe AIR 1.0 e versioni successive

Il modello di sicurezza della fase di runtime del client di Flash Player è stato progettato a partire da risorse quali file SWF, dati locali e URL Internet. Gli stakeholder sono le parti che possiedono o utilizzano tali risorse. Gli stakeholder possono controllare le proprie risorse (mediante impostazioni di sicurezza) e ogni risorsa presenta quattro stakeholder. Flash Player applica in maniera rigorosa una gerarchia di autorità per tali controlli, come illustrato nel grafico seguente:

Gerarchia di autorità
Gerarchia dei controlli di sicurezza

Ciò significa, ad esempio, che se un amministratore limita l'accesso a una risorsa, nessun altro stakeholder può ignorare tale restrizione.

Per applicazioni AIR, questi controlli si applicano solo al contenuto in esecuzione all'esterno dell'applicazione AIR.

Controlli amministratore

L'amministratore di un computer (utente che ha eseguito l'accesso con privilegi amministrativi) può applicare impostazioni di sicurezza di Flash Player valide per tutti gli utenti del computer. In un ambiente non aziendale, come nel caso di un computer domestico, vi è in genere un utente con accesso di amministratore. Anche in un ambiente aziendale, i singoli utenti possono disporre di diritti amministrativi.

Esistono due tipi di controlli amministratore:

  • File mms.cfg

  • directory Global Flash Player Trust.

File mms.cfg

Il file mms.cfg è un file di testo che consente agli amministratori di autorizzare o limitare l'accesso a un'ampia gamma di funzionalità. All'avvio, Flash Player legge le impostazioni di sicurezza da questo file e le impiega per limitare le funzionalità. Il file mms.cfg comprende impostazioni che vengono utilizzate dall'amministratore per gestire funzionalità quali i controlli della riservatezza, la sicurezza dei file locali, le connessioni socket e così via.

I file SWF possono accedere ad alcune informazioni sulle funzionalità che sono state disattivate mediante chiamata delle proprietà Capabilities.avHardwareDisable e Capabilities.localFileReadDisable . Tuttavia, la maggior parte delle informazioni contenute nel file mms.cfg non possono essere interrogate da ActionScript.

Per imporre criteri di riservatezza e sicurezza indipendenti dall'applicazione a un computer, il file mms.cfg dovrebbe essere modificato unicamente dagli amministratori di sistema. Il file mms.cfg non deve essere utilizzato dagli installatori di applicazioni. Nonostante sia possibile per un installatore con privilegi di amministratore modificare il contenuto del file mms.cfg file, Adobe considera tale comportamento una violazione della fiducia dell'utente ed esorta pertanto gli installatori a non modificare tale file.

Il file mms.cfg viene archiviato nel percorso seguente:

  • Windows: system \Macromed\Flash\mms.cfg

    (ad esempio, C:\WINDOWS\system32\Macromed\Flash\mms.cfg)

  • Mac: app support /Macromedia/mms.cfg

    (ad esempio, /Library/Supporto Applicazioni/Macromedia/mms.cfg)

Per ulteriori informazioni sul file mms.cfg, vedete la guida per l'amministrazione di Flash Player all'indirizzo www.adobe.com/go/flash_player_admin_it .

La directory Global Flash Player Trust

Le applicazioni di utenti e installatori con privilegi di amministratore sono in grado di registrare file SWF locali specifici come affidabili per tutti gli utenti. Tali file SWF vengono assegnati alla sandbox locale affidabile. Questi file possono interagire con qualunque altro file SWF e possono caricare dati sia in remoto che in locale. I file vengono designati come affidabili all’interno della directory Global Flash Player Trust, che si trova nel seguente percorso:

  • Windows: system \Macromed\Flash\FlashPlayerTrust

    (ad esempio, C:\WINDOWS\system32\Macromed\Flash\FlashPlayerTrust)

  • Mac: app support /Macromedia/FlashPlayerTrust

    (ad esempio, /Library/Supporto Applicazioni/Macromedia/FlashPlayerTrust)

La directory Flash Player Trust può contenere un numero indefinito di file di testo, ciascuno con un elenco dei percorsi affidabili, un percorso per riga. Ogni percorso può corrispondere a un singolo file SWF, un file HTML o una directory. Le righe di commento iniziano con il simbolo # . Ad esempio, un file di configurazione affidabile di Flash Player contenente il seguente testo garantisce uno stato affidabile a tutti i file contenuti nella directory specificata e in tutte le relative sottodirectory:

# Trust files in the following directories: 
C:\Documents and Settings\All Users\Documents\SampleApp

I percorsi elencati in un file di configurazione affidabile devono sempre essere percorsi locali o percorsi di rete SMB. I percorsi HTTP sono ignorati nel file di configurazione affidabile; solo i file locali possono essere considerati affidabili.

Per evitare conflitti, assegnate a ogni file di configurazione affidabile un nome corrispondente all'applicazione di installazione e utilizzare l'estensione .cfg.

Gli sviluppatori che distribuiscono un file SWF eseguito a livello locale mediante un'applicazione di installazione possono fare in modo che tale applicazione aggiunga un file di configurazione alla directory Global Flash Player Trust, al fine di garantire la totale affidabilità del file che stanno distribuendo. L'applicazione di installazione deve essere eseguita da un utente con privilegi amministrativi. A differenza del file mms.cfg, la directory Global Flash Player Trust viene inclusa allo scopo di garantire autorizzazioni di affidabilità mediante applicazioni di installazione. Sia gli utenti amministrativi che le applicazioni di installazione possono designare applicazioni locali come affidabili mediante la directory Global Flash Player Trust.

Esistono anche directory Flash Player Trust per singoli utenti (vedete Controlli utente ).

Controlli utente

Flash Player offre tre diversi meccanismi a livello utente per l’impostazione delle autorizzazioni: l’interfaccia utente Impostazioni, Gestione impostazioni e la directory User Flash Player Trust.

Interfaccia utente Impostazioni e Gestione impostazioni

L'interfaccia utente Impostazioni è un meccanismo rapido e interattivo per la configurazione delle impostazioni di un dominio specifico. Gestione impostazioni presenta un'interfaccia più dettagliata e consente di effettuare modifiche a livello globale che hanno effetto sulle autorizzazioni di molti o di tutti i domini. Inoltre, quando viene richiesta una nuova autorizzazione da parte di un file SWF e sono necessarie decisioni in fase di runtime relative alla sicurezza o alla riservatezza, vengono visualizzate finestre di dialogo nelle quali gli utenti possono modificare alcune impostazioni di Flash Player.

Gestione impostazioni e l'interfaccia utente Impostazioni comprendono opzioni relative alla sicurezza quali le impostazioni della fotocamera e del microfono, le impostazioni dell'area di memorizzazione degli oggetti condivisi, le impostazioni relative a contenuto legacy e così via. Nelle applicazioni AIR non sono disponibili né Gestione impostazioni né l'interfaccia utente Impostazioni.

Nota: le impostazioni eseguite nel file mms.cfg (vedete Controlli amministratore ) non vengono riportate in Gestione impostazioni.

Per maggiori informazioni su Gestione impostazioni, vedete www.adobe.com/go/settingsmanager_it .

Directory User Flash Player Trust

Le applicazioni di utenti e installatori sono in grado di registrare file SWF locali specifici come affidabili. Tali file SWF vengono assegnati alla sandbox locale affidabile. Questi file possono interagire con qualunque altro file SWF e possono caricare dati sia in remoto che in locale. I file vengono designati dall'utente come affidabili all'interno della directory User Player Trust, che si trova nella stessa directory dell'area di memorizzazione degli oggetti condivisi di Flash, nei seguenti percorsi (specifici in base all'utente corrente):

  • Windows: app data\Macromedia\Flash Player\#Security\FlashPlayerTrust

    (ad esempio, C:\Documents and Settings\JohnD\Dati applicazioni\Macromedia\Flash Player\#Security\FlashPlayerTrust in Windows XP o C:\Utenti\JohnD\DatiApp\Roaming\Macromedia\Flash Player\#Security\FlashPlayerTrust in Windows Vista)

    In Windows, la cartella Dati applicazioni è nascosta per impostazione predefinita. Per visualizzare i file e le cartelle nascoste, selezionate Risorse del computer per aprire Esplora risorse, quindi selezionate Strumenti > Opzioni cartella e infine la scheda Visualizzazione. Nella scheda Visualizzazione, selezionate il pulsante di opzione Visualizza cartelle e file nascosti.

  • Mac: app data/Macromedia/Flash Player/#Security/FlashPlayerTrust

    (ad esempio, /Users/JohnD/Library/Preferences/Macromedia/Flash Player/#Security/FlashPlayerTrust)

    Tali impostazioni riguardano unicamente l'utente corrente e non gli altri utenti che accedono al computer. Se un utente che non dispone di privilegi amministrativi installa un'applicazione nella propria porzione del sistema, la directory User Flash Player Trust consente al programma di installazione di registrare l'applicazione come affidabile per tale utente.

    Gli sviluppatori che distribuiscono un file SWF eseguito a livello locale mediante un'applicazione di installazione possono fare in modo che tale applicazione aggiunga un file di configurazione alla directory User Flash Player Trust, al fine di garantire la totale affidabilità del file che stanno distribuendo. Anche in questa situazione, la directory User Flash Player Trust è considerata un controllo utente, in quanto avviata da un'azione (installazione) eseguita dall'utente.

    Esiste anche una directory Global Flash Player Trust utilizzata da utenti o installatori con privilegi amministrativi per registrare un'applicazione per tutti gli utenti di un computer (vedete Controlli amministratore ).

Controlli del sito Web (file di criteri)

Per rendere i dati di un server Web disponibili ai file SWF di altri domini, potete creare un file di criteri sul server. Un file di criteri è un file XML memorizzato in una posizione specifica del server.

I file di criteri influenzano l'accesso a vari tipi di risorse, incluse le seguenti:

  • Dati in bitmap, file audio e video

  • Caricamento di file XML e di testo

  • Importazione di file SWF da altri domini di sicurezza nel dominio di sicurezza del file SWF che esegue il caricamento

  • Accesso a connessioni socket e connessioni socket XML

Gli oggetti ActionScript creano istanze per due tipi diversi di connessioni server: connessioni server basate su documenti e connessioni socket. Gli oggetti ActionScript quali Loader, Sound, URLLoader e URLStream sono in grado di creare istanze di connessioni server basate su documenti, ognuno dei quali può a sua volta caricare un file da un URL. Gli oggetti ActionScript Socket e XMLSocket sono invece in grado di effettuare connessioni socket, che operano con streaming di dati e non con documenti caricati.

Poiché Flash Player supporta due tipi di connessioni server, esistono anche due tipi di file di criteri: i file di criteri basati sugli URL e i file di criteri socket.
  • Le connessioni basate su documenti richiedono file di criteri degli URL , i quali consentono al server di indicare che i rispettivi dati e documenti sono messi a disposizione dei file SWF da alcuni oppure da tutti i domini.

  • Le connessioni socket richiedono invece file di criteri socket che consentono l'uso diretto della rete a livello di un socket TCP più basso, tramite le classi Socket e XMLSocket.

Flash Player richiede che i file di criteri vengano trasmessi con lo stesso protocollo utilizzato per il tentativo di connessione. Ad esempio, se collocate un file di criteri sul server HTTP, i file SWF di altri domini possono caricare dati da esso come da un qualsiasi server HTTP. Se tuttavia non fornite un file di criteri socket allo stesso server, ai file SWF di altri domini non sarà consentito connettersi al server a livello di socket. In altre parole, il sistema mediante il quale un file di criteri viene recuperato deve corrispondere al sistema mediante il quale viene eseguita la connessione.

Nella parte restante della presente sezione vengono illustrati brevemente l'uso e la sintassi dei file di criteri, in quanto si applicano ai file SWF pubblicati per Flash Player 10. Notate che, rispetto alle versioni precedenti di Flash Player, l'implementazione dei file di criteri è cambiata leggermente in quanto nelle versioni successive è stata rafforzata la sicurezza di Flash Player. Per ulteriori informazioni sui file di criteri, vedete l'articolo “Policy File Changes in Flash Player 9” (Modifiche ai file di criteri in Flash Player 9) nel Centro per sviluppatori di Flash Player all'indirizzo www.adobe.com/go/devnet_security_it .

Il codice in esecuzione nella sandbox dell'applicazione AIR non richiede un file dei criteri per accedere ai dati da un URL o un socket. Il codice di un'applicazione AIR in esecuzione in una sandbox non dell'applicazione richiede un file dei criteri.

File di criteri principale

Per impostazione predefinita, Flash Player (e il contenuto AIR che non si trova nella sandbox dell'applicazione AIR) cerca in primo luogo un file di criteri degli URL denominato crossdomain.xml nella directory principale del server e cerca un file di criteri socket sulla porta 843. Un file presente in una di queste due posizioni viene definito file di criteri principale . Nel caso di connessioni socket, Flash Player cerca anche un file di criteri socket sulla stessa porta usata per la connessione principale. Tuttavia, il file di criteri trovato su questa porta non viene considerato un file di criteri principale.

Oltre a definire le autorizzazioni di accesso, il file di criteri principale può anche contenere un'istruzione meta-policy , che indica dove il file di criteri si può trovare. Il metacriterio predefinito per i file di criteri degli URL è “solo principale”, ovvero /crossdomain.xml è il solo file di criteri consentito sul server. Il metacriterio predefinito per i file di criteri socket è “tutti”, ovvero qualunque socket sull'host può ospitare un file di criteri socket.

Nota: in Flash Player 9 e versioni precedenti, il metacriterio predefinito per i file di criteri degli URL era “tutti”, ovvero qualunque directory sull'host può contenere un file di criteri. Se avete implementato applicazioni che caricano i file di criteri da ubicazioni diverse da quella predefinita del file /crossdomain.xml e non sapete se tali applicazioni siano attualmente in esecuzione in Flash Player 10, accertatevi (in prima persona o tramite l'amministratore del sistema) di modificare il file di criteri principale in modo da consentire l'uso di più file di criteri. Per ulteriori informazioni sui come specificare un metacriterio diverso, vedete l'articolo “Policy File Changes in Flash Player 9” (Modifiche nei file di criteri principale in Flash Player 9) nel Centro per sviluppatori di Flash Player all'indirizzo www.adobe.com/go/devnet_security_it .

Un file SWF è grado di cercare un nome dei file di criteri differente o una directory differente mediante il metodo Security.loadPolicyFile() . Tuttavia se il file di criteri principale non specifica che la posizione di destinazione può ospitare file di criteri, la chiamata a loadPolicyFile() non produce risultati, anche se nella posizione indicata è effettivamente presente un file di criteri. Chiamate loadPolicyFile() prima di effettuare qualunque operazione sulla rete che richieda il file di criteri. Flash Player accoda automaticamente le richieste della rete ai relativi tentativi di accesso al file di criteri. Pertanto, è ad esempio accettabile chiamare Security.loadPolicyFile() immediatamente prima di iniziare un'operazione di rete.

Durante la ricerca di un file di criteri principale, Flash Player attende per tre secondi una risposta dal server. Se non la riceve, Flash Player deduce che il file di criteri principale non esiste. Non vi è tuttavia un timeout predefinito per le chiamate a loadPolicyFile() . Flash Player presuppone che il file chiamato esiste e attende tutto il tempo necessario per caricarlo. Quindi, per essere certi che il file di criteri principale venga caricato, usate loadPolicyFile() per chiamarlo esplicitamente.

Nonostante il metodo sia chiamato Security.loadPolicyFile() , non verrà caricato un file di criteri finché non viene generata una chiamata di rete che lo richieda. Le chiamate a loadPolicyFile() segnalano semplicemente a Flash Player dove cercare i file di criteri quando sono richiesti.

Non è possibile ricevere notifiche nel momento in cui la richiesta di un file di criteri viene inviata o completata, in quanto ciò non è necessario. Flash Player esegue i controlli dei criteri in modo asincrono e attende automaticamente il buon esito della ricerca dei file di criteri prima di stabilire le connessioni.

Nelle sezioni seguenti sono fornite informazioni relative ai file di criteri degli URL. Per ulteriori informazioni sui file di criteri socket, vedete Connessione a socket .

Area di validità

Un file di criteri degli URL è applicabile unicamente alla directory dalla quale è stato caricato e alle sue directory secondarie. Un file di criteri che si trova nella directory principale è applicabile all'intero server, mentre un file di criteri caricato da una qualsiasi sottodirectory è applicabile unicamente a tale directory e alle sue directory secondarie.

Un file di criteri influisce solo sull'accesso al server in cui risiede. Un file di criteri che ad esempio si trova all'indirizzo https://www.adobe.com:8080/crossdomain.xml sarà valido solo per le chiamate per il caricamento di dati eseguite a www.adobe.com tramite HTTPS sulla porta 8080.

Definizione delle autorizzazioni di accesso in un file di criteri degli URL

Un file di criteri degli URL contiene un solo tag <cross-domain-policy> che a sua volta contiene zero o più tag <allow-access-from> . Ogni tag <allow-access-from> contiene un attributo domain che specifica un indirizzo IP esatto, un dominio esatto o un dominio carattere jolly (ovvero qualsiasi dominio). I domini carattere jolly sono indicati in uno dei due seguenti modi:
  • Da un singolo asterisco (*), che indica tutti i domini e tutti gli indirizzi IP

  • Da un asterisco seguito da un suffisso, che indica solo i domini che terminano con il suffisso specificato

I suffissi devono iniziare con un punto. I domini carattere jolly con suffissi possono tuttavia essere rappresentati da domini costituiti solo dal suffisso senza il punto iniziale. Ad esempio, xyz.com è considerato parte di *.xyz.com. I caratteri jolly non sono consentiti quando vengono specificati domini IP.

Nell'esempio seguente è riportato un file di criteri degli URL che consente l'accesso a file SWF appartenenti a *.example.com, www.friendOfExample.com e 192.0.34.166:

<?xml version="1.0"?> 
<cross-domain-policy> 
    <allow-access-from domain="*.example.com" /> 
    <allow-access-from domain="www.friendOfExample.com" /> 
    <allow-access-from domain="192.0.34.166" /> 
</cross-domain-policy>

Se specificate un indirizzo IP, l'accesso è consentito solo ai file SWF caricati da quell'indirizzo IP utilizzando la sintassi IP (ad esempio http://65.57.83.12/flashmovie.swf) e non ai file SWF caricati utilizzando la sintassi del nome del dominio. Flash Player non esegue la risoluzione DNS.

È possibile consentire l'accesso a documenti appartenenti a qualsiasi dominio, come illustrato di seguito:

<?xml version="1.0"?> 
<!-- http://www.foo.com/crossdomain.xml --> 
<cross-domain-policy> 
<allow-access-from domain="*" /> 
</cross-domain-policy>

Ogni tag <allow-access-from> dispone dell'attributo opzionale secure che ha come valore predefinito true . Potete impostarlo su false se il file di criteri si trova su un server HTTPS e desiderate consentire ai file SWF di un server non HTTPS di caricare dati dal server HTTPS.

L'impostazione dell'attributo secure su false potrebbe compromettere la sicurezza garantita dal protocollo HTTPS. In particolare, l'impostazione di questo attributo su false consente di aprire il contenuto sicuro ad attacchi di snooping e spoofing. Adobe sconsiglia fortemente di impostare l'attributo secure su false .

Se i dati da caricare si trovano su un server HTTPS, ma il file SWF che esegue il caricamento si trova su un server HTTP, Adobe consiglia di spostare il file SWF su un server HTTPS, in modo da poter conservare tutte le copie dei dati sotto la protezione del server HTTPS. Tuttavia, se decidete di mantenere il file SWF su un server HTTP, aggiungete l'attributo secure="false" al tag <allow-access-from> , come riportato nel codice seguente:

<allow-access-from domain="www.example.com" secure="false" /> 
Un altro elemento utilizzabile per consentire l'accesso è il tag allow-http-request-headers-from . Questo elemento consente a un client con contenuti ottenuti da un altro dominio di autorizzazione di inviare al vostro dominio intestazioni definite dall'utente. A differenza del tag <allow-access-from> che concede agli altri domini l'autorizzazione a prelevare i dati dal vostro dominio, il tag allow-http-request-headers-from concede agli altri domini l'autorizzazione ad eseguire il push dei dati al vostro dominio, sotto forma di intestazioni. Nell'esempio seguente viene concessa a tutti i domini l'autorizzazione a inviare l'intestazione SOAPAction al dominio corrente:
<cross-domain-policy> 
    <allow-http-request-headers-from domain="*" headers="SOAPAction"/> 
</cross-domain-policy>

Se l'istruzione allow-http-request-headers-from è inserita nel file di criteri principale, vale per tutte le directory sull'host. In altri termini, vale solo per la directory e le sottodirectory del file di criteri contenente l'istruzione.

Precaricamento dei file di criteri

Caricare dati da un server o connettersi a un socket è un’operazione asincrona, di conseguenza Flash Player attende che il file di criteri termini di scaricare prima di iniziare l’operazione principale. Tuttavia, l’estrazione di dati pixel da immagini o di dati campione da file audio è un’operazione sincrona. Per poter estrarre i dati, è necessario che il file di criteri dei domini venga prima caricato. Quando caricate i file multimediali, dovete specificare che venga verificato se è presente un file di criteri:

  • Se usate il metodo Loader.load() , impostate la proprietà checkPolicyFile del parametro context , che è un oggetto LoaderContext.

  • Se incorporate un'immagine in un campo di testo mediante il tag <img> , impostate l'attributo checkPolicyFile del tag <img> su "true" , come nell'esempio seguente:

    <img checkPolicyFile = "true" src = "example.jpg">
  • Se usate il metodo Sound.load() , impostate la proprietà checkPolicyFile del parametro context , che è un oggetto SoundLoaderContext.

  • Se usate la classe NetStream, impostate la proprietà checkPolicyFile dell'oggetto NetStream.

Quando impostate uno di questi parametri, Flash Player verifica per prima cosa la presenza di file di criteri già scaricati per tale dominio. Quindi cerca il file di criteri nella posizione predefinita del server, facendo riferimento sia alle istruzioni <allow-access-from> , sia alla presenza di un metacriterio. Infine, prende in esame eventuali chiamate in attesa al metodo Security.loadPolicyFile() per vedere se sono nell’area di validità.

Controlli autore (sviluppatore)

L'API di ActionScript principale utilizzata per concedere privilegi di sicurezza è il metodo Security.allowDomain() , che consente di concedere privilegi a file SWF nel dominio specificato. Nell'esempio seguente, un file SWF concede l'accesso a file SWF gestiti dal dominio www.example.com:

Security.allowDomain("www.example.com")

Questo metodo consente di concedere autorizzazioni per le operazioni seguenti:

Lo scopo primario di una chiamata del metodo Security.allowDomain() è concedere ai file SWF di un dominio esterno l'autorizzazione a inviare script al file SWF che chiama il metodo Security.allowDomain() . Per ulteriori informazioni, vedete Scambio di script .

Se si specifica un indirizzo IP come parametro del metodo Security.allowDomain() , non viene consentito l'accesso a tutte le parti che accedono dall'indirizzo IP specificato. Al contrario, viene consentito solo l'accesso da una parte che contiene l'indirizzo IP specificato nel proprio URL, anziché il nome di dominio mappato sull'indirizzo IP. Ad esempio, se il nome dominio www.example.com viene mappato sull'indirizzo IP 192.0.34.166, una chiamata a Security.allowDomain("192.0.34.166") non garantisce l'accesso a www.example.com.

Per consentire l'accesso da tutti i domini, è possibile trasmettere il carattere jolly "*" al metodo Security.allowDomain() . Poiché in tal modo si consente a file SWF di tutti i domini di inviare script al file SWF chiamante, si raccomanda di utilizzare il carattere jolly "*" con estrema cautela.

ActionScript include un'API di autorizzazione secondaria chiamata Security.allowInsecureDomain() . Questo metodo funziona esattamente come il metodo Security.allowDomain() , con la differenza che, se chiamato da un file SWF gestito da una connessione HTTPS protetta, esso consente anche l'accesso al file SWF chiamante da parte di altri file SWF gestiti da un protocollo non protetto, quale HTTP. Tuttavia, non è consigliabile consentire lo scambio di script tra file appartenenti a un protocollo protetto (HTTPS) e file appartenenti a protocolli non protetti (come HTTP), in quanto si potrebbe aprire contenuto protetto ad attacchi di snooping e spoofing. Il funzionamento di questi attacchi è il seguente: poiché il metodo Security.allowInsecureDomain() consente l'accesso ai dati HTTPS protetti da parte di file SWF gestiti su connessioni HTTP, chi effettua l'attacco si interpone tra il server HTTP e gli utenti ed è in grado di sostituire il file SWF HTTP con un suo file, che può così accedere ai dati HTTPS protetti.

Importante: il codice in esecuzione nella sandbox dell'applicazione AIR non può chiamare i metodi allowDomain() o allowInsecureDomain() della classe Security.

Un altro metodo di sicurezza importante è il metodo Security.loadPolicyFile() , che obbliga Flash Player a verificare un file di criteri in un percorso non standard. Per ulteriori informazioni, vedete Controlli del sito Web (file di criteri) .