|
Sebbene le applicazioni AIR vengano create usando le tecnologie Web, è importante che gli sviluppatori tengano presente che non stanno lavorando nella sandbox di sicurezza del browser. Ciò significa che è possibile creare applicazioni AIR potenzialmente dannose per il sistema locale, sia volontariamente che involontariamente. AIR tenta di ridurre il rischio, tuttavia vi sono modi attraverso i quali possono essere introdotte delle vulnerabilità. In questo argomento sono descritte alcuni importanti rischi di sicurezza potenziali.
Rischio derivante dall'importazione di file nella sandbox di sicurezza dell'applicazione
I file presenti nella directory dell'applicazione vengono assegnati alla sandbox dell'applicazione e dispongono dei privilegi completi del runtime. Le applicazioni che scrivono sul file system locale ricevono istruzioni di scrivere su
app-storage:/
. Questa directory è indipendente dai file dell'applicazione sul computer dell'utente, quindi i file non vengono assegnati alla sandbox dell'applicazione e costituiscono un rischio di sicurezza limitato. Si consiglia agli sviluppatori di tenere presente quanto segue:
-
Includete un file in un file AIR (nell'applicazione installata) solo se necessario.
-
Includete un file di script in un file AIR (nell'applicazione installata) solo il relativo comportamento è completamente chiaro e attendibile.
-
Evitate di scrivere o modificare il contenuto nella directory dell'applicazione. Il runtime impedisce alle applicazioni di scrivere o modificare file e directory tramite lo schema URL
app:/
generando un'eccezione SecurityError.
-
Evitate di utilizzare dati da un'origine di rete, in quanto i parametri per i metodi dell'API AIR potrebbero comportare l'esecuzione di codice, ad esempio il metodo
Loader.loadBytes()
e la funzione JavaScript
eval()
.
Rischio derivante dall'uso di un'origine esterna per determinare i percorsi
Un'applicazione AIR potrebbe essere compromessa dall'uso di dati o contenuto esterno. Per questo motivo, prestate particolare attenzione quando usate dati dalla rete o dal file system. L'attendibilità, in ultima analisi, dipende dallo sviluppatore e della connessioni di rete che ha creato; tuttavia, i dati esterni comportano un rischio intrinseco e non dovrebbero essere usati per l'input in operazioni considerate sensibili. Si consiglia agli sviluppatori di evitare quanto segue:
Rischi derivanti da uso, memorizzazione o trasmissione di credenziali non sicure
L'archiviazione di credenziali utente nel file system locale dell'utente comporta intrinsecamente il rischio che tali credenziali vengano compromesse. Si consiglia agli sviluppatori di tenere presente quanto segue:
-
Se le credenziali devono essere archiviate localmente, crittografatele durante la scrittura nel file system locale. Il runtime fornisce un archivio crittografato univoca per ogni applicazione installata tramite la classe EncryptedLocalStore. Per informazioni dettagliate, vedete
Archiviazione locale crittografata
.
-
Non trasmettete credenziali utente non crittografate a un'origine di rete, a meno che tale origine non sia affidabile e la trasmissione non utilizzi il protocollo HTTPS o TLS (Transport Layer Security).
-
Non specificate mai una password predefinita quando create delle credenziali; fate in modo che gli utenti creino password personalizzate. Gli utenti che non modificano il valore predefinito espongono le proprie credenziali a possibili attacchi da parte di chi conosce già la password predefinita.
Rischio derivante da un attacco con downgrade
Durante l'installazione di un'applicazione, il runtime verifica che non sia già installata una versione di tale applicazione. Se un'applicazione è già installata, il runtime confronta la stringa della versione con la versione in corso di installazione. Se la stringa è diversa, l'utente può scegliere di aggiornare la propria installazione. Il runtime non è in grado di garantire che la nuova versione installata sia più recente di quella precedente; rileva solo che è diversa. Un utente malintenzionato potrebbe distribuire una versione meno recente per sfruttare eventuali punti deboli nella sicurezza. Per questo motivo, è opportuno che lo sviluppatore effettui controlli delle versioni quando viene eseguita l'applicazione. È buona norma fare in modo che l'applicazione ricerchi gli aggiornamenti necessari nella rete. In questo modo, anche se chi effettua l'attacco dovesse indurre l'utente a eseguire una versione precedente, questa rileverà automaticamente che è necessario un aggiornamento. L'uso di un chiaro schema di controllo delle versioni per la vostra applicazione, renderà anche più difficile indurre gli utenti a installare una versione precedente.
|
|
|
