Documentazione di Flash CS3 |
|||
| Programmazione in ActionScript 3.0 > Sicurezza di Flash Player > Panoramica dei controlli di autorizzazione | |||
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 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.
I controlli amministratore, utente e sito Web vengono illustrati nelle sezioni che seguono. Le impostazioni del creatore (sviluppatore) vengono descritte nella parte restante di questo capitolo.
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 singoli utenti possono disporre di diritti amministrativi.
Esistono due tipi di controlli amministratore:
Nei sistemi Mac OS X, il file mms.cfg si trova in /Library/Supporto Applicazioni/Macromedia/mms.cfg. Nei sistemi Microsoft Windows, tale file si trova nella cartella Macromedia Flash Player, nella directory di sistema (ad esempio, C:\windows\system32\macromed\flash\mms.cfg, in un'installazione di Windows XP predefinita).
All'avvio, Flash Player legge le impostazioni di sicurezza da questo file e le impiega per limitare le funzionalità.
Il file mms.cfg include impostazioni utilizzate dall'amministratore per eseguire le seguenti attività:
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.
Le applicazioni di utenti e installatori con privilegi di amministratore 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 come affidabili all'interno della directory Global Flash Player Trust, che si trova nella stessa directory del mms.cfg file, nei seguenti percorsi (specifici in base all'utente corrente):
(ad esempio, C:\windows\system32\Macromed\Flash\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:
# Considera affidabili i file delle directory seguenti: C:\Documents and Settings\All Users\Documenti\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, assegnare 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 (vedere la sezione seguente, 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.
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 generale in grado di alterare le 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 è possibile modificare alcune impostazioni di Flash Player.
Gestione impostazioni e l'interfaccia utente Impostazioni offrono le seguenti opzioni di sicurezza:
|
NOTA |
|
Qualsiasi impostazione che riguarda il file mms.cfg (vedere Controlli amministratore) non viene riportata in Gestione impostazioni. |
Per ulteriori informazioni su Gestione impostazioni, vedere www.adobe.com/go/settingsmanager_it.
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 Flash 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):
(ad esempio, C:\Documents and Settings\JohnD\Dati applicazioni\Adobe\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 applicazioni affidabili per tutti gli utenti di un computer (vedere Controlli amministratore).
Per rendere i dati di un server Web disponibili ai file SWF di altri domini, è possibile creare un file di criteri dei domini sul server. Il file di criteri dei domini è un file XML che fornisce al server la possibilità di indicare che i propri dati e documenti sono disponibili per i file SWF provenienti da specifici domini o da tutti i domini. A qualsiasi file SWF gestito da un dominio specificato dal file di criteri del server è consentito l'accesso a dati o alle risorse provenienti da tale server.
I file di criteri dei domini influenzano l'accesso a vari tipi di risorse, incluso le seguenti:
Maggiori informazioni a riguardo sono contenute nella parte rimanente di questo capitolo.
Nell'esempio seguente è riportato un file di criteri 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>
Quando un file SWF tenta di accedere a dati da un dominio diverso, Flash Player tenta automaticamente di caricare un file di criteri dal quel dominio. Se il dominio del file SWF che tenta di accedere ai dati è compreso nel file dei criteri, i dati sono accessibili automaticamente.
Per impostazione predefinita, i file di criteri devono essere denominati crossdomain.xml e devono risiedere nella directory principale del server. Tuttavia, un file SWF è in grado di cercare un nome differente o all'interno di una directory differente mediante il metodo Security.loadPolicyFile(). Un file di criteri dei domini è applicabile unicamente alla directory dalla quale è stato caricato e alle sue directory secondarie. Di conseguenza, 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 si trova, ad esempio, 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.
Un file di criteri dei domini 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 da un solo asterisco (*) che corrisponde a tutti i domini e a tutti gli indirizzi IP oppure da un asterisco seguito da un suffisso che corrisponde a tutti 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, foo.com è considerato parte di *.foo.com. I caratteri jolly non sono consentiti quando vengono specificati domini IP.
Se si specifica 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 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. È possibile impostarlo su false se il file di criteri si trova su un server HTTPS e si desidera 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 vivamente 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 si decide di mantenere il file SWF su un server HTTP, aggiungere l'attributo secure="false" al tag <allow-access-from>, come riportato nel codice seguente:
<allow-access-from domain="www.example.com" secure="false" />
Utilizzare un file di criteri che non contiene tag <allow-access-from> equivale a non utilizzare alcun criterio su un server.
Gli oggetti di ActionScript sono in grado di creare istanze di due diversi tipi di connessione 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 bastate su documenti che, a loro volta, possono caricare 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. Flash Player supporta due tipi di file di criteri: i file di criteri basati su documenti e i file di criteri socket. Le connessioni basate su documenti necessitano di file di criteri basati su documenti, mentre le connessioni socket richiedono file di criteri socket.
Per Flash Player è necessario che un file di criteri venga trasmesso con lo stesso tipo di protocollo utilizzato dalla connessione. Ad esempio, se si colloca un file di criteri sul server HTTP, i file SWF di altri domini possono caricare dati da esso come da un qualsiasi server HTTP. Tuttavia, se non si fornisce un file di criteri socket allo stesso server, ai file SWF di altri domini non sarà consentito connettersi al server a livello di socket. Il sistema mediante il quale un file di criteri socket viene recuperato deve corrispondere al sistema mediante il quale viene eseguita la connessione.
Un file dei criteri gestito da un server socket ha la stessa sintassi di qualsiasi altro file dei criteri, con la differenza che questo file specifica anche le porte a cui viene garantito l'accesso. Un file dei criteri proveniente da una porta con numero inferiore a 1024 può autorizzare l'accesso a qualsiasi porta; un file proveniente da una porta 1024 o superiore può autorizzare l'accesso alle porte 1024 e superiori. Le porte consentite vengono specificate in un attributo to-ports del tag <allow-access-from>. Sono consentiti i numeri di porta singoli, gli intervalli di porte e i caratteri jolly.
Segue un esempio di file dei criteri XMLSocket:
<cross-domain-policy> <allow-access-from domain="*" to-ports="507" /> <allow-access-from domain="*.example.com" to-ports="507,516" /> <allow-access-from domain="*.example2.com" to-ports="516-523" /> <allow-access-from domain="www.example2.com" to-ports="507,516-523" /> <allow-access-from domain="www.example3.com" to-ports="*" /> </cross-domain-policy>
Quando i file di criteri sono stati introdotti per la prima volta in Flash Player 6, i file di criteri socket non erano supportati. Le connessioni ai server socket venivano autorizzate da un file di criteri contenuto nel percorso predefinito del file di criteri dei domini su un server HTTP collegato alla porta 80 dello stesso host del server socket. Per consentire la conservazione delle disposizioni server esistenti, Flash Player 9 supporta ancora tale funzionalità. Tuttavia, l'impostazione predefinita di Flash Player ora prevede il recupero di un file di criteri socket sulla stessa porta della connessione socket. Se si desidera utilizzare un file di criteri basato su HTTP per autorizzare connessioni socket, è necessario richiedere esplicitamente il file di criteri HTTP mediante un codice simile al seguente:
Security.loadPolicyFile("http://socketServerHost.com/crossdomain.xml")
Inoltre, per autorizzare connessioni socket, il file di criteri HTTP deve provenire unicamente dallo stesso percorso predefinito del file di criteri dei domini e non da altri percorsi HTTP. Un file di criteri ottenuto da un server HTTP autorizza implicitamente l'accesso socket a tutte le porte 1024 e superiori; qualsiasi attributo to-ports presente nel file di criteri HTTP viene ignorato.
Per ulteriori informazioni sui file di criteri socket, vedere Connessione a socket.
Caricare dati da un server o connettersi a un socket è un'operazione asincrona, di conseguenza Flash Player attende che il file di criteri dei domini 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 si caricano i file multimediali, è necessario specificare che venga verificato un file di criteri dei domini:
Loader.load(), impostare la proprietà checkPolicyFile del parametro context, che è un oggetto LoaderContext.<img>, impostare l'attributo checkPolicyFile del tag <img> su "true", come nell'esempio seguente: <img checkPolicyFile = "true" src = "example.jpg">.Sound.load(), impostare la proprietà checkPolicyFile del parametro context, che è un oggetto SoundLoaderContext.checkPolicyFile dell'oggetto NetStream.Quando si imposta uno di questi parametri, Flash Player verifica per prima cosa la presenza di file di criteri già scaricati per tale dominio. Quindi prende in esame eventuali chiamate in attesa al metodo Security.loadPolicyFile() per vedere se sono nell'area di validità e, in caso affermativo, attende che vengano eseguite. Infine cerca il file di criteri dei domini nel percorso predefinito all'interno del server.
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:
Lo scopo primario di una chiamata del metodo Security.allowDomain() è concedere a file SWF di un dominio esterno l'autorizzazione a inviare script al file SWF che chiama il metodo Security.allowDomain(). Per ulteriori informazioni, vedere 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. Ecco come funzionano tali attacchi: 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.
Un altro metodo di sicurezza importante è il metodo Security.loadPolicyFile(), che fa in modo che Flash Player verifichi un file di criteri dei domini in un percorso non standard. Per ulteriori informazioni, vedere Controlli del sito Web (file di criteri dei domini).
Flash CS3
Inviami un messaggio e-mail quando vengono aggiunti dei commenti a questa | Rapporto sui commenti
Pagina corrente: http://livedocs.adobe.com/flash/9.0_it/main/00000349.html