Utilisation sécurisée d’un contenu non approuvé

Adobe AIR 1.0 et les versions ultérieures

Un contenu qui n’est pas affecté au sandbox de l’application peut fournir des fonctionnalités supplémentaires à votre application, mais uniquement s’il respecte les critères de sécurité du moteur d’exécution. La présente rubrique décrit le contrat de sécurité AIR avec un contenu hors application.

Security.allowDomain()

Les applications AIR limitent la programmation de l’accès au contenu hors application de façon plus rigoureuse que le module d’extension du navigateur de Flash Player ne le fait pour du contenu non approuvé. Par exemple, dans le Flash Player du navigateur, lorsqu’un fichier SWF affecté au sandbox approuvé localement appelle la méthode System.allowDomain() , la programmation de l’accès est autorisée à tout SWF chargé à partir du domaine spécifié. L’approche analogue à partir du contenu de l'application dans les applications AIR n’est pas permise, car cela consisterait à autoriser un accès déraisonnable au fichier hors application dans le système de fichiers de l’utilisateur. Les fichiers distants ne peuvent pas accéder directement au sandbox de l’application, quels que soient les appels à la méthode Security.allowDomain() .

Programmation entre contenu d’application et contenu hors application

Les applications AIR qui programment entre contenu d’application et contenu hors application disposent de mécanismes de sécurité plus complexes. Les fichiers qui ne sont pas dans le sandbox de l’application ne sont autorisés à accéder aux propriétés et méthodes des fichiers dans le sandbox de l’application que par l’utilisation d’un pont de sandbox. Un pont de sandbox agit en tant que passerelle entre contenu de l’application et contenu hors application. Il fournit ainsi une interaction explicite entre les deux fichiers. Lorsqu’ils sont utilisés correctement, les ponts de sandbox procurent une couche supplémentaire de sécurité pour empêcher un contenu hors application d’accéder à des références d’objets qui font partie du contenu de l’application.

L’avantage que peut présenter un pont de sandbox est très bien décrit par un exemple. Supposez qu’une application de disquaire AIR souhaite fournir une interface de programmation à des publicitaires voulant créer leurs propres fichiers SWF qui leur permettront de communiquer avec l’application du disquaire. Celui-ci veut fournir aux publicitaires des méthodes pour rechercher des artistes et des CD du magasin. Mais il veut aussi isoler quelques méthodes et propriétés du fichier SWF tiers, pour des raisons de sécurité.

Cette possibilité existe avec un pont de sandbox. Par défaut, un contenu chargé de l’extérieur dans une application AIR à l’exécution n’a accès à aucune méthode ou propriété de l’application principale. Avec une implémentation de pont de sandbox personnalisé, un développeur peut fournir des services au contenu distant sans exposer ces méthodes et propriétés. Considérez le pont de sandbox comme une voie entre contenu approuvé et non approuvé qui fournit une communication entre le contenu chargé et le contenu récepteur sans présenter de références d’objet.

Pour plus d’informations sur la façon d’utiliser les ponts de sandbox en toute sécurité, voir la section Programmation entre contenus de différents domaines .

Protection contre la génération dynamique de contenu SWF à risque

La méthode Loader.loadBytes() fournit un moyen pour une application de générer un contenu SWF à partir d’un tableau d’octets. Cependant, des attaques par injection sur des données chargées à partir de sources distantes pourraient causer des dommages sérieux lors du chargement du contenu. Ceci est particulièrement valable lors du chargement des données dans le sandbox de l’application où le contenu SWF généré peut accéder à l’ensemble des interfaces de programmation d’AIR au complet.

Il existe des conditions légitimes pour utiliser la méthode loadBytes() sans générer de code SWF exécutable. Vous pouvez utiliser cette méthode pour générer des données d’image afin de contrôler le délai d’affichage de celle-ci, par exemple. Il y a aussi des situations légitimes qui dépendent effectivement de l’exécution du code, comme la création dynamique de contenu SWF pour de la lecture audio. Dans AIR, par défaut, la méthode loadBytes() ne vous permet pas de charger un contenu SWF ; il ne vous permet que de charger un contenu d’image. Dans AIR, la propriété loaderContext de la méthode loadBytes() possède une propriété allowLoadBytesCodeExecution que vous pouvez définir sur true afin d’autoriser explicitement l’application à utiliser loadBytes() pour charger un contenu SWF exécutable. Le code ci-dessous montre comment utiliser cette fonction :

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

Si vous appelez loadBytes() pour charger un contenu SWF et que la propriété allowLoadBytesCodeExecution de l’objet LoaderContext est définie sur false (valeur par défaut), l’objet Loader renvoie une exception SecurityError.

Remarque : dans une version ultérieure d’Adobe AIR, cette interface de programmation pourrait changer. Lorsque cela se produira, il vous sera peut-être nécessaire de recompiler le contenu qui utilise la propriété allowLoadBytesCodeExecution de la classe LoaderContext.