Sandbox de sécurité

Les moteurs d’exécution de Flash Player et d’AIR classent les actifs (notamment les fichiers SWF) issus d’Internet dans des sandbox distincts correspondant à leur domaine d’origine. Les actifs chargés d’ example.com ne partagent par exemple pas le même sandbox de sécurité que les actifs issus de foo.org . Par défaut, ces fichiers sont autorisés à accéder à toutes les ressources issues de leur propre serveur. Il est possible d’autoriser les fichiers SWF distants à accéder à des données d’autres domaines à l’aide d’autorisations explicites portant sur les sites Web et les auteurs, par exemple des fichiers de régulation d’URL et la méthode Security.allowDomain() . Pour plus d’informations, voir Contrôles de site Web (fichiers de régulation) et Contrôles de création (développeur) .

Les fichiers SWF distants ne peuvent pas charger de fichiers ou de ressources locales.

Pour plus de détails sur la sécurité de Flash Player, voir la rubrique « Sécurité » du Centre des développeurs Flash Player à l’adresse www.adobe.com/go/devnet_security_fr .

Un fichier est dit local s’il est référencé par le biais du protocole file: ou d’un chemin UNC (Universal Naming Convention). Les fichiers SWF locaux sont placés dans l’un de quatre sandbox locaux :

• Sandbox local avec système de fichiers : pour raisons de sécurité, les moteurs d’exécution de Flash Player et AIR placent par défaut tous les fichiers locaux dans le sandbox local avec système de fichiers. A partir de ce sandbox, le code exécutable peut lire les fichiers locaux (à l’aide de la classe URLLoader, par exemple), mais en aucun cas communiquer avec le réseau. Ceci garantit à l’utilisateur que les données locales ne peuvent pas filtrer hors du réseau ou autrement être partagées de manière inopportune.

• Sandbox local avec réseau : lors de la compilation d’un fichier SWF, vous pouvez spécifier s’il dispose d’un accès réseau lorsqu’il est exécuté comme fichier local (voir Définition du type de sandbox des fichiers SWF locaux ). De tels fichiers sont placés dans le sandbox local avec réseau. Les fichiers SWF placés dans le sandbox local avec réseau abandonnent leur accès aux fichiers locaux. En échange, ils sont autorisés à accéder aux données sur le réseau. Toutefois, un fichier local avec réseau ne peut pas lire des données dérivées du réseau si aucune autorisation n’est accordée pour cela par le biais d’un fichier de régulation d’URL ou d’un appel à la méthode Security.allowDomain() . A cet effet, le fichier de régulation d’URL doit accorder une autorisation à tous les domaines en utilisant allow-access-from domain="*"/ ou Security.allowDomain("*") . Pour plus d’informations, voir Contrôles de site Web (fichiers de régulation) et Contrôles de création (développeur) .

• Sandbox local approuvé : les fichiers SWF locaux enregistrés comme approuvés (par l’utilisateur ou un programme d’installation) sont placés dans ce sandbox. Les administrateurs système et les utilisateurs peuvent aussi associer un fichier SWF local au sandbox local approuvé ou l’en dissocier, selon les contraintes de sécurité (voir Contrôles administrateur et Contrôles utilisateur ). Les fichiers SWF associés au Sandbox local approuvé peuvent interagir avec tous les autres fichiers SWF et charger des données à partir de n’importe quel emplacement (à distance ou localement).

• Sandbox de sécurité de l’application AIR : ce sandbox contient du contenu installé à l’aide de l’application AIR en cours d’exécution. Par défaut, le code exécuté dans le sandbox de l’application AIR peut accéder par intercodage au code de n’importe quel domaine. En revanche, les fichiers qui résident hors du sandbox de l’application AIR ne peuvent pas accéder par intercodage au code de ce sandbox. Par défaut, le code et le contenu du sandbox de sécurité de l’application AIR peuvent charger le contenu et les données de n’importe quel domaine.

La communication entre le sandbox local avec réseau et le sandbox local avec système de fichiers est strictement interdite, tout comme la communication entre le sandbox local avec système de fichiers et le sandbox distant. Elles ne peuvent pas être autorisées par une application Flash Player ni par un utilisateur ou un administrateur.

La programmation croisée entre les fichiers HTML et SWF locaux (par exemple à l’aide de la classe ExternalInterface) exige que les deux fichiers impliqués se trouvent dans le sandbox local approuvé. Cette contrainte vient du fait que les modèles de sécurité locaux des navigateurs diffèrent de celui de Flash Player.

Les fichiers SWF du sandbox local avec réseau ne peuvent pas charger des fichiers SWF du sandbox local avec système de fichiers. Les fichiers SWF du sandbox local avec système de fichier ne peuvent pas charger des fichiers SWF du sandbox local avec réseau.

Le moteur d’exécution d’Adobe AIR ajoute un autre sandbox, dit sandbox de l’ application , au modèle de sandbox de sécurité de Flash Player. Les fichiers installés dans le cadre d’une application AIR sont chargés dans le sandbox de l’application. A tout autre fichier chargé par l’application s’appliquent des restrictions de sécurité correspondant aux limites stipulées par le modèle de sécurité de Flash Player standard.

Lors de l’installation d’une application, tous les fichiers intégrés à un package AIR sont installés sur l’ordinateur de l’utilisateur dans le répertoire de l’application. Les développeurs peuvent référencer ce répertoire dans le code via le modèle d'URL app:/ (voir Modèles d’URI ). Tous les fichiers qui se trouvent dans l’arborescence du répertoire de l’application sont affectés au sandbox de l’application lorsque celle-ci est exécutée. Le contenu du sandbox de l’application est doté de tous les privilèges disponibles pour une application AIR, y compris l’interaction avec le système des fichiers locaux.

De nombreuses applications AIR n’utilisent que ces fichiers installés localement pour exécuter l’application. Toutefois, les applications AIR ne se limitent pas uniquement aux fichiers contenus dans le répertoire de l’application ; elles peuvent charger tout type de fichier à partir de n’importe quelle source. Ceci inclut aussi bien les fichiers locaux par rapport à l’ordinateur de l’utilisateur que ceux accessibles à partir des sources externes, comme ceux sur un réseau local ou sur Internet. Le type de fichier n’a pas d’impact sur les restrictions relatives à la sécurité ; les fichiers HTML chargés sont dotés des mêmes privilèges de sécurité que les fichiers SWF chargés à partir de la même source.

Le contenu du sandbox de sécurité de l’application a accès aux interfaces de programmation d’AIR que le contenu des autres sandbox n’est pas autorisé à utiliser. Par exemple, la propriété air.NativeApplication.nativeApplication.applicationDescriptor , qui renvoie les contenus du fichier descripteur d’application pour l’application, est limitée au contenu du sandbox de sécurité de l’application. Un autre exemple d’interface de programmation limitée : la classe FileStream qui contient des méthodes pour la lecture et l’écriture dans le système de fichiers local.

Les interfaces de programmation ActionScript réservées au contenu du sandbox de sécurité de l’application sont dotées du logo AIR dans le manuel Guide de référence ActionScript 3.0 pour la plate-forme Adobe Flash . L’utilisation de ces interfaces de programmation dans d’autres sandbox provoque le renvoi d’une exception SecurityError.

Pour un contenu HTML, dans un objet HTMLLoader, toutes les interfaces de programmation JavaScript d’AIR (celles qui sont disponibles via la propriété window.runtime ou l’objet air lors de l’utilisation du fichier AIRAliases.js), sont mises à la disposition du contenu dans le sandbox de sécurité de l’application. Le contenu HTML d’un autre sandbox n’ayant pas accès à la propriété window.runtime , il lui est impossible d’accéder aux interfaces de programmation AIR ou Flash Player.

Les restrictions complémentaires suivantes s’appliquent au content exécuté au sein du sandbox de l’application AIR :

• Pour un contenu HTML dans le sandbox de sécurité de l’application, il existe des limitations dans l’utilisation des interfaces de programmation qui peuvent transformer dynamiquement des chaînes en code exécutable après le chargement du code. Ceci empêche l’application d’injecter (et d’exécuter) du code par inadvertance à partir de sources non-applicatives, comme des domaines du réseau potentiellement non sécurisés. L’utilisation de la fonction eval() en est un exemple. Pour plus d’informations, voir Restrictions relatives au code pour un contenu dans des sandbox différents .

• Pour prévenir les attaques éventuelles d’hameçonnage, les balises img du contenu HTML des objets TextField d’ActionScript sont ignorées dans un contenu SWF au sein du sandbox de sécurité de l’application.

• Le contenu du sandbox de l’application ne peut pas utiliser le protocole asfunction du contenu HTML dans les champs de texte ActionScript 2.0.

• Le contenu SWF du sandbox de l’application ne peut pas utiliser la mémoire cache interdomaines, une fonction qui a été ajoutée à Flash Player 9 Mise à jour 3. Cette fonction permet à Flash Player de mettre constamment en mémoire cache le contenu du composant de la plate-forme Adobe et de le réutiliser à la demande dans du contenu SWF chargé. Cela lui évite de recharger le contenu plusieurs fois.

Contrairement au contenu du sandbox de sécurité de l’application, celui de JavaScript dans un sandbox de sécurité hors application peut à tout moment appeler la fonction eval() pour exécuter dynamiquement le code généré. Des restrictions s’appliquent néanmoins dans AIR au contenu JavaScript exécuté dans un sandbox de sécurité hors application, Parmi ces API figurent :

• Le code JavaScript dans un sandbox hors application n’a pas accès à l’objet window.runtime et, de ce fait, il ne peut pas exécuter d’interfaces de programmation AIR.

• Par défaut, le contenu dans un sandbox de sécurité hors application ne peut pas utiliser d’appels XMLHttpRequest pour charger des données à partir d’autres domaines ; il est limité au domaine d’où l’appel est lancé. Toutefois, le code de l’application peut autoriser le contenu hors application à le faire en paramétrant l’attribut allowCrossdomainXHR dans l’image conteneur ou l’iframe. Pour plus d’informations, voir Restrictions relatives au code pour un contenu dans des sandbox différents .

• Il existe des restrictions relatives aux appels de la méthode window.open de JavaScript. Pour plus de détails, voir la section Restrictions relatives à l’appel de la méthode window.open() de JavaScript .

• Un contenu HTML dans un sandbox de sécurité distant (réseau) ne peut charger que du contenu CSS, image , iframe et img à partir d’un domaine distant (à partir d’URL du réseau).

• Un contenu HTML dans un sandbox local avec système de fichiers, local avec réseau ou approuvé localement ne peut charger que du contenu CSS, image , iframe et img à partir de sandbox locaux (mais pas à partir d’URL d’application ou de réseau).

Pour plus d’informations, voir Restrictions relatives au code pour un contenu dans des sandbox différents .

Un utilisateur ou l’administrateur d’un ordinateur peut spécifier si un fichier SWF local est approuvé, lui permettant ainsi de charger des données de tous les domaines, locaux ou réseau. Cette caractéristique est définie dans les répertoires Flash Player Trust global et utilisateur. Pour plus d’informations, voir Contrôles administrateur et Contrôles utilisateur .

Pour plus d’informations sur les sandbox locaux, voir Sandbox locaux .

La propriété statique en lecture seule Security.sandboxType permet au créateur d’un fichier SWF de déterminer le type de sandbox auquel le moteur d’exécution de Flash Player ou d’AIR a associé le fichier SWF. La classe Security inclut des constantes qui représentent les valeurs possibles de la propriété Security.sandboxType , comme suit :

• Security.REMOTE : le fichier SWF provient d’une URL Internet et son fonctionnement est régi par les règles de sandbox de domaines.

• Security.LOCAL_WITH_FILE : le fichier SWF est un fichier local mais n’a pas été approuvé par l’utilisateur ni publié avec une désignation réseau. Le fichier SWF peut lire les sources de données locales mais ne peut pas communiquer avec Internet.

• Security.LOCAL_WITH_NETWORK : le fichier SWF est un fichier local non approuvé par l’utilisateur mais qui a été publié avec une désignation réseau. Le fichier SWF peut communiquer sur Internet mais ne peut pas lire les sources de données locales.

• Security.LOCAL_TRUSTED : le fichier SWF est un fichier local qui a été approuvé par l’utilisateur via le Gestionnaire des paramètres ou le fichier de configuration Flash Player Trust. Ce fichier SWF peut lire les sources de données locales et communiquer avec Internet.

• Security.APPLICATION : le fichier SWF est exécuté dans une application AIR, et a été installé avec le package (le fichier AIR) pour cette application. Par défaut, les fichiers du sandbox de sécurité de l’application AIR peuvent accéder par programmation croisée aux fichiers de n’importe quel domaine. En revanche, les fichiers se trouvant en dehors de ce sandbox ne peuvent pas accéder par programmation croisée au fichier AIR. Par défaut, les fichiers du sandbox de sécurité de l’application AIR peuvent charger le contenu et les données de n’importe quel domaine.