Modifications de la sécurité dans Flash Player 8

Dans Flash Player 8, Macromedia a modifié le modèle de sécurité qui est appliqué au contenu Flash local. Par défaut, les privilèges des applications Flash exécutées depuis le système de fichiers local d'un utilisateur plutôt que par HTTP sont plus limités dans Flash Player 8 que dans Flash Player 7. Ce modèle s'appliquant au contenu Flash quelle qu'en soit la version, le contenu publié avant la sortie de la version 8 de Flash Player peut être affecté, comme celui créé après sa sortie. Cet article permet de corriger la plupart des problèmes liés à ces modifications.

Outre le changement de modèle de sécurité, Flash Player 8 introduit quelques restrictions supplémentaires et de nouvelles fonctionnalités de sécurité que cet article décrit également. Cependant, les modifications de la sécurité locale sont de loin le plus gros changement apporté à la sécurité de Flash Player 8.

Remarque : Ces modifications de la sécurité locale n'affectent pas le contenu Flash obtenu via HTTP. La majorité du contenu Flash passe par HTTP et ne doit donc pas être affecté par ces modifications.

Nouvelles restrictions

Voici les nouvelles limites imposées au contenu Flash :

• Sandbox locaux : Par défaut, les fichiers SWF locaux n'ont plus accès à Internet, ne peuvent plus exécuter d'échanges HTTP, ni communiquer avec les fichiers HTML locaux. Lorsque des fichiers SWF de version 7 ou antérieure tentent d'effectuer l'une de ces actions, une boîte de dialogue signale aux utilisateurs que l'opération est impossible. L'aspect de la boîte de dialogue et les ruptures du contenu existant peuvent être modifiés par les utilisateurs ou les développeurs Flash en définissant les autorisations appropriées.
• Restrictions de chargement : Le contenu SWF et HTML issu d'URL non locales peut ne plus charger le contenu (SWF, HTML, PNG, etc.) provenant de chemins locaux.
• Stockage tiers : Les utilisateurs de Flash Player peuvent maintenant choisir d'empêcher les fichiers SWF tiers (provenant de domaines autres que celui qui s'affiche dans la barre d'adresses du navigateur) de lire ou d'écrire des objets partagés persistants. Cette restriction n'est pas appliquée par défaut. Les utilisateurs doivent l'activer explicitement.
• allowScriptAccess par défaut : Pour les fichiers SWF de version 8 et ultérieures, le paramètre allowScriptAccess HTML est par défaut 'sameDomain' plutôt que 'always'. Cela n'affecte pas les fichiers SWF de la version 7 ou des versions antérieures. Le paramètre allowScriptAccess indique si les fichiers SWF peuvent faire appel à du code JavaScript dans des pages HTML.

Nouvelles fonctionnalités de sécurité

Voici les nouvelles fonctionnalités de sécurité du contenu Flash (pour plus d'informations sur la sécurité relative à Flash Player 7, consultez la page Modifications de la sécurité dans Macromedia Flash Player 7) :

Caractère générique allowDomain : System.security.allowDomain() accepte maintenant l'argument de caractère générique « * » qui autorise l'accès des fichiers SWF depuis n'importe quel domaine.

Autorisations plus précises : System.security.allowDomain() et System.exactSettings ne s'appliquent à présent qu'au fichier SWF qui les appelle, et non plus à l'ensemble du domaine de ce fichier. Cette restriction ne concerne que le nouveau contenu (version 8+) ; la compatibilité ascendante est donc préservée.

Objets partagés, persistants et sécurisés : Les fichiers SWF chargés via HTTPS peuvent maintenant créer des objets SharedObject éventuellement accessibles uniquement aux fichiers SWF également chargés via HTTPS. Cela rappelle le comportement des cookies des navigateurs et permet de protéger les données stockées dans des objets partagés contre les risques de repérage et d'altération. Les objets partagés existants ne sont pas affectés.

Les modifications apportées à la sécurité locale de Flash Player 8 ont un objectif majeur : Lorsque les utilisateurs téléchargent des fichiers SWF sur leurs ordinateurs, ils doivent être assurés que Flash Player ne permettra pas à ces fichiers d'effectuer des actions nuisibles. Dès que la sécurité est en jeu, les utilisateurs doivent pouvoir être tout autant confiants quant au téléchargement et à l'exécution des fichiers SWF sur leurs ordinateurs qu'au stockage de fichiers JPEG ou TXT, plutôt que devoir se montrer prudents, comme avec les fichiers exécutables.

Jusqu'à Flash Player 7, l'intérêt des fichiers SWF locaux reposait sur le rôle qu'ils jouaient du point de vue des auteurs de contenu Flash : un fichier SWF local n'est généralement qu'un fichier local temporaire éventuellement destiné à être publié sur le Web. Dans ce contexte, il n'était pas nécessaire de limiter les actions qu'ils peuvent exécuter. Toutefois, lorsqu'un fichier SWF est téléchargé puis exécuté par un utilisateur qui n'est pas un développeur Flash, cet individu ne dispose pas d'informations suffisantes quant à l'origine du fichier SWF pour être certain qu'il est inoffensif. Dans le cas de Flash Player 7 et des versions antérieures, lorsqu'un tiers mal intentionné réussit à convaincre un utilisateur de télécharger et d'exécuter un fichier SWF, ce dernier, devenu local, peut en profiter pour pirater le système local : il peut lire les fichiers texte issus d'emplacements connus (ou invités) dans le système de fichiers de l'utilisateur—à l'aide, par exemple, de XML.load()—puis renvoyer leur contenu à l'attaquant. C'est ce type d'espionnage des fichiers qui est contrecarré par les modifications de la sécurité locale de Flash  Player 8.

L'un des facteurs clé du succès à long terme de Flash réside dans la capacité de toutes ses nouvelles versions à assurer la compatibilité ascendante avec tout contenu Flash existant. Les modifications de sécurité violent parfois ce principe, frustrant ainsi les développeurs et les utilisateurs de Flash. (La plupart des lecteurs voudront probablement revoir les changements de contenus requis par les modifications de la sécurité dans Flash  Player 7.) Macromedia est conscient de l'impact de ces changements pour ses clients et n'entreprend pas de tels projets à la légère. Nous présentons donc nos excuses les plus sincères à tous ceux qui en sont affectés.

Malgré ces difficultés, l'amélioration de notre modèle de sécurité demeure la priorité légitime pour une technologie de plate-forme telle que Flash. Le succès de Flash est incroyable et le lecteur est de plus en plus répandu, ce qui, pour ses clients, est un gage de valeur. Sécuriser le comportement de Flash Player est pour nous un devoir si nous souhaitons que le grand public et les professionnels continuent à installer le lecteur et à le mettre un jour. Rétrospectivement, il aurait peut-être été plus simple de concevoir un ensemble de règles de sécurité s'appliquant au contenu Flash local plus tôt dans l'histoire de Flash Player. Toutefois, les risques liés à la sécurité évoluent, de même que l'usage du lecteur Flash, et plusieurs versions sont parfois nécessaires pour obtenir une avancée efficace.

L'aspect positif est que moins de contenu sera affecté par les modifications de Flash Player 8 que par celles de Flash Player 7. Dans ce dernier cas, les modifications affectaient le contenu développé sur le Web, alors que les modifications de Flash Player 8 ne concernent que le contenu déployé sous forme de fichiers locaux, considérablement moins courant. Avec des millions de déploiements de Flash à travers le monde, « moins courant » implique tout de même un nombre considérable d'exemples de contenus Flash locaux, mais le nombre de développeurs touchés devrait être moins important que dans le cas des modifications de Flash Player 7.

Dans Flash Player 7 et les versions antérieures, les fichiers SWF locaux—chargés à partir du système de fichiers d'un utilisateur à l'aide d'un chemin local—étaient librement autorisés à exécuter la plupart des opérations normalement contrôlées par les règles de sécurité de Flash Player. Par exemple, alors qu'un fichier SWF chargé via HTTP ne peut (par défaut) charger un texte à l'aide de XML.load() que depuis son propre domaine d'origine, un fichier SWF local dans Flash Player 7 était autorisé à charge du texte depuis n'importe quelle URL HTTP ou n'importe quel chemin du système de fichiers local, à l'aide de XML.load().

Considérez la lecture d'un fichier texte à partir d'un chemin local comme un privilège appelé lecture locale. Considérez également que, dans Flash Player 7, tous les fichiers SWF disposent d'un privilège supplémentaire appelé envoi net, qui autorise l'envoi de n'importe quelle donnée vers n'importe quel emplacement Internet à l'aide, par exemple, d'une opération POST HTTP via LoadVars.send(). Combinez ces privilèges, 'lecture locale' et 'envoi net', dans un fichier SWF local téléchargé par un utilisateur depuis une source non approuvée et vous obtenez un fichier SWF local autorisé, de façon inappropriée, à lire les fichiers texte de l'utilisateur et à en renvoyer le contenu vers un emplacement Internet, à son insu.

Dans Flash Player 8, le résumé le plus simple des règles de fichiers SWF locaux est le suivant : Par défaut, les fichiers SWF locaux conservent le privilège de lecture locale mais perdent celui d'envoi net. Ils ne sont tout simplement pas autorisés à communiquer avec Internet (ou un serveur HTTP), en aucune façon. En modifiant un paramètre dans un fichier SWF, un auteur Flash peut choisir de lui accorder le privilège d'envoi net, en échange de l'abandon du privilège de lecture locale. Enfin, les auteurs et les utilisateurs peuvent configurer Flash Player de manière à élever le statut d'un fichier SWF au niveau approuvé qui lui accorde les deux privilèges. En d'autres termes, le fichier SWF retrouve exactement les mêmes privilèges que ceux dont il bénéficiait dans Flash Player 7.

Eléments affectés

Le contenu Flash peut être affecté en fonction de deux facteurs : sa nature locale ou non et le type de lecteur Flash utilisé.

Les fichiers SWF affectés sont ceux qui sont chargés à partir de chemins locaux. Cela comprend, entre autres, les exemples de formes d'URL suivants :

• c:\temp\my.swf
• file:///c|/temp/my.swf
• /temp/my.swf
• file:///temp/my.swf
• \\server\share\my.swf
• file:////server/share/my.swf
• URL relatives chargées par les fichiers SWF déjà locaux

Il existe plusieurs types de lecteurs Flash et chacun est affecté dans des circonstances différentes :

• Les lecteurs de navigateurs Web (lecteurs de contrôle ActiveX et plug-ins) imposent les règles de sécurité locales en usage dans le navigateur Web.
• Ces lecteurs de navigateurs Web n'imposent pas toujours les règles de sécurité locales lorsqu'ils sont utilisés dans une application autre que navigateur. Si vous développez une application qui intègre l'un de ces lecteurs, consultez la section « Intégration de Flash Player et sécurité locale ».
• Les lecteurs autonomes imposent les règles de sécurité locales.
• Les projecteurs Flash, qui peuvent être créés à partir d'une application de programmation Macromedia Flash et de lecteurs autonomes, n'imposent pas les règles de sécurité locales car il s'agit de programmes exécutables que les utilisateurs doivent, en général, traiter avec précaution.
• Les lecteurs de programmation dans Flash n'imposent pas les règles de sécurité locales car il ne servent qu'à tester le contenu en cours de développement, pas à lire un contenu issu du Web.

Types Sandbox

Dans Flash Player 8, tous les fichiers SWF (et les fichiers HTML, pour les scripts SWF-HTML) sont placés dans l'un des quatre types de Sandbox :

• Distant. Tous les fichiers provenant d'URL non locales sont placés dans un Sandbox distant. Ces Sandbox sont nombreux, un pour chaque domaine Internet (ou intranet) d'où proviennent les fichiers chargés. Il s'agit des mêmes Sandbox que ceux qui avaient été introduits dans Flash Player 6. Ils n'ont pas été modifiés dans Flash Player 8.
• Local/Système de fichiers. Il s'agit du Sandbox par défaut pour les fichiers locaux dans Flash Player 8. Les fichiers SWF de ce Sandbox ne peuvent pas contacter Internet (ni les serveurs HTTP) par quelque moyen que ce soit. Par exemple, ils ne peuvent pas transmettre d'URL HTTP à loadMovie(), getURL() ou XML.load(). Comme ces opérations étaient autorisées dans Flash Player 7, un fichier SWF de version 7 ou antérieure qui tente de contacter Internet constitue un cas où le contenu qui fonctionnait auparavant risque de ne plus fonctionner comme prévu après une mise à niveau de Flash Player 7 vers Flash Player 8. Ainsi, lorsqu'un fichier SWF de version 7 ou antérieure tente de contacter Internet, Flash Player 8 affiche une boîte de dialogue à l'utilisateur pour lui signaler qu'une tentative de contact Internet a échoué. La boîte de dialogue d'avertissement contient un bouton qui permet à l'utilisateur d'accéder au Gestionnaire de paramètres, où il peut choisir d'élever le statut du contenu concerné au niveau approuvé/local (voir ci-dessous).
• Local/Réseau. Les fichiers SWF de ce Sandbox peuvent communiquer via HTTP mais pas lire les systèmes de fichiers locaux. Les fichiers SWF de toutes versions peuvent choisir d'aller dans ce Sandbox à l'aide d'un indicateur défini dans le fichier SWF lui-même. En d'autres termes, l'utilisateur n'a pas à intervenir pour placer un fichier SWF dans ce Sandbox. Cet indicateur peut être défini avec les options de publication de Flash 8, ou à l'aide du Programme de mise à jour du contenu local, utilitaire de post-traitement SWF disponible gratuitement sur le site de macromedia.com.
• Approuvé local Ce Sandbox ne présente aucune restriction. Il accorde les mêmes privilèges ouverts que ce qu'obtenaient tous les fichiers locaux dans Flash Player 7. Tout fichier local peut être placé dans ce Sandbox si l'utilisateur lui en donne l'autorisation. Cette autorisation peut prendre deux formes : interactivement via le Gestionnaire de paramètres ou non interactivement via un programme d'installation exécutable qui crée des fichiers de configuration Flash Player sur l'ordinateur de l'utilisateur.

A ce stade, il peut être très utile de consulter les annexes des diagrammes décrivant la sécurité locale (voir la section Diagrammes de la sécurité locale).

Lorsqu'un fichier SWF doit accéder à Internet (ou à un serveur HTTP intranet), deux Sandbox locaux offrent un tel accès. Le sandbox local/réseau est plus facile à atteindre et toute la configuration nécessaire passe par le fichier SWF lui-même. Le sandbox approuvé/local est plus puissant, offre de plus grands privilèges, mais est généralement plus difficile à atteindre et requiert des informations de configuration distinctes du fichier SWF. Après la présentation détaillée des règles de sécurité locales, cet article s'intéressera au choix entre ces deux alternatives.

Autorisations globales

Comme les fichiers locaux ne disposent plus d'autorisations illimitées dans Flash Player 8, des autorisations Flash doivent parfois leur être accordées. Ces autorisations sont décrites dans la section suivante.

En général, Flash Player adhère au principe de demande d'autorisations globales pour accorder des autorisations aux fichiers locaux. Par exemple, si un fichier SWF distant souhaite s'autoriser lui-même à être mis en script par un fichier SWF local/réseau, il doit appeler System.security.allowDomain("*"), autorisant ainsi n'importe quel autre fichier SWF chargé à le mettre en script. Flash Player n'offre pas de méthode permettant de n'accorder d'autorisation qu'aux seuls fichiers locaux. Celui qui accorde l'autorisation doit accepter de le faire pour tous les fichiers. Cela est dû au fait que Flash Player ne peut pas déterminer l'origine d'un fichier local—celui-ci peut provenir de n'importe où. Il n'est donc pas approprié d'autoriser un fichier local à exécuter une action, sauf si la personne qui accorde cette autorisation ne se soucie pas de la provenance du fichier.

Assurez-vous de ne pas appeler System.security.allowDomain("*") sauf si le fichier SWF qui le fait ne contient pas d'informations sensibles. N'appelez pas simplement System.security.allowDomain("*") dans l'espoir de résoudre tous vos problèmes de sécurité, vous sacrifieriez ainsi des protections dont votre contenu pourrait avoir besoin ! Prenez chaque fois le temps de réfléchir aux conséquences de l'octroi d'une autorisation globale.

Cette section décrit les divers Sandbox locaux dans lesquels sont placés les fichiers SWF.

Privilèges

Flash Player définit les types de privilèges suivants pour les fichiers locaux :

• Lecture locale. Ce privilège est disponible pour les fichiers SWF local/système de fichiers, mais pas pour les fichiers SWF local/réseau. Il comprend les opérations qui chargent des données à partir de fichiers externes dans des variables ActionScript, où les données proviennent de fichiers résidant dans les systèmes de fichiers locaux. Des exemples de formes d'URL locales ont déjà été proposés dans la section « Eléments affectés ». Les opérations de chargement de données affectées sont les suivantes :
  • XML.load, XML.sendAndLoad
  • LoadVars.load, LoadVars.sendAndLoad, loadVariables, loadVariablesNum, MovieClip.loadVariables
  • Importation d'un symbole à partir d'une autre bibliothèque SWF
• Envoi Net. Ce privilège est disponible pour les fichiers SWF local/réseau, mais pas pour les fichiers SWF local/système de fichiers. Il comprend des opérations qui envoient des données ou des requêtes vers des emplacements Internet ou des serveurs HTTP, y compris toutes les opérations suivantes utilisées avec des URL non locales :
  • XML.load, XML.send, XML.sendAndLoad
  • LoadVars.load, LoadVars.send, LoadVars.sendAndLoad, loadVariables, loadVariablesNum, MovieClip.loadVariables
  • XMLSocket.connect
  • NetConnection.call (Flash Remoting)
  • Importation d'un symbole à partir d'une autre bibliothèque SWF
  • getURL, MovieClip.getURL
  • loadMovie, loadMovieNum, MovieClip.loadMovie, MovieClipLoader.loadClip
  • Sound.loadSound
• Lecture Net. Les fichiers SWF local/réseau peuvent exécuter les opérations d'envoi Net. Certaines d'entre elles sont à sens unique : les données sont envoyées, mais aucune réponse ne revient. D'autres opérations d'envoi Net sont des requêtes pour lesquelles une réponse est reçue. Ces dernières sont appelées opérations Lecture Net, super-ensemble d'opérations Envoi Net. Les fichiers SWF local/réseau peuvent tenter les opérations de lecture Net, bien qu'une autorisation soit nécessaire à partir du domaine d'origine des données. Ces opérations sont les suivantes, à l'aide d'URL non locales :
  • XML.load, XML.sendAndLoad
  • LoadVars.load, LoadVars.sendAndLoad, loadVariables, loadVariablesNum, MovieClip.loadVariables
  • XMLSocket.connect
  • NetConnection.call (Flash Remoting)
  • Importation d'un symbole à partir d'une autre bibliothèque SWF
• SWF-HTML. Cela comprend les opérations qui autorisent les fichiers SWF à mettre en script des fichiers HTML et vice versa. Des trois Sandbox locaux, seuls les fichiers approuvé/local disposent du droit SWF-HTML, du fait des non concordances potentielles entre les modèles de sécurité de Flash Player et des navigateurs Web. Ces opérations comprennent :
  • Opérations SWF vers HTML :

• Opérations HTML vers SWF :

  L'API JavaScript (SetVariable, GotoFrame, etc.)
  Rappel établi avec ExternalInterface.addCallback

Choix d'un fichier SWF dans le Sandbox Local-Réseau

Un fichier SWF local est placé dans ce Sandbox lorsqu'il contient un indicateur appelé UseNetwork. Cet indicateur peut être placé dans un fichier SWF de n'importe quelle version, bien qu'il n'ait de sens que pour les versions Flash Player 8 et ultérieures. Cet indicateur est mis en place par l'une des deux méthodes suivantes :

• Lors d'une publication depuis Flash 8, dans la boîte de dialogue Paramètres de publication, sélectionnez l'onglet Flash, localisez l'option Sécurité de lecture locale, puis choisissez Accès au réseau uniquement (figure 1).

• Si vous n'avez pas Flash 8 ou si vous préférez travailler avec les fichiers SWF après leur publication plutôt que de les republier, vous pouvez utiliser le programme de mise à jour du contenu local de Flash, utilitaire de ligne de commande gratuit disponible en téléchargement sur le site macromedia.com. Ce programme de mise à jour du contenu local peut ajouter, supprimer ou vérifier l'indicateur UseNetwork, en travaillant sur un ou plusieurs fichiers SWF. Cet utilitaire est disponible pour Windows, Mac OS X et Linux, et également en code source.

Notez que l'indicateur UseNetwork n'affecte pas les fichiers SWF chargés via HTTP (toujours placés dans des Sandbox distants) ou que l'utilisateur a approuvé (toujours placés dans le Sandbox approuvé/local). L'indicateur UseNetwork n'affecte que les fichiers SWF qui seraient autrement placés dans le sandbox Local/Système de fichiers.

Configuration des fichiers dans le Sandbox approuvé/local

Les fichiers SWF (ou HTML) locaux sont placés dans ce Sandbox s'ils correspondent à un chemin local désigné comme approuvé par la configuration locale de l'utilisateur. Il est possible d'approuver des chemins vers des fichiers individuels ou des répertoires, tout leur contenu, fichiers et sous-répertoires, devenant alors également approuvé. Deux méthodes permettent d'accorder des approbations :

• Gestionnaire des paramètres. Les utilisateurs peuvent ouvrir le Panneau Sécurité du Gestionnaire de paramètres et ajouter, modifier ou supprimer manuellement des chemins approuvés dans la liste (figure 2).

• Les utilisateurs peuvent également choisir le traitement global que Flash Player doit réserver aux anciens fichiers SWF (SWF local/système de version 7 et antérieures) par l'intermédiaire des options 'Demander/Autoriser/Refuser' de ce panneau. L'option par défaut est 'Demander' ; elle empêche toute opération non autorisée mais affiche la boîte de dialogue d'avertissement. Le choix de l'option 'Toujours autoriser' permet par contre les opérations interdites, revenant ainsi au comportement par défaut de Flash Player 7. Toutefois, ce paramètre n'affecte pas les fichiers SWF de version 8 ou ultérieure, mais uniquement le contenu développé avant la mise en place des nouvelles règles locales. L'activation de l'option 'Toujours refuser' entraîne l'échec de toutes les opérations interdites, sans affichage de la boîte de dialogue.

  Remarque<:hs>: Les options 'Demander/Autoriser/Refuser' contrôlent non seulement les questions de sécurité locale mais également celles de correspondance exacte de domaine survenues depuis Flash Player 7.

• Fichiers de configuration FlashPlayerTrust Il s'agit de simples fichiers texte qui contiennent la liste des chemins approuvés. Ils doivent être créés par des programmes d'installation exécutables. Lorsque l'un de ces programmes installe des fichiers SWF sur l'ordinateur d'un utilisateur, il peut installer des fichiers de configuration de confiance pour désigner les fichiers SWF approuvés. Bien que chaque fichier SWF ne soit pas approuvé explicitement par l'utilisateur, celui-ci fait simplement confiance au programme d'installation lorsqu'il l'exécute—il s'agit, après tout, d'un programme exécutable. Flash Player reconnaît les fichiers de configuration de confiance en deux emplacements : l'un qui affecte tous les utilisateurs de l'ordinateur et l'autre qui n'affecte que l'utilisateur en cours. L'emplacement réservé à tous les utilisateurs a été défini de manière à exiger des droits administratifs au niveau du système d'exploitation. Les emplacements sont les suivants :
  • Tous les utilisateurs Windows :

    <système>\Macromed\Flash\FlashPlayerTrust

    (ex. : c:\WINNT\system32\Macromed\Flash\FlashPlayerTrust)

  • Utilisateur Windows unique :

    <app data>\Macromedia\Flash Player\#Security\FlashPlayerTrust

    (ex. : c:\Documents and Settings\fred\Application Data\Macromedia\Flash Player\#Security\FlashPlayerTrust)

  • Tous les utilisateurs Mac OS  :

    <app support>/Macromedia/FlashPlayerTrust

    (ex. : /Library/Application Support/Macromedia/FlashPlayerTrust)

  • Utilisateur Mac OS unique :

    <app data>/Macromedia/Flash Player/#Security/FlashPlayerTrust

    (ex. : /Users/fred/Library/Preferences/Macromedia/Flash Player/#Security/FlashPlayerTrust)

Ces emplacements sont des répertoires, pas des fichiers individuels. Autant de fichiers de configuration que nécessaire peuvent y être installés, Flash Player lira tous les fichiers stockés dans ces répertoires. Les fichiers de configuration ne doivent cependant pas être placés dans des sous-répertoires de FlashPlayerTrust, mais directement dans les répertoires FlashPlayerTrust. Le nom donné aux fichiers de configuration individuels n'a pas d'importance. Cependant, pour éviter les conflits de nom, il est préférable que les programmes d'installation nomment leurs fichiers de configuration de sorte qu'ils demeurent spécifiques à leur produit. Les répertoires FlashPlayerTrust n'étant pas présents dans tous les systèmes, les programmes d'installation doivent parfois les créer.

La syntaxe de ces fichiers est simple : ils contiennent autant de chemins d'accès local que nécessaire, un par ligne. Les espaces blancs et les lignes vierges sont autorisés. Des commentaires peuvent être inclus avec le caractère #, à la fin d'une ligne. Les guillemets sont inutiles (et seront la cause de problèmes) pour les chemins contenant des espaces.

Ces fichiers contenant des chemins de système de fichiers qui peuvent comporter des caractères non ASCII dans certains ordinateurs, le codage de texte utilisé dans les fichiers FlashPlayerTrust est important. Flash Player recherchera des caractères de marque d'ordre d'octet Unicode au début de ces fichiers, et reconnaîtra les marques d'ordre UTF-8 et UTF-16, traitant le reste du fichier en UTF-8 ou UTF-16 de façon appropriée. (Le Bloc-notes de Windows et TextEdit de Mac, par exemple, peuvent écrire des fichiers texte Unicode contenant ses marques d'ordre d'octet. Nombre d'autres éditeurs de texte peuvent également le faire.) Si Flash Player ne trouve pas de marque d'ordre d'octet au début d'un fichier FlashPlayerTrust, il interprète le fichier à l'aide de la 'page de codes' actuelle (codage local par défaut) de l'ordinateur.

Sandbox HTML

Bien que l'on parle généralement de fichiers SWF placés dans des Sandbox, il est également vrai que Flash Player place lui aussi des fichiers HTML dans des Sandbox pour contrôler les interactions SWF/HTML. Les fichiers HTML locaux ne possèdent que deux Sandbox : approuvés et non approuvés. Par défaut, les fichiers HTML locaux ne sont pas approuvés, mais peuvent être désignés comme approuvés de la même façon que les fichiers SWF. Le Sandbox d'un fichier HTML local ne concerne que la mise en script d'HTML en SWF, comme avec l'API JavaScript de Flash Player.

Choix du Sandbox d'un fichier SWF

Un fichier SWF peut choisir son propre type de Sandbox à l'aide de la propriété ActionScript en lecture seule suivante :

System.security.sandboxType

Cette propriété peut prendre l'une des quatre valeurs de chaînes suivantes :

• "remote"
• "localWithFile"
• "localWithNetwork"
• "localTrusted"

Comportement d'un Sandbox Local/Système de fichiers

Les fichiers SWF d'un sandbox local/système de fichiers peuvent exécuter des opérations en Lecture locale mais pas d'opérations Envoi Net ou SWF/HTML.

Si vous utilisez une version de débogage de Flash Player et que vous êtes connecté(e) au débogueur dans Macromedia Flash, dès qu'un fichier SWF de ce sandbox tente une opération interdite, un message de diagnostic s'affiche dans le panneau de résultats et décrit l'opération avortée.

Lorsqu'un utilisateur lit un fichier SWF avec une version de publication 7 ou antérieure dans ce Sandbox et que le fichier SWF tente une opération interdite, une boîte de dialogue d'avertissement de sécurité s'affiche, signalant que le fonctionnement prévu du contenu a pu être interrompu du fait d'une modification des règles de sécurité locales de Flash Player 8 (figure 3).

Cette boîte de dialogue apparaît tout au plus à chaque exécution d'une application. Les opérations suivantes ne déclencheront pas son ouverture, mais échoueront discrètement.

La tentative d'opération échouera quelle que soit la mesure prise par l'utilisateur dans la boîte de dialogue. Toutefois, si l'utilisateur clique sur le bouton Paramètres, une nouvelle fenêtre affiche le Gestionnaire de paramètres, où il peut choisir d'approuver le contenu local à l'origine de la tentative d'opération interdite. Si l'utilisateur choisit la commande d'ajout d'emplacement, rapidement après l'affichage du Gestionnaire de paramètres de Flash Player (figure 2), une info-bulle présente le chemin du fichier SWF local à l'origine de la tentative d'opération interdite (figure 4).

L'utilisateur peut choisir de simplement copier ce chemin dans le champ de texte 'Faire confiance à cet emplacement', approuvant ainsi le fichier SWF individuel qui avait entraîné l'ouverture de la boîte de dialogue. Cela est parfois suffisant. Toutefois, les applications se composent parfois de plusieurs fichiers et plusieurs d'entre eux doivent alors être approuvés pour que l'application fonctionne correctement. (Voir la section coopération des médias ultérieure.) L'utilisateur peut donc être amené à approuver plusieurs fichiers ou l'ensemble du répertoire contenant le fichier SWF à l'origine de l'ouverture de la boîte de dialogue.

Si l'utilisateur effectue des changements dans le Gestionnaire de paramètres, il doit ensuite redémarrer l'application originale (généralement en actualisant son navigateur) pour que ces changements soient pris en compte.

La documentation relative au Panneau de sécurité du Gestionnaire de paramètres décrit la procédure ci-dessus pour les utilisateurs. Ces derniers peuvent également accéder à la TechNote, How Do I Let Local Flash Content Communicate with the Internet? (Comment autoriser le contenu Flash local à communiquer avec Internet ?), pour obtenir la procédure détaillée d'approbation d'un contenu local.

FlashAuthor.cfg

Pour les utilisateurs, la boîte de dialogue d'avertissement de sécurité locale ne s'affiche que pour les fichiers SWF de version 7 et antérieures. Cette boîte de dialogue permet aux utilisateurs de corriger le contenu pré–Flash 8 affecté par les nouvelles règles de sécurité locales.

Toutefois, pour les auteurs de contenu Flash, la boîte de dialogue d'avertissement de sécurité peut être un indicateur pratique des causes d'échec. Les auteurs peuvent souhaiter être immédiatement informés lorsqu'un fichier SWF, quelle que soit la version, tente une opération interdite par les règles de sécurité locales.

En réponse à ce besoin, divers outils de programmation Macromedia, dont Macromedia Flash 8, installent un fichier appelé FlashAuthor.cfg qui demande à Flash Player d'afficher la boîte de dialogue d'avertissement dès qu'un fichier SWF Local/Système tente une opération interdite, quelle que soit sa version. Les utilisateurs sont également libres de créer eux-mêmes ce fichier. Celui-ci peut être placé en deux emplacements, chacun à côté des répertoires FlashPlayerTrust :

• Tous les utilisateurs Windows :

  <système>\Macromed\Flash\FlashAuthor.cfg

  (ex. : c:\WINNT\system32\Macromed\Flash\FlashAuthor.cfg)

• Utilisateur Windows unique :

  <app data>\Macromedia\Flash Player\#Security\FlashAuthor.cfg

  (ex. : c:\Documents and Settings\fred\Application Data\Macromedia\Flash Player\#Security\FlashAuthor.cfg)

• Tous les utilisateurs Mac OS  :

  <app support>/Macromedia/FlashAuthor.cfg

  (ex. : /Library/Application Support/Macromedia/FlashAuthor.cfg)

• Utilisateur Mac OS unique :

  <app data>/Macromedia/Flash Player/#Security/FlashAuthor.cfg

  (ex. : /Users/fred/Library/Preferences/Macromedia/Flash Player/#Security/FlashAuthor.cfg)

Une seule instruction est pour l'instant reconnue dans ce fichier :

LocalSecurityPrompt=Author

Cette instruction demande à Flash Player d'ignorer la version du fichier SWF lorsqu'il choisit d'afficher ou non la boîte de dialogue d'avertissement de la figure 3.

FlashAuthor.cfg peut également contenir des espaces et des commentaires, signalés par le caractère # et placés en fin de ligne.

Si vous développez du contenu SWF destiné à être lu sous forme de fichier local, l'instruction LocalSecurityPrompt=Author peut se révéler inopportune car elle empêche Flash Player d'imiter parfaitement le comportement de l'utilisateur. Vous pouvez désactiver le comportement spécifique aux auteurs en choisissant un contenu de FlashAuthor.cfg autre que LocalSecurityPrompt=Author, comme illustré ci-dessus. Par exemple, vous pouvez commenter la ligne ci-dessus ou la modifier en quelque chose de facile à comprendre, tel que :

LocalSecurityPrompt=User

Notez que Macromedia Flash 8 installe FlashAuthor.cfg dans les deux emplacements réservés, tous les utilisateurs et utilisateur unique. Lorsque FlashAuthor.cfg est présent aux deux emplacements, Flash Player effectue la copie de l'emplacement de l'utilisateur unique, alors n'oubliez pas de modifier le fichier concerné.

Comportement d'un Sandbox Local/Réseau

Les fichiers SWF d'un sandbox local/réseau peuvent exécuter des opérations Envoi Net mais pas d'opérations en Lecture locale ou SWF/HTML.

Si vous utilisez une version de débogage de Flash Player et que vous êtes connecté au débogueur dans Flash, dès qu'un fichier SWF de ce sandbox tente une opération interdite, un message de diagnostic s'affiche dans le panneau de résultats et décrit l'opération avortée.

Les fichiers SWF placés dans ce Sandbox n'entraîneront pas l'ouverture de la boîte de dialogue d'avertissement de sécurité car le contenu ne peut pas avoir été créé avant la modification des règles de sécurité locales et se trouver dans un Sandbox local/réseau. Du point de vue de l'utilisateur, toutes les opérations interdites de ce Sandbox échoueront discrètement.

Les fichiers SWF local/réseau peuvent exécuter des opérations Envoi Net. Certaines d'entre elles sont à sens unique : les données sont envoyées, mais aucune réponse ne revient. D'autres opérations d'envoi Net sont des requêtes pour lesquelles une réponse est reçue. Ces dernières sont appelées opérations Lecture Net, super-ensemble d'opérations Envoi Net. XML.load("http://mysite.com/data/schedule.xml") est un exemple d'opération en lecture seule. Les fichiers SWF local/réseau peuvent tenter des opérations de Lecture seule. Toutefois, pour respecter le principe d'autorisations globales de Flash Player afin qu'un fichier SWF local/réseau charge des données depuis un domaine donné, celui-ci doit servir un fichier de régulation qui autorise tous les domaines à lire les données concernées, en indiquant <allow-access-from domain="*" />. Dans l'exemple ci-dessus, mysite.com aurait besoin d'un fichier de régulation placé soit dans l'emplacement par défaut (http://mysite.com/crossdomain.xml) ou à côté des données désirées (http://mysite.com/data/crossdomain.xml). Dans ce dernier cas, le chargement du fichier SWF doit appeler le code suivant pour informer Flash Player de l'emplacement, pas par défaut, du fichier de régulation :

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é.

Restrictions de chargement

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 fichiers SWF distants (servis via HTTP et d'autres protocoles non locaux) ne peuvent jamais charger de fichiers SWF locaux.
• Les fichiers SWF Local/Réseau ne peuvent jamais charger de fichiers SWF Local/Système de fichiers, ou vice versa.
• Les fichiers SWF Local/Système de fichiers ne peuvent jamais charger de fichiers SWF distants. (Il s'agit en fait de la conséquence d'une règle traitée précédemment : le chargement d'un fichier SWF distant requiert un appel à loadMovie avec une URL distante, c'est-à-dire une opération d'envoi Net, donc interdite aux fichiers SWF Local/Système de fichiers.)

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 fichiers SWF distants ne peuvent pas appeler getURL par des URL locales.
• Les fichiers SWF Local/Système de fichiers peuvent appeler getURL avec des URL locales, mais dans ce cas, tous les paramètres de requête ou les ancres (parties de l'URL qui suit un symbole « ? » ou « # ») seront ignorés.

Autorisations de programmation croisée

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 :

• Un fichier SWF local non approuvé codant un fichier SWF local approuvé, ce dernier devant autoriser l'opération
• Un fichier SWF Local/Réseau codant un fichier SWF distant, ce dernier devant autoriser l'opération
• Un fichier SWF distant codant un autre fichier SWF distant issu d'un domaine différent, le fichier SWF accédé devant autoriser l'opération (les règles distant/distant n'ont pas changé depuis Flash Player 7)

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 ».

Objets partagés persistants

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.

L'objectif des scénarios suivants est d'illustrer les effets des nouvelles règles de sécurité locales dans Flash Player 8.

Scénario utilisateur : Auteurs Flash et collègues

Les règles de sécurité locales de Flash Player 8 ont été conçues pour protéger les utilisateurs. Pour ces derniers, les fichiers SWF locaux représentent généralement du contenu final, c'est-à-dire des éléments téléchargés depuis une source Internet ou installés en même temps qu'une application. Pour les auteurs Flash, toutefois, les fichiers SWF locaux sont bien souvent une simple version temporaire du contenu en cours de développement, c'est-à-dire des éléments destinés à être déployés sur un serveur HTTP. Des restrictions de sécurité peuvent donc parfois empêcher votre contenu de fonctionner comme prévu, simplement parce que vous lisez vos fichiers SWF alors qu'ils sont encore des fichiers locaux.

Les trois méthodes suivantes permettent de tester le contenu Flash en développement, par ordre de complexité croissante :

• Testez l'animation dans l'application de programmation Flash. Les Lecteurs de tests d'animation n'imposant pas du tout les nouvelles règles de sécurité locales, ce mode ne devrait pas entraîner de problèmes.
• Affichez les fichiers SWF locaux dans des lecteurs autonomes ou de navigateurs. Cette méthode accroît les risques de problèmes liés aux nouvelles règles, par exemple lorsqu'un fichier SWF appelle getURL avec une URL HTTP.
• Stockez les fichiers SWF sur un serveur de test HTTP et affichez-les dans un navigateur. Là encore, cette méthode de test évite les problèmes de sécurité locale car les fichiers SWF affichés via HTTP ne sont pas locaux et sont régis par les règles de sécurité à distance de Flash Player, qui n'ont pas changé dans Flash Player 8.

L'idéal, pour éviter des restrictions de sécurité indésirables pendant les tests d'aperçu dans un navigateur, serait que Flash Player puisse faire la différence entre le contenu Flash en cours de développement et les fichiers SWF non approuvés téléchargés sur Internet. Malheureusement, aucune méthode automatisée fiable ne permet à Flash Player d'effectuer cette opération.

Par contre, il est possible, et pratique, de configurer Flash Player de sorte qu'il fasse confiance à tous les fichiers SWF provenant d'une certaine zone de votre système de fichiers local. Par exemple, si vous stockez tout votre travail Flash en cours sous C:\FlashSites, vous pouvez ouvrir le Gestionnaire de paramètres et ajouter le répertoire C:\FlashSites à votre liste de chemins approuvés. Dès cet instant, chaque fois que vous affichez tout fichier SWF issu du répertoire C:\FlashSites ou de l'un de ses sous-répertoires, Flash Player le place dans le Sandbox Approuvé local, évitant ainsi tout échec lié à la sécurité. Par contre, assurez-vous de ne jamais placer de fichiers SWF issus de sources auxquelles vous ne faites pas confiance dans vos zones approuvées ! De même, le fait de conserver vos propres fichiers SWF locaux à l'écart des fichiers SWF non approuvés des autres auteurs vous permettra de bénéficier des mêmes protections améliorées que tous les utilisateurs de Flash Player.

Imaginons que vous configuriez un répertoire approuvé dans le Gestionnaire des paramètres. A présent, votre propre travail n'est plus interrompu par des problèmes de sécurité. Toutefois, vous devrez peut-être partager vos fichiers SWF en cours de développement avec divers collègues, auteurs HTML, développeurs Flex, artistes bitmap, etc. Ou encore, vous souhaiterez montrer vos fichiers SWF à vos supérieurs ou à des clients. Parmi ces personnes, certains n'auront probablement pas configuré de répertoire approuvé sur leurs ordinateurs. Donc, s'ils ouvrent vos fichiers SWF sous forme de fichiers locaux et que ces derniers tentent de communiquer avec Internet (par exemple en appelant getURL), ou avec des pages HTML, les règles de sécurité locales peuvent empêcher votre contenu de fonctionner comme prévu sur leurs ordinateurs. De plus, certains de ces membres de votre 'communauté de travail' n'auront probablement pas installé FlashAuthor.cfg sur leurs ordinateurs. Donc, si vos fichiers SWF sont de version 8 ou ultérieure, ils ne verront même pas les boîtes de dialogue d'avertissement leur signalant les raisons de l'échec.

Malheureusement, aucune recette magique ne permet de résoudre ces problèmes de 'communauté de travail'. A la base, le problème est que lorsque Flash Player s'exécute sur les ordinateurs de vos collègues, il n'a aucun moyen de distinguer (temporairement) vos fichiers SWF locaux des fichiers SWF potentiellement non approuvés issus de téléchargements sur Internet.

Le moyen le plus sûr pour résoudre ces problèmes de 'communauté de travail' consiste à publier vos fichiers SWF sur un serveur de test HTTP, puis d'envoyer des liens, plutôt que d'envoyer directement les fichiers SWF. Toutefois, cette méthode présente parfois des inconvénients ou se révèle impossible : par exemple, si vous ne disposez pas de serveur HTTP privé ou si vous devez partagez vos fichiers SWF avec des personnes extérieures à votre réseau et ne souhaitez pas les publier sur des serveurs publics. D'autres possibilités sont alors envisageables :

• Créez des projecteurs SWF
• Publiez vos fichiers SWF sous forme de Local/Réseau plutôt que Local/Système de fichiers.
• Pour vos projets SWF, créez des programmes d'installation qui configureront des fichiers FlashPlayerTrust.
• Envoyez des instructions de configuration du Gestionnaire des paramètres à vos collègues.
• Demandez à vos collègues de publier les fichiers SWF sur leurs propres serveurs.

La meilleure solution dépend en fait de votre situation.

Scénario utilisateur : Utilisateurs Flash Player

La majorité des nouvelles règles de sécurité locales resteront transparentes pour les utilisateurs finaux de Flash Player. Toutefois, comme nous venons de le voir, certains d'entre eux possèdent peut-être des applications Flash locales destinées à communiquer avec Internet. Dès que ces utilisateurs migrent vers Flash Player 8, des boîtes de dialogue leur signalent les opérations potentiellement risquées.

Dans ce cas, les options des utilisateurs sont simples. Ils peuvent choisir d'ignorer le problème, contacter le vendeur de l'application pour demander un correctif ou tenter de corriger eux-mêmes le problème.

Les utilisateurs qui décident de corriger le problème peuvent cliquer sur le bouton Paramètres de la boîte de dialogue d'avertissement. Le Gestionnaire des paramètres apparaît alors et leur permet d'obtenir des informations sur la sécurité locale, en choisissant Edit Locations > Add Location, puis de sélectionner un chemin local à approuver. L'identification du chemin qui peut être approuvé n'est pas toujours une tâche facile. Approuver le seul chemin qui apparaît dans la boîte de dialogue d'avertissement est parfois suffisant, mais il arrive aussi que plusieurs fichiers SWF soient impliqués dans l'application concernée. Dans ce cas, il est parfois nécessaire d'approuver l'ensemble du répertoire contenant ces fichiers SWF. Après avoir choisi les chemins à approuver, l'utilisateur doit revenir dans l'application qui a déclenché l'avertissement de sécurité et la redémarrer, par exemple en actualisant son navigateur.

Une fois dans le Gestionnaire de paramètres, l'utilisateur peut également choisir d'activer l'option 'Toujours autoriser' afin d'approuver tous les fichiers SWF des versions 7 et antérieures. Cette opération est bien plus simple que l'identification des chemins qui doivent être approuvés mais, en contrepartie, la sécurité des utilisateurs s'en trouve réduite.

Scénario application : Correction d'un système d'aide hybride

Imaginons maintenant que vous développiez une application utilisant des fichiers SWF locaux et que certains de vos utilisateurs vous informent que des boîtes de dialogue de sécurité de Flash Player leur signalent des opérations potentiellement risquées lorsqu'ils affichent certaines parties de votre application. Disons que votre application est un système d'aide hybride, forme courante d'application SWF locale : un ensemble de fichiers HTML et SWF qui communiquent entre eux à l'aide de getURL et éventuellement de la fonction fscommand.

La première étape consiste à déterminer la gravité du problème. S'agit-il d'un composant essentiel d'une application importante avec une faille majeure ou d'une petite défaillance de votre violon d'Ingres ? Pensez-vous redistribuer les fichiers corrigés à tous vos utilisateurs ? La réponse sera souvent affirmative, mais assurez-vous que le jeu en vaut la chandelle.

Une possibilité consiste à demander à vos utilisateurs d'approuver le chemin d'accès à votre système d'aide dans le Gestionnaire des paramètres. Toutefois, cette opération peut être laborieuse pour certains utilisateurs ou leur poser des problèmes s'ils ne comprennent pas les implications de leurs décisions en matière de sécurité.

Une autre possibilité serait de republier vos fichiers SWF en tant que local/réseau, ou de les traiter ensuite à l'aide du Programme de mise à jour du contenu local. Si les seules violations de sécurité provoquées par votre contenu proviennent d'appels à la méthode getURL, cela devrait être suffisant. Toutefois, si vous fichiers SWF et HTML se programment les uns les autres à l'aide de fscommand, de getURL ("javascript:...") ou d'autres opérations de script hybrides, le Sandbox local/réseau ne suffira pas pour restaurer l'état précédent de votre application. Vous devrez alors placer vos fichiers SWF dans un Sandbox Approuvé local.

Si vos utilisateurs disposent de connaissances techniques, vous pouvez leur fournir un fichier FlashPlayerTrust et des instructions sur son emplacement de stockage. Vous pouvez également créer un petit script ou programme créant automatiquement un fichier FlashPlayerTrust à l'emplacement approprié. Si vous savez où vos fichiers SWF sont installés, il vous suffit d'approuver le répertoire où ils doivent résider. Toutefois, si les utilisateurs ont choisi un emplacement d'installation personnalisé, il vous faudra peut-être leur signaler l'emplacement dans lequel ils ont installé votre contenu ou rechercher vos fichiers SWF dans leur système de fichiers local.

Scénario application : Gestionnaire de contacts parfois connectés

Pour notre dernier scénario, imaginons que vous développiez une application SWF locale destinée à synchroniser périodiquement des données avec un serveur HTTP et à servir de référentiel local de ces données le reste du temps. Les données en question étant le contenu d'un carnet d'adresses, on pourrait voir cette application comme un « gestionnaire de contacts parfois connectés ».

Disons que vous avez déterminé que vous avez besoin de droits d'Envoi Net, mais pas de droits de Lecture locale. Par exemple, vous n'avez pas besoin de lire des fichiers XML locaux pour la configuration. Ainsi, lors de la publication de vos fichiers SWF, vous activez l'option 'Accès au réseau uniquement' de la Sécurité de lecture locale dans les options de publication de Flash. Vos fichiers SWF sont maintenant libres d'utiliser getURL, XML.load et d'autres opérations HTTP.

Vous allez à présent vous attaquer à la connexion de votre application à la source de données HTTP nécessaire pour la synchronisation. Imaginons que vous utilisiez XML.sendAndLoad() pour échanger des données XML simples. XML.sendAndLoad étant une opération de Lecture Net, vous avez besoin d'un fichier de régulation sur le serveur HTTP avec lequel vous effectuez la synchronisation. Disons maintenant que vous souhaitiez que votre fichier de régulation ne gère que les données concernées, pas la totalité du serveur HTTP. Vous placez alors ce fichier de régulation à côté de la source de données XML et vous appelez System.security.loadPolicyFile dans votre fichier SWF client, en spécifiant l'emplacement du fichier de régulation. Le fichier de régulation a l'aspect suivant :

Le fichier de régulation doit approuver tous les emplacements ("*") de sorte que vos fichiers SWF local/réseau puissent charger les données de votre serveur, tout en respectant le principe d'autorisations globales.

Et ça devrait marcher !

Les diagrammes suivants résument les droits de sécurité locale décrits dans les sections précédentes.

Origines et Sandbox

Lorsqu'ils sont chargés dans Flash Player, tous les fichiers SWF sont placés dans un sandbox. La figure 5 décrit l'affectation des fichiers SWF aux différents sandbox selon leur origine. Les fichiers SWF issus du réseau, par exemple de a.com et b.com, sont toujours placés dans un sandbox qui correspond à leur domaine d'origine.

Les fichiers SWF d'origine locale (de systèmes de fichiers locaux ou de chemins réseau UNC) sont placés dans l'un des trois sandbox. Par défaut, les fichiers SWF locaux sont placés dans le sandbox Local/Système de fichiers. Les fichiers locaux qui réclament un accès réseau sont placés dans le Sandbox local/réseau. Les fichiers locaux enregistrés comme étant de confiance (via le Gestionnaire de paramètres ou un fichier de configuration) sont placés dans le Sandbox Approuvé local. (Dans Flash Player 7 et les versions antérieures, tous les fichiers locaux sont placés dans le Sandbox Approuvé local.)

Deux fichiers SWF placés dans le même sandbox peuvent interagir librement. Les derniers diagrammes présentent les interactions éventuelles des fichiers SWF avec les fichiers SWF issus d'autres sandbox et avec les systèmes de fichiers et serveurs.

Privilèges par défaut

A la figure 5, les flèches représentaient l'origine du fichier SWF. Dans la série de diagrammes suivants, les flèches illustrent cette fois les accès. Les flèches pointillées représentent le chargement des données et les flèches accentuées une programmation croisée. La figure 6 illustre les privilèges dont disposent les fichiers SWF qui arrivent dans les sandbox par défaut.

Par défaut, les fichiers SWF locaux sont placés dans le sandbox Local/Système de fichiers. A partir de ce Sandbox, les fichiers SWF peuvent lire les fichiers d'un système de fichiers local ou de chemins réseau UNC (avec la méthode XML.load() par exemple), mais ne peuvent en aucune manière communiquer avec Internet.

Les droits des fichiers SWF distants sont identiques à ceux accordés par Flash Player 7, sauf qu'ils ne peuvent plus charger de contenu local. Les fichiers SWF distants sont toujours placés dans un Sandbox correspondant à leur domaine d'origine. Depuis le Sandbox a.com, un fichier SWF peut lire (via XML.load() par exemple) sur le serveur de a.com et envoyer des données (via XML.send() par exemple) n'importe où sur Internet.

Autorisations des fichiers SWF distants

La figure 7 illustre les droits non disponibles par défaut des fichiers SWF distants, mais pouvant être accordés par des autorisations spécifiques.

Un fichier SWF provenant de a.com peut lire (via XML.load par exemple) sur le serveur de b.com si ce dernier présente un fichier de régulation qui autorise l'accès à partir de a.com ou de tous les domaines. Un fichier SWF provenant de a.com peut inter-coder un fichier SWF provenant de b.com (en appelant une méthode ActionScript dans le fichier SWF de b.com, par exemple) si le fichier SWF de b.com appelle System.security.allowDomain("a.com"). Ces autorisations étaient disponibles dans Flash Player 7 et n'ont pas changé dans Flash Player 8.

Par défaut, les fichiers SWF distants ne peuvent pas inter-coder les fichiers SWF locaux. Toutefois, les fichiers SWF Local/réseau et Approuvé local sont autorisés à accorder des autorisations de programmation croisée par des fichiers SWF distants, à l'aide de System.security.allowDomain(). Les fichiers SWF Local/Système de fichiers ne sont pas autorisés à accorder de telles autorisations car ils pourraient dans ce cas coopérer avec un fichier SWF distant pour lire les données du système de fichiers local et les envoyer à un serveur Web.

Privilèges des fichiers SWF Approuvé local

La figure 8 présente les droits illimités accordés aux fichiers SWF Approuvé local. Ces derniers peuvent lire les fichiers locaux, interagir avec n'importe quel serveur et programmer n'importe quel autre fichier SWF.

Autorisations des fichiers SWF Local/Système de fichiers

La figure 9 illustre les droits des fichiers SWF Local/Système de fichiers non disponibles par défaut, mais pouvant être accordés par des autorisations spéciales. Les fichiers SWF Local/Système de fichiers peuvent autoriser des fichiers SWF Local/Système de fichiers à les programmer, via System.security.allowDomain("*").

Notez que ces autorisations ne peuvent être accordées à des fichiers SWF Local/Système de fichiers qu'en accordant des autorisations à tous les domaines. Cette condition illustre le fait qu'accorder un accès aux fichiers SWF Local/Système de fichiers revient à accorder un accès à tout le monde puisque Flash Player ne peut pas déterminer l'origine d'un fichier SWF local.

Les autorisations ne peuvent pas être accordées aux fichiers SWF Local/Système de fichiers par des fichiers SWF distants ou Local/Réseau car cela permettrait à tous ces fichiers de coopérer pour lire les données d'un système de fichiers local, puis de les envoyer à un serveur Web.

En l'absence d'autorisation, les fichiers SWF Local/Système de fichiers sont seulement autorisés à charger les données de systèmes de fichiers locaux (via XML.load() par exemple).

Privilèges des fichiers SWF Local/Réseau

La figure 10 illustre les privilèges par défaut dont disposent les fichiers SWF locaux qui se sont déclarés eux-mêmes Local/Réseau plutôt que Local/Système de fichiers. En l'absence d'autorisation, les fichiers SWF Local/Réseau sont seulement autorisés à communiquer avec les autres fichiers SWF Local/Réseau et à envoyer des données aux serveurs (via XML.send() par exemple).

Autorisations des fichiers SWF Local/Réseau

La figure 11 illustre les droits des fichiers SWF Local/Réseau non disponibles par défaut, mais pouvant être accordés par des autorisations spéciales.

Un fichier SWF Local/Réseau est autorisé à lire (via XML.load par exemple) sur le serveur de a.com si ce dernier dispose d'un fichier de régulation qui autorise l'accès à partir de tous les domaines.

Un fichier SWF Local/Réseau peut inter-coder un fichier SWF provenant de a.com (en appelant une méthode ActionScript dans le fichier SWF de a.com, par exemple) si le fichier SWF de a.com appelle System.security.allowDomain("*"). De même, un fichier SWF Local/Réseau sera autorisé à inter-coder un fichier SWF Approuvé local si ce dernier appelle allowDomain("*").

Notez que ces autorisations ne peuvent être accordées à des fichiers SWF Local/Réseau qu'en accordant des autorisations à tous les domaines. Cette condition illustre le fait qu'accorder un accès aux fichiers SWF Local/Réseau revient à accorder un accès à tout le monde puisque Flash Player ne peut pas déterminer l'origine d'un fichier SWF local.

Aucune autorisation ne peut être accordée pour autoriser des fichiers SWF Local/Réseau à lire des fichiers locaux.

Résumé du flux de données

La figure 12 résument les flux de données possibles lorsqu'un ensemble maximal d'autorisations est en vigueur.

Grâce aux autorisations, des fichiers SWF Local/Réseau peuvent librement interagir avec des serveurs et des fichiers SWF distants. Ces autorisations permettent également aux fichiers SWF Approuvé local de communiquer librement avec des ressources réseau et vice versa.

Notez cependant que même avec le maximum d'autorisations, les données ne peuvent pas transiter des systèmes de fichiers locaux à Internet sans passer par un fichier SWF Approuvé local.

Il est possible de développer des applications locales qui intègrent Flash Player, l'incluant à l'interface sous forme de composant. Cela ne s'applique qu'aux applications locales natives, développées en tant que programme exécutable.

Macromedia n'offre pour l'instant pas d'assistance pour ce type d'usage de Flash Player, qui n'est cependant pas interdit. Utiliser Flash Player dans votre application est risqué car vous ne pouvez pas redistribuer Flash Player avec elle et vous dépendez entièrement de la version de Flash Player installée sur les ordinateurs de vos utilisateurs. Les utilisateurs pouvant, à tout moment, effectuer une mise à jour de Flash Player, votre application est alors à la merci de changements de comportement imprévus.

En dépit de ces problèmes, Macromedia s'efforce de contribuer autant que possible au bon déroulement des applications qui intègrent Flash Player.

Le comportement de Flash Player 8 et des versions ultérieures quant à la sécurité locale dans des cas d'intégration est le suivant :

• Lorsqu'il détecte qu'il est hébergé à l'intérieur d'un conteneur non navigateur, le contrôle ActiveX de Flash Player désactive les nouvelles règles de sécurité locales, en plaçant tous les fichiers SWF locaux dans le sandbox Approuvé local. Cela est vrai même si le contrôle ActiveX est instancié au sein d'une occurrence du contrôle ActiveX d'Internet Explorer qui, à son tour, est hébergé à l'intérieur d'un conteneur non navigateur. Notez que seule l'application du conteneur ultime importe. Ainsi, si votre contrôle ActiveX intègre celui de Flash Player qui est, à son tour, intégré dans Internet Explorer, Flash Player détecte qu'il s'exécute à l'intérieur d'un navigateur et il active la sécurité locale.
• Les lecteurs de plug-in de Flash Player ne détectent pas si leur conteneur est, ou non, un navigateur, mais activent toujours les nouvelles règles de sécurité locales par défaut. Toutefois, si les utilisateurs (via le Gestionnaire de paramètres) ou des programmes d'installation (via les fichiers de configuration FlashPlayerTrust) approuvent le chemin d'accès d'une application exécutable qui intègre un plug-in de Flash Player, le plug-in désactive les nouvelles règles de sécurité locales lorsqu'il est intégré à l'exécutable.
• Les lecteurs de contrôle ActiveX et de plug-in disposent d'API exportées qui permettent aux applications hôtes de choisir ou non d'appliquer les nouvelles règles de sécurité locales. Ces API doivent être appelées très tôt dans le cycle de vie de Flash Player, avant le chargement de tout contenu. Voici la liste de ces API :

Si vous développez une application locale qui intègre Flash Player, nous vous conseillons de définir explicitement si vous souhaitez activer ou non les règles de sécurité locales et appeler l'API appropriée. En général, si votre usage de Flash Player inclut la lecture de contenu SWF provenant de sources non contrôlées, par exemple d'Internet, il vaut mieux choisir d'activer les règles de sécurité locales. D'un autre côté, si vous ne lisez que certains fichiers SWF que vous contrôlez et fournissez avec votre application, la désactivation de la sécurité locale vous permettra d'obtenir un maximum de flexibilité.

Les utilisateurs de Flash Player 8 et des versions ultérieures disposent d'une option similaire à ce que fournissent la plupart des navigateurs pour les cookies tiers : Les utilisateurs peuvent désactiver la lecture et l'écriture d'objets partagés persistants côté client par les fichiers SWF provenant de domaines tiers. Par défaut, le stockage tiers est activé. Les utilisateurs peuvent le désactiver dans le Gestionnaire de paramètres de Flash Player en y désactivant l'option 'Autoriser le contenu tiers à stocker des données sur l'ordinateur'. Un fichier SWF tiers est un fichier SWF dont le domaine d'origine diffère du domaine principal visité par l'utilisateur (qui apparaît dans la barre d'adresse du navigateur).

L'option de stockage tiers affecte les objets partagés locaux et leurs cousins moins connus, les objets partagés distants persistants, utilisés uniquement en combinaison avec Flash Media Server (ancien serveur de communication Flash).

Lorsque le stockage tiers est désactivé et qu'un fichier SWF tente d'obtenir un objet partagé à l'aide de SharedObject.getLocal() ou de SharedObject.getRemote(), Flash Player détermine si le fichier SWF à l'origine de l'appel est un fichier tiers ou non. Flash Player compare le domaine d'origine du fichier SWF et le domaine affiché dans la barre d'adresse du navigateur et classifie le fichier SWF comme tiers lorsque les deux domaines ne sont pas exactement identiques. Si le fichier SWF est un fichier tiers, l'appel à getLocal() ou getRemote() renvoie null.

Les restrictions du stockage tiers n'affectent pas les fichiers SWF locaux (chargés depuis le système de fichiers des utilisateurs) mais uniquement les fichiers SWF distants. La classification des fichiers SWF tiers requérant une comparaison avec l'URL d'un navigateur, Flash Player n'observe la restriction tiers que pour une lecture dans le navigateur Web. Les lecteurs autonomes, les projecteurs et les lecteurs de programmation Flash ne le font pas.

Si vous êtes concerné(e) par ce problème

Si votre fichier SWF est réellement un fichier tiers—c'est-à-dire, incorporé dans le site de quelqu'un d'autre—vous devez accepter que certains utilisateurs ne permettront pas à votre fichier SWF de lire ou écrire des objets partagés. Pour en découvrir les raisons, consultez la section suivante.

Si votre fichier SWF est traité comme un fichier tiers mais n'est utilisé qu'au sein de sites que vous contrôlez, il vous faudra peut-être réorganiser votre site de sorte que les fichiers SWF qui doivent lire ou écrire des objets partagés persistants soient toujours servis depuis le domaine principal visité par l'utilisateur.

Pourquoi limiter le stockage tiers ?

Naviguer sur Internet constitue un compromis entre confidentialité et commodité. Les utilisateurs ne peuvent généralement pas éviter de révéler certains faits les concernant, par exemple leurs adresses IP et leur choix de système d'exploitation et de navigateur. Cependant, ils préfèrent également que la plupart des informations qui les concernent directement demeurent confidentielles, sauf lorsqu'ils choisissent de les révéler volontairement à des tiers connus. L'historique de navigation, tel que révélé par le suivi des informations stockées par le contenu Web, est l'un des aspects des profils personnels des utilisateurs largement débattus ces dernières années. Lorsqu'un grand nombre de sites différents gardent une trace de la visite de chaque utilisateur, et que ces sites peuvent ensuite exploiter ces informations pour établir le profil comportemental de navigation des utilisateurs, certaines personnes (et associations de défense de la vie privée des individus) voient dans cette opération une violation des libertés individuelles.

Ces enregistrements de suivi sont généralement stockés en deux emplacements : sur des serveurs Web et sur le propre ordinateur de l'utilisateur. Les technologies de client, telles que les navigateurs Web et Flash Player, n'ayant pas d'influence sur les serveurs Web, cette option demeure à la disposition de ceux qui souhaitent connaître l'historique de navigation des utilisateurs. Toutefois, ce stockage des enregistrements de navigation sur des serveurs présente quelques gros inconvénients : il nécessite à la fois espace de stockage et communication inter-serveurs, tous deux plutôt onéreux. De plus, il est souvent difficile d'identifier un utilisateur parmi de multiples visites car les éléments qui les distinguent, les adresses IP par exemple, varient avec le temps ou peuvent être partagées par plusieurs utilisateurs. Le suivi d'historique préfère donc, si possible, stocker ses enregistrements de navigation directement sur les ordinateurs des utilisateurs, établissant ainsi la liste des sites visités avec un ordinateur donné.

Les deux technologies utilisées pour stocker ces informations sont les cookies de navigateurs et les objets partagés persistants dans Flash. Les navigateurs et Flash Player implémentent une stratégie de sécurité de même origine, qui empêche les sites de lire les cookies ou les objets partagés établis par d'autres sites. Du fait de cette restriction, stocker un enregistrement de navigation dans son propre stock de données ne suffit pas à chaque site participant. Aucun autre site ne pourra se servir de ces informations pour établir un historique complet. Au lieu de cela, la technique généralement utilisée consiste à désigner un domaine unique pour enregistrer toutes les informations historiques, puis de laisser chaque site participant référencer un document historique en écriture à partir de ce domaine, en transmettant les informations d'identification du site à l'URL utilisée pour récupérer le document. Lors des prochaines visites, un document de lecture d'historique issu du domaine commun peut accéder à tous les enregistrements écrits par le document d'écriture de cookie, révélant ainsi la partie de l'historique de navigation de l'utilisateur.

Les navigateurs Web et Flash Player permettent maintenant aux utilisateurs de contrôler ce suivi de leur historique par cette technique en leur donnant la possibilité de désactiver la lecture et l'écriture de données persistantes « tierces ». Un tiers, dans ce cas, est défini comme tout domaine différent du domaine principal visité par l'utilisateur (qui apparaît dans la barre d'adresse du navigateur). Par exemple, si un utilisateur a désactivé le stockage tiers, puis visite le site http://site1.com/index.html, et que index.html inclut http://common.com/writeHistory.html?domain=site1.com, lorsque writeHistory.html tente de lire ou d'écrire des données persistantes, le navigateur ou Flash Player interdit l'opération car common.com est un domaine tiers. L'utilisateur visite le site site1.com dans son navigateur, pas common.com.

allowScriptAccess par défaut

Depuis la version 6, Flash Player prend en charge un paramètre HTML appelé allowScriptAccess. Ce paramètre précise si le code ActionScript d'un fichier SWF est autorisé à appeler le code JavaScript de la page HTML qui le contient, (et pas l'inverse, où JavaScript appelle ActionScript—géré par System.security.allowDomain).

Les valeurs possibles de allowScriptAccess sont les suivantes :

• always: Toujours autoriser les appels ActionScript vers JavaScript
• sameDomain: Autoriser les appels ActionScript vers JavaScript uniquement lorsque le fichier SWF et la page HTML sont issus du même domaine
• never: Ne jamais autoriser les appels ActionScript vers JavaScript

Dans Flash Player 6 et 7, la valeur par défaut de allowScriptAccess (lorsqu'elle n'était pas définie par la page HTML ) était 'always'. Par ailleurs, la valeur par défaut de allowScriptAccess dans les modèles de publication HTML de Flash a toujours été 'sameDomain'. Si vous ne modifiez pas le résultat du processus de publication HTML de Flash, vous obtenez un comportement 'sameDomain' car votre page HTML spécifiera 'sameDomain' à Flash Player.

Dans Flash Player 8, si la valeur n'est pas spécifiée, la valeur par défaut de allowScriptAccess demeure 'always' lorsque le fichier SWF principal dans Flash Player est de version 7 ou antérieure, mais devient 'sameDomain' lorsque le fichier SWF principal est de version 8 ou ultérieure.

Le paramètre allowScriptAccess permet à une page HTML d'inclure du contenu Flash mais l'empêche d'exécuter les scripts de la page HTML. Cela peut se révéler très utile lorsque la page HTML appelle un contenu Flash qui n'est peut-être pas approuvé. Par exemple, si vous développez un forum où les utilisateurs peuvent inclure des signatures SWF qu'ils fabriquent eux-mêmes et que le code HTML généré va directement chercher ces fichiers SWF, vous préférerez probablement que ces derniers ne puissent pas exécuter de scripts dans votre page HTML.

Voici un exemple de définition de allowScriptAccess :

Prise en charge du caractère générique de allowDomain

Remarque<:hs>: Les modifications décrites dans cette section s'appliquent à la fois à System.security.allowDomain() et à System.security.allowInsecureDomain(). Pour plus de clarté, seule l'instruction System.security.allowDomain est décrite, les mêmes modifications étant apportées à System.security.allowInsecureDomain(). Macromedia ne recommande pas l'appel à System.security.allowInsecureDomain() car cette dernière affaiblit la sécurité fournie par SSL (HTTPS).

Depuis Flash Player 8, System.security.allowDomain() accepte le caractère générique astérisque, « * ». Un appel à System.security.allowDomain("*") permet d'accorder un accès en programmation aux fichiers SWF provenant de tous les domaines, pas seulement d'un domaine spécifique.

Cette autorisation générique est très utile lorsque vous n'avez pas de données sensibles à protéger et que vous devez partager les données librement avec d'autres domaines. Toutefois, avant d'appeler System.security.allowDomain("*"), assurez-vous que le fichier SWF qui effectue l'appel ne contient pas d'information ou de code ActionScript devant rester confidentiel ou semi privé. Après l'appel à System.security.allowDomain("*"), tous les fichiers SWF provenant d'Internet, quelle que soit leur provenance, peuvent charger votre fichier SWF et le coder, même les fichiers SWF écrits par des auteurs malveillants.

Notez que vous devrez peut-être parfois appeler System.security.allowDomain() sans même connaître le domaine d'où proviendra le fichier SWF avant l'exécution, par exemple parce que ce fichier provient d'un cluster d'équilibrage de charges ou que votre fichier SWF sera utilisé sur de nombreux domaines différents. Dans ce cas, n'appelez pas System.security.allowDomain("*") à l'aveuglette ! Comme nous venons de le dire, n'importe quel autre fichier SWF issu d'Internet peut alors coder votre fichier SWF. Attendez plutôt le chargement du fichier SWF coopérant, puis déterminez son domaine via la propriété ActionScript MovieClip._url. Après le transfert de la valeur de la propriété _url à System.security.allowDomain(), le fichier SWF du clip référencé doit alors pouvoir coder le fichier SWF à l'origine de l'appel de System.security.allowDomain().

Flash Player 8 permet aux fichiers SWF de toute version de passer "*" à System.security.allowDomain(). Toutefois, si vous envisagez d'appeler System.security.allowDomain("*") dans un fichier SWF de version antérieure à la version 8, n'oubliez pas de vérifier que la version du lecteur (System.capabilities.version) correspond au moins à la version 8 avant de procéder, car les versions précédentes de Flash Player ne reconnaîtront par le caractère "*" comme un argument transmis à System.security.allowDomain.

Autorisations plus précises

Remarque<:hs>: Les modifications décrites dans cette section s'appliquent à la fois à System.security.allowDomain() et à System.security.allowInsecureDomain(). Pour plus de clarté, seule l'instruction System.security.allowDomain est décrite, les mêmes modifications étant apportées à System.security.allowInsecureDomain(). Macromedia ne recommande pas l'appel à System.security.allowInsecureDomain() car cette dernière affaiblit la sécurité fournie par SSL (HTTPS).

Lorsque vous appelez System.security.allowDomain(), deux parties sont impliquées dans l'autorisation établie : la partie qui accorde, correspondant au fichier SWF qui appelle System.security.allowDomain(), et la partie qui utilise, correspondant aux domaines spécifiés dans l'argument transmis à System.security.allowDomain(). Une fois l'autorisation établie, tous les fichiers SWF provenant du domaine d'utilisation peuvent coder le fichier SWF qui accorde l'autorisation.

Dans Flash Player 6 et 7, tous les fichiers SWF provenant du domaine d'utilisation pouvaient non seulement coder les fichiers SWF d'accord eux-mêmes, mais également ceux qui provenaient du domaine du fichier SWF d'accord. La partie qui accordait était davantage considérée comme un domaine d'accord plutôt que comme un fichier d'accord. Par exemple, lorsqu'un fichier SWF provenant de http://site1.com/app1.swf appelait System.security.allowDomain("site2.com"), un fichier SWF provenant de http://site2.com/another.swf pouvait coder soit le fichier SWF d'accord, provenant de http://site1.com/app1.swf, ou tout autre fichier SWF chargé depuis site1.com, tel que http://site1.com/different.swf.

Ce dispositif donnait parfois d'étranges résultats. L'administrateur du site1.com peut gérer de nombreuses applications Flash différentes n'ayant aucun rapport entre elles, et certaines de ces applications peuvent avoir besoin d'autoriser un accès par un domaine extérieur, mais pas toutes les applications du site1.com. Il est possible que l'auteur de app1.swf n'est pas réalisé que, en appelant System.security.allowDomain("site2.com"), il autorisait non seulement l'accès à app1.swf mais également à different.swf.

Lorsqu'un fichier SWF de version 8 ou ultérieure appelle System.security.allowDomain(), le fichier SWF à l'origine de l'appel est la seule partie qui accorde. Si deux fichiers SWF différents issus du même domaine souhaitent tous deux accorder un accès à un domaine extérieur, chacun d'eux doit appeler System.security.allowDomain().

Ce comportement ne s'applique qu'aux fichiers SWF de version 8 ou ultérieure. Les fichiers SWF de version 6 ou 7 qui appellent System.security.allowDomain(), même lors d'une lecture dans Flash Player 8, continueront à accorder un accès à tous les fichiers SWF de version 6 et 7 de leur propre domaine afin de préserver la compatibilité ascendante. Toutefois, un fichier SWF de version 6 ou 7 qui appelle System.security.allowDomain() n'accordera pas un accès aux fichiers SWF de version 8 ou ultérieure de son propre domaine.

Le même changement de comportement a été apporté pour System.exactSettings, qui détermine si un fichier SWF utilisera son super-domaine de style Flash 6 (par exemple, monsite.com est le super-domaine de www.monsite.com) ou son domaine exact de style Flash 7 (par exemple, www.monsite.com) comme base pour les autorisations appareil photo/microphone et les objets partagés persistants. Dans Flash Player 7, lorsque l'un des fichiers SWF d'un domaine modifiait la valeur de System.exactSettings, cette modification s'appliquait à tous les fichiers SWF du même domaine. Dans les fichiers SWF de version 8 ou ultérieure, la définition de System.exactSettings ne concerne que le fichier SWF à l'origine de l'appel.

Objets partagés persistants sécurisés

Dans Flash Player 8 et les versions ultérieures, un fichier SWF provenant d'une URL HTTPS peut spécifier, lors de la lecture ou de l'écriture d'un objet partagé persistant, qu'il souhaite utiliser un stock d'objets partagés distinct, uniquement accessible aux fichiers SWF servis via HTTPS. Ces objets partagés seront protégés contre les attaques éventuelles décrites ci-dessous. Outre l'obligation HTTPS, les règles régissant les accès aux objets partagés conservés dans un stock sécurisé sont les mêmes que pour les objets partagés non sécurisés : Par défaut, seul un fichier SWF provenant de la même URL que le créateur d'origine peut accéder à l'objet partagé, mais si le créateur a spécifié une option localPath plus courte que son URL complète, les fichiers SWF dont les URL commencent par le même préfixe peuvent également accéder à l'objet partagé en spécifiant le même localPath.

Récupération d'un objet partagé sécurisé

Pour récupérer un objet partagé sécurisé, transmettez la valeur 'true' pour le nouveau paramètre facultatif appelé secure à SharedObject.getLocal() ou SharedObject.getRemote():

(Notez que les objets partagés distants requièrent Flash Media Server et ne sont documentés qu'avec ce produit.)

Par exemple, pour récupérer un objet partagé local sécurisé :

(La valeur null de localPath équivaut à omettre entièrement localPath, aussi transmettez cette valeur null de localPath si vous souhaitez un objet partagé sécurisé avec le localPath par défaut.)

Notez que l'indicateur secure est défini par défaut sur 'false', ce qui signifie qu'aucun fichier SWF créé avec une version antérieure à Flash Player 8 ne sera affecté par cette nouvelle fonctionnalité—seuls les fichiers SWF qui demandent explicitement des objets partagés sécurisés utiliseront le nouveau stock sécurisé distinct. Tous les objets partagés créés par des fichiers SWF antérieurs, HTTPS ou non, résident dans le stock non sécurisé d'origine.

Lorsqu'un fichier SWF provenant d'une URL non HTTPS transmet la valeur 'true' pour le paramètre secure, l'appel à getLocal() ou getRemote() renvoie null.

N'oubliez pas que, les objets partagés sécurisés et non sécurisés provenant d'espaces entièrement distincts, il est possible d'obtenir deux objets partagés persistants (l'un sécurisé et l'autre non) de mêmes noms, localPaths et domaines, mais pourtant distincts. Par exemple, si un fichier SWF HTTPS crée un objet partagé sécurisé nommé 'userInfo' et un localPath de '/', et que par la suite un fichier SWF HTTP récupère un objet partagé non sécurisé nommé 'userInfo' et un localPath de '/', ce deuxième objet partagé sera en fait distinct du premier car les deux objets proviennent de stocks différents.

Pourquoi utiliser des objets partagés sécurisés ?

Les objets partagés persistants sécurisés offrent une protection contre un type potentiel de tentatives d'accès aux données sensibles par des parties non autorisées.

Le protocole HTTPS fournit plusieurs protections importantes. La plus connue d'entre elles est le cryptage, qui empêche les tiers de voir le contenu des conversations qui circulent sur le réseau. Cependant, un autre avantage important de ces protections est l'intégrité, qui permet d'être certain que, lorsqu'une partie envoie des données à l'autre, les données arrivent sans modification ou, lorsqu'elles ont été modifiées, la modification est détectée et les données sont rejetées comme non valides. Cela permet de déjouer ce que l'on appelle une attaque man-in-the-middle, qui profite de la nature disséminée d'Internet : une partie au centre de la conversation réseau, par exemple l'employé d'un fournisseur de services, un opérateur réseau, un serveur proxy, un pare-feu, etc., peut non seulement écouter une conversation mais également modifier les données envoyées dans l'une ou l'autre direction, en y insérant éventuellement son propre document qui agit au nom et à l'insu de l'expéditeur. Par exemple, si un utilisateur visite le site 'example.com' et affiche un fichier SWF qui demande des identifiants de connexion, un attaquant man-in-the-middle pourrait y substituer ses propres identifiants, un fichier SWF presque identique qui enverrait non seulement les informations de connexion de l'utilisateur au destinataire prévu mais également à l'attaquant. Toutefois, si la connexion est sécurisée via HTTPS, le fichier SWF modifié de l'attaquant sera rejeté lorsque le client le reçoit et l'attaque échouera.

Pour finir, une autre attaque similaire est basée sur l'usurpation d'identité d'un site fournissant un fichier SWF. Elle profite des failles des systèmes DNS ou autres utilisés pour identifier un serveur. Une autre propriété du protocole HTTPS appelée authentification permet de déjouer ce type d'attaque en vérifiant l'identité du serveur à l'aide de certificats SSL. Pour ce qui nous concerne, la présentation d'une attaque man-in-the-middle suffit pour traiter ce type d'attaques et celles d'usurpation d'identité.

Si vous diffusez un fichier SWF via HTTPS et que vous écrivez un objet partagé persistant à partir de ce fichier, vous avez de bonnes raisons de souhaiter que les données de cet objet partagé demeurent exclusivement à la disposition de vos propres fichiers SWF et, avant tout, de l'utilisateur. Par exemple, si vous enregistrez des informations sensibles dans un objet partagé persistant, comme des informations de comptes ou des données financières. Dans l'idéal, vous souhaiterez vous assurer que, si l'un de vos utilisateurs est victime d'une attaque man-in-the-middle, l'attaquant ne puisse pas accéder aux données de cet objet partagé.

Dans Flash Player 7, si votre fichier SWF HTTPS a écrit un objet partagé et qu'un utilisateur a été ensuite trompé par un attaquant man-in-the-middle en visitant une URL de votre site qui permet d'accéder à un objet partagé—en fait, vraisemblablement l'URL même d'où provient votre fichier SWF—mais avec la différence cruciale que le protocole utilisé est HTTP et non pas HTTPS, l'attaquant peut alors envoyer son propre fichier SWF et Flash Player pensera alors qu'il provient de votre site. Le fichier SWF de l'attaquant peut alors lire l'objet partagé et envoyé son contenu à l'attaquant.

Ces attaques sont bien entendu difficiles à organiser. Si vous avez déjà déployé des fichiers SWF HTTPS qui écrivaient des données sensibles dans des objets partagés persistants, il est peu probable que quiconque ait tenté d'y accéder par ce type d'attaque. Toutefois, pour optimiser votre future protection, si vous stockez des données sensibles dans des objets partagés persistants, envisagez de sécuriser ces objets.

Pour en savoir plus

En tant que l'un des éléments logiciels les plus distribués dans le monde, Flash Player mérite sa place sur tant d'ordinateurs et de périphériques du fait de ces formidables capacités multimédia et de sa fiabilité. En plus de ces nouvelles capacités d'expression et de ses performances améliorées, Flash Player 8 accroît la sécurité de la navigation sur le Web pour ses centaines de millions d'utilisateurs. Ce fait ne doit pas être ignoré. Flash Player conservera sa réputation auprès des professionnels de la sécurité en tant que logiciel responsable qui permet aux utilisateurs de garder le contrôle de leurs données personnelles.

Les améliorations présentées dans cet article ne sont pas sans conséquences. Une petite fraction des millions de fichiers SWF circulant de par le monde aura, bien involontairement, été affectée par ces nouvelles protections d'une façon que leurs auteurs ne pouvaient prévoir. Nous ne prenons pas ces conséquences à la légère et avons passé un temps considérable à soupeser les avantages et les inconvénients de ces modifications de la sécurité. Flash a acquis une solide réputation de technologie à « déploiement unique et sans souci ultérieur ». Les nouvelles versions de Flash Player lisent aussi bien les anciens contenus Flash que lors de leur première publication. Néanmoins, nos responsabilités envers les utilisateurs de Flash Player nous tiennent à coeur. En faisant en sorte que Flash Player mérite la confiance de chacun, nous contribuons à la prospérité à long terme de l'univers du multimédia enrichi.