Nous avons jusqu'à présent abordé la sécurité locale du point de vue d'un seul fichier SWF fonctionnant de manière autonome : aucun fichier SWF individuel ne dispose à la fois de droits en lecture seule et d'envoi Net sans autorisation spécifique de l'utilisateur. Cependant, les améliorations de la sécurité locale dans Flash Player 8 doivent également protéger les utilisateurs de Flash Player lorsque plusieurs fichiers SWF coopèrent entre eux. Aucun jeu de fichiers SWF coopératifs ne peut disposer collectivement de droits en lecture seule et d'envoi Net.
L'obtention d'une coopération entre des fichiers SWF passe par deux étapes. Pour commencer, un fichier SWF doit en charger un autre, généralement via la commande ActionScript loadMovie. Les deux fichiers SWF doivent ensuite échanger des informations, à l'aide de variables ActionScript, d'appels de méthode, d'objets LocalConnection, etc. Cet échange d'informations est parfois appelé programmation croisée.
Pour maintenir la sécurité locale, Flash Player interdit parfois le chargement du fichier SWF. Dans d'autres cas, il l'autorise mais limite la programmation croisée.
Le chargement du fichier SWF et la programmation croisée sont toujours autorisés entre les fichiers SWF résidant dans le même Sandbox. Ainsi, par exemple, tout fichier SWF local/système de fichiers peut charger et inter-coder n'importe quel autre fichier SWF local/système de fichiers, tout fichier SWF local/réseau peut charger et inter-coder n'importe quel autre fichier SWF local/réseau, etc. Les restrictions apparaissent lorsque deux fichiers SWF issus de Sandbox différents tentent de coopérer.
Le tableau 1 résume les restrictions de chargement et de programmation croisée entre Sandbox ; les règles individuelles apparaissent ensuite. Toutes les coopérations entre fichiers SWF comprennent deux parties. Le fichier SWF qui initie la coopération (qui appelle loadMovie ou exécute la programmation croisée) est appelé fichier SWF accédant et l'autre, fichier SWF accédé. Les titres du haut du tableau représentent le Sandbox du SWF accédant et ceux de gauche, le Sandbox du SWF accédé.
| Sandbox du fichier SWF accédant | ||||
|---|---|---|---|---|
| Sandbox du fichier SWF accédé | Local/ Système de fichiers |
Local/ Réseau |
Approuvé local |
Distant |
| Local/ Système de fichiers |
Chargement : oui Prog. croisée : oui |
Chargement : non | Chargement : oui Prog. croisée : oui |
Chargement : non |
| Local/ Réseau |
Chargement : non | Chargement : oui Prog. croisée : oui |
Chargement : oui Prog. croisée : oui |
Chargement : non |
| Approuvé local |
Chargement : oui Prog. croisée : avec autorisation |
Chargement : oui Prog. croisée : avec autorisation |
Chargement : oui Prog. croisée : oui |
Chargement : non |
| Distant | Chargement : non | Chargement : oui Prog. croisée : avec autorisation |
Chargement : oui Prog. croisée : oui |
Chargement : oui Prog. croisée : avec autorisation si les domaines ne correspondent pas |
Les cellules rouges du Tableau 1 présentent des cas où certains fichiers SWF ne peuvent pas en charger d'autres (via loadMovie, loadMovieNum, etc.) :
Les deux dernières règles peuvent au besoin être contournées car il est facile de transformer un fichier SWF Local/Système de fichiers en fichier SWF Local/Réseau et vice versa.
Toutefois, la première règle—un fichier SWF distant ne peut pas charger un fichier SWF local—est sans appel. Contrairement à la plupart des règles de sécurité de Flash Player, elle est incontournable. Elle permet d'éviter ce que l'on appelle les escalades de zones, où le contenu d'une zone moins privilégiée (un fichier SWF distant) active le contenu d'une zone potentiellement plus privilégiée (fichiers SWF locaux). Si, cas inhabituel, vous développez une application hybride distant-local démarrant un contenu installé localement lorsque les utilisateurs visitent une page Web, votre meilleure option consiste à modifier votre point d'entrée, à demander aux utilisateurs d'afficher d'abord un fichier SWF local (ou un projecteur local, un exécutable local, etc.), puis d'activer votre contenu en ligne.
Flash Player présente des règles similaires pour appeler getURL, qui charge des pages de navigateur plutôt que des fichiers SWF :
Les cellules jaunes du Tableau 1 présentent des cas où un fichier SWF peut en coder un autre, tant que le fichier SWF accédé autorise explicitement l'opération. Parmi ces cas figurent, notamment :
Pour respecter le principe d'autorisations globales de Flash Player, dans les deux premiers cas, le fichier SWF accédé doit accorder une autorisation aux fichiers SWF de tous les Sandbox. Cela signifie un appel à System.security.allowDomain(« * ») ou, pour les objets LocalConnection, l'apport d'un gestionnaire LocalConnection.allowDomain qui renvoie la valeur 'true' lorsqu'il est fourni avec un argument de domaine spécifiant « localhost ».
Flash Player 6 et les versions ultérieures prennent en charge des objets partagés persistants par l'intermédiaire de la classe SharedObject. Les objets partagés persistants stockent des données sur les ordinateurs des utilisateurs. Il s'agit généralement d'objets partagés locaux, obtenus avec SharedObject.getLocal. Il est également possible de créer des objets partagés distants persistants. Flash Media Server* (ancien serveur de communication Flash) est alors nécessaire, et les objets partagés distants sont documentés avec ce produit.
Chaque sandbox distant est associé à un stock d'objets partagés persistants. Par exemple, lorsqu'un fichier SWF issu de 'domain1.com' lit ou écrit un objet partagé persistant, Flash Player lit et écrit cet objet dans le stock d'objets de 'domain1.com'. De même, dans le cas d'un fichier SWF provenant de 'domain2.com', Flash Player utilisera le stock de 'domain2.com'. Pour éviter les conflits de noms, les objets partagés persistants sont identifiés par un chemin qui correspond par défaut au chemin complet de l'URL du fichier SWF à l'origine de la création, mais pouvant être abrégé par le paramètre localPath de SharedObject.getLocal, qui autorise d'autres fichiers SWF du même domaine à accéder à un objet partagé après sa création.
Dans Flash Player 7 et les versions antérieures, tous les fichiers SWF locaux partageaient un même stock d'objets partagés persistants. Depuis Flash Player 8, il existe deux stocks d'objets partagés locaux. Pour reprendre un ancien modèle, Flash Player s'assure que les fichiers SWF Local/Système de fichiers ne peuvent pas communiquer avec les fichiers SWF Local/Réseau—dans ce cas en affectant un stock d'objets partagés distinct chacun des deux Sandbox locaux.
Flash Player affecte les fichiers SWF approuvés locaux au même stock d'objets partagés que les fichiers SWF Local/Système de fichiers. Cela simplifie les transitions entre l'état de Local/Système de fichiers (par défaut) et celui d'Approuvé local (que les utilisateurs peuvent choisir pour corriger un problème et permettre au contenu local existant de fonctionner correctement). Lorsque les fichiers SWF effectuent cette transition, ils conservent tous les objets partagés qu'ils ont créés.
