Programmation croisée

Flash Player 9 et les versions ultérieures, Adobe AIR 1.0 et les versions ultérieures

Si deux fichiers SWF écrits en ActionScript 3.0 ou deux fichiers HTML exécutés dans AIR sont transmis à partir d’un même domaine (supposons que l’URL du premier fichier SWF est http://www.example.com/swfA.swf et celle du second est http://www.example.com/swfB.swf), le code défini dans l’un des fichiers peut examiner et modifier les variables, objets, propriétés, méthodes, etc. de l’autre fichier, et inversement. On parle d’intercodage.

Si les deux fichiers sont issus de domaines différents (par exemple, http://siteA.com/swfA.swf et http://siteB.com/siteB.swf), Flash Player et AIR n’autorisent par défaut ni swfA.swf à créer un script pour swfB.swf, ni swfB.swf à créer un script pour swfA.swf. Un fichier SWF autorise les fichiers SWF provenant d’autres domaines en appelant Security.allowDomain(). Ainsi, en appelant Security.allowDomain("siteA.com"), swfB.swf accepte la programmation en provenance des fichiers SWF de siteA.com.

La programmation croisée n’est pas prise en charge entre les fichiers SWF AVM1 et AVM2. Un fichier SWF AVM1 est un fichier créé avec ActionScript 1.0 ou ActionScript 2.0 (AVM1 et AVM2 font référence à la machine virtuelle ActionScript). Vous pouvez néanmoins utiliser la classe LocalConnection pour échanger des données entre AVM1 et AVM2.

Dans tout contexte inter-domaines, il est important d’identifier clairement les parties impliquées. Dans le cadre de cette étude, le fichier effectuant la programmation croisée sera appelé partie procédant à l’accès (habituellement le fichier SWF procédant à l’accès), et l’autre côté sera appelé partie cible (généralement le fichier SWF cible). Lorsque siteA.swf programme siteB.swf, siteA.swf est la partie procédant à l’accès et site.B.swf la partie cible, comme le montre l’illustration suivante :

Les autorisations inter-domaines établies avec Security.allowDomain() sont asymétriques. Dans l’exemple précédent, siteA.swf peut programmer siteB.swf mais l’inverse n’est pas possible car siteA.swf n’a pas appelé la méthode Security.allowDomain() pour autoriser les fichiers SWF de siteB.com à le programmer. Vous pouvez définir des autorisations symétriques si les deux fichiers SWF appellent la méthode Security.allowDomain().

En dehors de la protection des fichiers SWF contre les scripts inter-domaines provenant d’autres fichiers SWF, Flash Player protège également les fichiers SWF contre ce type de script provenant des fichiers HTML. La programmation HTML vers SWF est possible au moyen de rappels effectués avec la méthode ExternalInterface.addCallback(). Lorsque la programmation HTML vers SWF franchit les limites du domaine, le SWF cible doit également appeler Security.allowDomain(), comme s’il avait été appelé par un fichier SWF, faute de quoi l’opération échoue. Pour plus d’informations, voir Contrôles de création (développeur).

Flash Player fournit en outre des contrôles de sécurité spécifiques à la programmation SWF vers HTML. Pour plus d’informations, voir Contrôle de l’accès URL externe.

Sécurité de la scène

Certaines propriétés et méthodes de l’objet Stage sont disponibles pour tout sprite ou clip de la liste d’affichage.

Le premier fichier SWF chargé est cependant considéré comme le propriétaire de l’objet Stage. Par défaut, les propriétés et méthodes suivantes de l’objet Stage sont uniquement disponibles pour les fichiers SWF du même sandbox de sécurité que le propriétaire de l’objet Stage :

Propriétés

Méthodes

align

addChild()

displayState

addChildAt()

frameRate

addEventListener()

height

dispatchEvent()

mouseChildren

hasEventListener()

numChildren

setChildIndex()

quality

willTrigger()

scaleMode

 

showDefaultContextMenu

 

stageFocusRect

 

stageHeight

 

stageWidth

 

tabChildren

 

textSnapshot

 

width

 

Pour qu’un fichier SWF d’un sandbox différent de celui du propriétaire de l’objet Stage puisse accéder à ces propriétés et méthodes, le fichier SWF propriétaire de l’objet Stage doit appeler la méthode Security.allowDomain(). Pour plus d’informations, voir Contrôles de création (développeur).

La propriété frameRate est un cas à part : tout fichier SWF peut lire la propriété frameRate. Toutefois, seuls les fichiers situés dans le sandbox de sécurité du propriétaire de l’objet Stage (ou ceux qui ont été autorisés à l’aide de la méthode Security.allowDomain()) peuvent modifier cette propriété.

Il existe également des restrictions sur les méthodes removeChildAt() et swapChildrenAt(), mais ce sont des restrictions différentes des autres. Pour appeler ces méthodes, le code ne doit pas se trouver dans le même domaine que le propriétaire de l’objet Stage mais dans le même domaine que le propriétaire du ou des objets enfant concernés ; en outre, les objets enfant peuvent appeler la méthode Security.allowDomain().

Parcours de la liste d’affichage

La capacité d’un fichier SWF d’accéder aux objets d’affichage chargés à partir d’autres sandbox fait l’objet de restrictions. Pour qu’un fichier SWF puisse accéder à un objet d’affichage créé par un autre fichier SWF dans un sandbox différent, le fichier SWF cible doit appeler la méthode Security.allowDomain() pour autoriser l’accès du domaine du fichier SWF procédant à l’appel. Pour plus d’informations, voir Contrôles de création (développeur).

Pour accéder à un objet Bitmap chargé par un objet Loader, il faut qu’un fichier de régulation d’URL existe sur le serveur d’origine du fichier image et que ce fichier accorde une autorisation au domaine du fichier SWF qui essaie d’accéder à l’objet Bitmap (voirContrôles de site Web (fichiers de régulation)).

L’objet LoaderInfo qui correspond au fichier chargé (et à l’objet Loader) inclut les trois propriétés suivantes, qui définissent la relation entre l’objet chargé et l’objet Loader : childAllowsParent, parentAllowsChild et sameDomain.

Sécurité des événements

Les événements liés à la liste d’affichage sont soumis à des restrictions d’accès de sécurité en fonction du sandbox de l’objet d’affichage qui distribue l’événement. Un événement de la liste d’affichage traverse des phases de capture et de propagation (voir Gestion des événements). Au cours de ces deux phases un événement passe de l’objet d’affichage source aux objets d’affichage parent dans la liste d’affichage. Si un objet parent appartient à un sandbox de sécurité différent de celui de l’objet d’affichage source, la phase de capture ou de propagation vers le haut s’arrête en dessous de cet objet parent, sauf si une relation de confiance est établie entre le propriétaire de l’objet parent et celui de l’objet source. Cette confiance mutuelle s’établit des manières suivantes :

  1. Le fichier SWF propriétaire de l’objet parent doit appeler la méthode Security.allowDomain() pour approuver le domaine du fichier SWF propriétaire de l’objet source.

  2. Le fichier SWF propriétaire de l’objet source doit appeler la méthode Security.allowDomain() pour approuver le domaine du fichier SWF propriétaire de l’objet parent.

L’objet LoaderInfo qui correspond au fichier chargé (et à l’objet Loader) inclut les deux propriétés suivantes, qui définissent la relation entre l’objet chargé et l’objet Loader : childAllowsParent et parentAllowsChild.

Pour les événements distribués à partir d’objets autres que les objets d’affichage, il n’existe aucune vérification de sécurité ni aucune implication liée à la sécurité.