Présentation des contrôles d'autorisation -- Flash CS3

Le modèle de sécurité d'exécution du client Flash Player a été conçu autour des ressources, c'est-à-dire des objets tels que des fichiers SWF, des données locales et des URL Internet. Les parties prenantes sont celles qui détiennent ou utilisent ces ressources. Elles peuvent exercer un contrôle (via des paramètres de sécurité) sur leurs propres ressources, chaque ressource ayant quatre parties prenantes. Flash Player applique une stricte hiérarchie d'autorité sur ces contrôles, comme le montre l'illustration suivante :

Ainsi, par exemple, si un administrateur restreint l'accès à une ressource, aucune autre partie prenante ne peut revenir sur cette restriction.

Les contrôles administrateur, utilisateur et de site Web sont décrits dans les sections suivantes. Les paramètres de création (développeur) sont présentés dans le reste du chapitre.

Sous-rubriques

Contrôles administrateur

L'administrateur d'un ordinateur (un utilisateur ayant ouvert une session avec des droits d'administration) peut définir des paramètres de sécurité Flash Player qui s'appliquent à tous les utilisateurs de l'ordinateur. Dans un environnement autre que l'entreprise, par exemple un ordinateur domestique, un utilisateur dispose aussi d'un accès administrateur. Même au sein d'une entreprise, certains utilisateurs peuvent posséder des droits d'administration sur l'ordinateur.

Fichier mms.cfg

Sur les systèmes Mac OS X, le fichier mms.cfg se trouve dans /Library/Application Support/Macromedia/mms.cfg. Sur les systèmes Microsoft Windows, ce fichier se situe dans le dossier Macromedia Flash Player du répertoire système (par exemple C:\windows\system32\macromed\flash\mms.cfg, dans le cas d'une installation par défaut sous Windows XP).

Lors du lancement de Flash Player, l'application lit les paramètres de sécurité dans ce fichier, puis les utilise pour limiter la fonctionnalité.

Le fichier mms.cfg inclut des paramètres que l'administrateur utilise pour effectuer les tâches suivantes :

Un fichier SWF peut obtenir des informations sur les fonctions désactivées en appelant les propriétés Capabilities.avHardwareDisable et Capabilities.localFileReadDisable. Toutefois, la plupart des paramètres du fichier mms.cfg ne peuvent être interrogés à partir d'ActionScript.

Pour mettre en place sur un ordinateur des stratégies de confidentialité et de sécurité indépendantes des applications, le fichier mms.cfg doit être uniquement modifié par un administrateur système. Le fichier mms.cfg n'est pas destiné aux programmes d'installation des applications. Bien qu'un programme d'installation exécuté avec des privilèges administrateur puisse modifier le contenu du fichier mms.cfg, Adobe considère cette pratique comme une violation de la confiance de l'utilisateur et presse les créateurs de programmes d'installation de ne jamais modifier le fichier mms.cfg.

Répertoire Flash Player Trust global

Les administrateurs et programmes d'installation peuvent approuver des fichiers SWF locaux spécifiques. Ces fichiers SWF sont associés au sandbox local approuvé. Ils peuvent interagir avec tout autre fichier SWF puisqu'ils peuvent charger des données stockées localement ou à distance. Les fichiers sont désignés comme approuvés dans le répertoire Flash Player Trust global, qui se trouve dans le même répertoire que le fichier mms.cfg, aux emplacements suivants (en fonction de l'utilisateur actif):

Le répertoire Flash Player Trust peut contenir un nombre illimité de fichiers texte, chacun répertoriant des chemins d'accès approuvés, à raison d'un chemin par ligne. Chaque chemin d'accès peut mener à un fichier SWF ou HTML, ou à un répertoire. Les lignes de commentaire commencent par le symbole #. Par exemple, un fichier de configuration Flash Player contenant le texte suivant approuve tous les fichiers placés dans le répertoire spécifié et ses sous-répertoires :

# Trust files in the following directories:
C:\Documents and Settings\All Users\Documents\SampleApp

Les chemins répertoriés dans un fichier de configuration Trust doivent toujours faire référence au système local ou à un réseau SMB. Les chemins d'accès HTTP placés dans un fichier de configuration Trust sont ignorés ; seuls les fichiers locaux peuvent être approuvés.

Pour éviter les conflits, attribuez au fichier de configuration Trust un nom correspondant à l'application installée, suivi de l'extension de fichier .cfg.

En tant que développeur diffusant un fichier SWF à exécuter localement par le biais d'un programme d'installation, vous pouvez faire en sorte que ce programme d'installation ajoute un fichier de configuration au répertoire Flash Player Trust global afin d'accorder des privilèges complets au fichier que vous diffusez. Le programme d'installation doit être exécuté par un utilisateur doté de droits d'administration. Contrairement au fichier mms.cfg, le répertoire Flash Player Trust global est prévu pour les programmes d'installation devant accorder des autorisations. Il permet aux administrateurs et aux programmes d'installation de désigner des application locales approuvées.

Il existe également des répertoires Flash Player Trust destinés aux utilisateurs individuels (voir la section suivante Contrôles utilisateur)

Contrôles utilisateur

Flash Player fournit trois mécanismes de définition des autorisations pour les utilisateurs : l'interface de paramétrage, le Gestionnaire des paramètres et le répertoire Flash Player Trust utilisateur.

Interface de paramétrage et Gestionnaire des paramètres

L'interface de paramétrage est un mécanisme interactif qui permet de configurer rapidement les paramètres d'un domaine donné. Le Gestionnaire des paramètres, avec son interface plus détaillée, permet d'effectuer des modifications globales sur les autorisations de plusieurs domaines ou de tous. En outre, si un fichier SWF requiert une nouvelle autorisation qui oblige à prendre des décisions en cours d'exécution concernant la sécurité ou la confidentialité, des boîtes de dialogue s'affichent dans lesquelles les utilisateurs peuvent régler certains paramètres de Flash Player.

Le Gestionnaire des paramètres et l'interface de paramétrage proposent les options de sécurité suivantes :

Répertoire Flash Player Trust utilisateur

Les utilisateurs et programmes d'installation peuvent approuver des fichiers SWF locaux spécifiques. Ces fichiers SWF sont associés au sandbox local approuvé. Ils peuvent interagir avec tout autre fichier SWF puisqu'ils peuvent charger des données stockées localement ou à distance. Pour approuver un fichier, l'utilisateur le désigne dans le répertoire Flash Player Trust utilisateur, qui se trouve dans le même répertoire que la zone de stockage des objets partagés Flash, aux emplacements suivants (ces emplacements sont spécifiques à l'utilisateur actif) :

Ces paramètres s'appliquent uniquement à l'utilisateur actif, et non aux autres utilisateurs qui ouvrent une session sur l'ordinateur. Si un utilisateur sans droits d'administration installe une application dans sa partie réservée du système, le répertoire Flash Player Trust utilisateur permet au programme d'installation d'enregistrer cette application comme approuvée pour l'utilisateur en question.

En tant que développeur diffusant un fichier SWF à exécuter localement par le biais d'un programme d'installation, vous pouvez faire en sorte que ce programme d'installation ajoute un fichier de configuration au répertoire Flash Player Trust utilisateur afin d'accorder des privilèges complets au fichier que vous diffusez. Même dans ce cas de figure, le fichier placé dans le répertoire Flash Player Trust utilisateur constitue un contrôle utilisateur puisque son initialisation résulte d'une action de l'utilisateur (l'installation).

Il existe également un répertoire Flash Player Trust global utilisé par l'administrateur ou les programmes d'installation pour enregistrer une application destinée à l'ensemble des utilisateurs d'un ordinateur (voir Contrôles administrateur).

Contrôles de site Web (fichiers de régulation interdomaine)

Si vous souhaitez rendre les données d'un serveur Web accessibles aux fichiers SWF issus de domaines différents, vous pouvez créer un fichier de régulation interdomaine sur votre serveur. Un fichier de régulation interdomaine est un fichier XML qui permet au serveur d'indiquer que ses données et ses documents sont disponibles pour les fichiers SWF servis à partir de certains domaines ou de tous les domaines. Tout fichier SWF servi à partir d'un domaine spécifié par le fichier de régulation du serveur peut accéder aux données et aux ressources de ce serveur.

Les fichiers de régulation interdomaine ont une incidence sur l'accès à certains actifs, notamment les suivants :

Des informations détaillées sont fournies à ce sujet dans le reste de ce chapitre.

Syntaxe du fichier de régulation

L'exemple suivant présente un fichier de régulation qui autorise l'accès à des fichiers SWF issus des domaines *.example.com, www.friendOfExample.com et 192.0.34.166 :

<?xml version="1.0"?>
<cross-domain-policy>
    <allow-access-from domain="*.example.com" />
    <allow-access-from domain="www.friendOfExample.com" />
    <allow-access-from domain="192.0.34.166" />
</cross-domain-policy>

Lorsqu'un fichier SWG essaie d'accéder aux données depuis un autre domaine, Flash Player essaie automatiquement de charger un fichier de régulation depuis ce domaine. Si le domaine du fichier SWF qui tente d'accéder aux données est inclus dans le fichier de régulation, les données sont automatiquement accessibles.

Par défaut, les fichiers de régulation sont nommés crossdomain.xml et doivent résider dans le répertoire racine du serveur. Cependant, un fichier SWF peut effectuer une recherche sur un nom de fichier ou un emplacement différent en appelant la méthode Security.loadPolicyFile(). Un fichier de régulation interdomaine s'applique uniquement au répertoire dans lequel il est chargé et à ses sous-répertoires. Ainsi, un fichier de régulation placé dans le répertoire racine s'applique à l'ensemble du serveur. En revanche, un fichier de régulation chargé d'un sous-répertoire quelconque s'applique uniquement à celui-ci et à ses sous-répertoires.

Un fichier de régulation contrôle uniquement l'accès au serveur sur lequel il réside. Par exemple, un fichier de régulation situé dans https://www.adobe.com:8080/crossdomain.xml ne s'applique qu'aux appels de chargement de données transmis à www.adobe.com sur HTTPS au port 8080.

Un fichier de régulation interdomaine contient une seule balise <cross-domain-policy>, qui contient elle-même aucune ou plusieurs balises <allow-access-from>. Chaque balise <allow-access-from> contient un attribut domain qui spécifie soit une adresse IP exacte, un domaine exact ou un domaine générique (tout domaine). Les domaines génériques sont signalés par un astérisque (*) seul, qui correspond à tous les domaines et à toutes les adresses IP, ou par un astérisque suivi d'un suffixe, qui correspond uniquement aux domaines se terminant par le suffixe spécifié. Les suffixes doivent commencer par un point. Cependant, les domaines génériques suivis de suffixes peuvent correspondre à des domaines qui sont composés uniquement du suffixe sans le point de séparation. Par exemple, foo.com est considéré comme un élément de *.foo.com. Les caractères génériques ne sont pas autorisés dans les spécifications de domaine IP.

Si vous spécifiez une adresse IP, seuls les fichiers SWF chargés depuis cette adresse IP à l'aide de la syntaxe IP (par exemple, http://65.57.83.12/flashmovie.swf) sont accessibles ; les fichiers chargés à l'aide d'une syntaxe domaine-nom sont inaccessibles. Flash Player n'effectue pas de résolution DNS.

Vous pouvez autoriser l'accès à des documents provenant de tout autre domaine, comme indiqué dans l'exemple suivant :

<?xml version="1.0"?>
<!-- http://www.foo.com/crossdomain.xml -->
<cross-domain-policy>
  <allow-access-from domain="*" />
</cross-domain-policy>

Chaque balise <allow-access-from> peut présenter l'attribut facultatif secure, dont la valeur par défaut est true. Vous pouvez définir cet attribut sur false si le fichier de régulation figure sur un serveur HTTPS et si vous autorisez les fichiers situés sur un serveur non HTTPS à charger des données à partir d'un serveur HTTPS.

La définition de l'attribut secure sur false risque de compromettre la sécurité fournie par le protocole HTTPS. Plus particulièrement, la définition de cet attribut sur false rend le contenu sécurisé vulnérable aux attaques d'espionnage. Adobe recommande vivement de ne pas définir l'attribut secure sur false.

Si les données à charger se trouvent sur un serveur HTTPS mais que le fichier SWF à l'origine du chargement se situe sur un serveur HTTP, Adobe recommande de placer le fichier SWF sur un serveur HTTPS de manière que toutes les données sécurisées soient sous la protection de HTTPS. Cependant si vous décidez que vous devez conserver le fichier SWF à l'origine du chargement sur un serveur HTTP, ajoutez l'attribut secure="false" à la balise <allow-access-from>, comme le montre le code suivant :

<allow-access-from domain="www.example.com" secure="false" />

Un fichier de régulation ne contenant aucune balise <allow-access-from> revient à ne pas avoir de régulation sur un serveur.

Fichiers de régulation socket

Les objets ActionScript instancient deux différents types de connexions serveur : des connexions liées à des documents et des connexions socket. Les objets ActionScript tels que Loader, Sound, URLLoader et URLStream instancient des connexions serveur liées à des documents, chacun de ces objets permettant de charger un fichier à partir d'une URL. Les objets ActionScript Socket et XMLSocket établissent des connexions socket, qui fonctionnent avec des flux de données et non des documents chargés. Flash Player prend en charge deux types de fichiers de régulation : des fichiers de régulation liés à des documents et des fichiers de régulation socket. Les connexions liées à des documents nécessitent des fichiers de régulation du premier type, alors que les connexions socket exigent des fichiers de régulation socket.

Pour le transfert du fichier de régulation, Flash Player impose qu'il s'effectue suivant le même protocole que la connexion elle-même. Par exemple, si vous placez un fichier de régulation sur un serveur HTTP, les fichiers SWF issus d'autres domaines sont autorisés à charger les données qu'il contient en tant que serveur HTTP. Cependant, si vous ne fournissez aucun fichier de régulation socket sur ce même serveur, vous empêchez les fichiers SWF issus d'autres domaines d'accéder au serveur au niveau socket. La méthode de récupération du fichier de régulation socket doit correspondre à la méthode de connexion.

La syntaxe des fichiers de régulation transmis par un serveur socket est identique à celle des autres fichiers de régulation, à l'exception près que ces fichiers doivent également spécifier les ports auxquels ils permettent d'accéder. Un fichier de régulation transmis via un port dont le numéro est inférieur à 1024 peut autoriser l'accès à tous les ports. Un fichier de régulation transmis via le port 1024 ou supérieur ne peut définir l'accès qu'au port 1024 et aux ports supérieurs. Les ports accessibles sont spécifiés par l'attribut to-ports dans la balise <allow-access-from>. Il est possible d'utiliser des numéros de ports, des plages de ports et des caractères génériques.

<cross-domain-policy> 
   <allow-access-from domain="*" to-ports="507" /> 
   <allow-access-from domain="*.example.com" to-ports="507,516" /> 
   <allow-access-from domain="*.example2.com" to-ports="516-523" /> 
   <allow-access-from domain="www.example2.com" to-ports="507,516-523" /> 
   <allow-access-from domain="www.example3.com" to-ports="*" /> 
</cross-domain-policy>

Lors de l'introduction des fichiers de régulation dans Flash Player 6, les fichiers socket n'étaient pas pris en charge. Les connexions aux serveurs socket étaient autorisées par un fichier de régulation issu de l'emplacement par défaut du fichier de régulation interdomaine sur un serveur HTTP à condition d'utiliser le port 80 du même hôte que le serveur socket. Pour qu'il soit possible de conserver les organisations de serveurs existantes, Flash Player 9 continue de prendre en charge cette fonction. Cependant, par défaut, Flash Player récupère désormais le fichier de régulation socket sur le même port que la connexion socket. Si vous utilisez un fichier de régulation sur HTTP pour autoriser une connexion socket, vous devez explicitement demander le fichier de régulation HTTP à l'aide d'un code tel que celui-ci :

Security.loadPolicyFile("http://socketServerHost.com/crossdomain.xml")

En outre, pour autoriser les connexions socket, un fichier de régulation HTTP doit provenir exclusivement de l'emplacement par défaut du fichier de régulation inter-domaines et d'aucun autre emplacement HTTP. Un fichier de régulation obtenu d'un serveur HTTP autorise implicitement l'accès socket aux ports 1024 et supérieurs ; les éventuels attributs to-ports dans ce type de fichier sont ignorés.

Pour plus d'informations sur les fichiers de régulation socket, voir Connexion aux sockets.

Préchargement des fichiers de régulation

Le chargement de données à partir d'un serveur ou la connexion à un socket est une opération asynchrone ; Flash Player attend que le fichier de régulation interdomaine soit entièrement téléchargé avant de commencer l'opération principale. Cependant, l'extraction de données de pixels dans des images ou de données échantillon à partir de fichiers son est une opération synchrone ; le fichier de régulation interdomaine doit se charger avant de permettre l'extraction des données. Lors du chargement du média, vous devez spécifier que le fichier de régulation interdomaine doit être vérifié :

Lorsque vous définissez l'un des ces paramètres, Flash Player commence par vérifier si des fichiers de régulation ont déjà été téléchargés pour ce domaine. Il examine ensuite tous les appels en attente à la méthode Security.loadPolicyFile() pour voir s'ils correspondent au domaine. Si tel est le cas, il attend leur exécution. Dans un troisième temps, il recherche le fichier de régulation interdomaine à l'emplacement par défaut sur le serveur.

Contrôles de création (développeur)

L'API ActionScript principale utilisée dans l'attribution des privilèges de sécurité est la méthode Security.allowDomain(), qui accorde des droits aux fichiers SWF du domaine que vous spécifiez. Dans l'exemple suivant, un fichier SWF autorise l'accès des fichiers SWF servis à partir du domaine www.example.com :

Security.allowDomain("www.example.com")

La méthode Security.allowDomain() sert avant tout à permettre aux fichiers SWF situés dans un domaine externe d'effectuer une programmation croisée avec le fichier SWF qui appelle la méthode Security.allowDomain(). Pour plus d'informations, voir Programmation croisée.

La spécification de l'adresse IP en tant que paramètre de Security.allowDomain() n'autorise pas l'accès de toutes les parties provenant de l'adresse IP spécifiée. Au contraire, elle autorise l'accès d'une partie présentant une URL identique à l'adresse IP spécifiée, plutôt qu'un nom de domaine renvoyant à l'adresse IP. Par exemple, si le nom de domaine www.example.com renvoie à l'adresse IP 192.0.34.166, un appel à Security.allowDomain("192.0.34.166") ne donne pas accès à www.example.com.

Vous pouvez transmettre le caractère générique "*" à la méthode Security.allowDomain() pour permettre l'accès à partir de tous les domaines. Soyez prudent lorsque vous utilisez le caractère générique "*" car celui-ci autorise les fichiers SWF issus de tous les domaines à effectuer une programmation dans le fichier SWF appelant.

ActionScript inclut une seconde API d'autorisation appelée Security.allowInsecureDomain(). Cette méthode joue le même rôle que la méthode Security.allowDomain() à la différence suivante : lorsqu'elle est appelée à partir d'un fichier SWF servi par une connexion HTTPS, elle autorise l'accès à ce fichier appelant pour d'autres fichiers SWF servis à partir d'un protocole non sécurisé, tel HTTP. Cependant, il est déconseillé de permettre la programmation croisée entre des fichiers issus d'un protocole sécurisé et ceux provenant d'un protocole qui ne l'est pas. Cette pratique est susceptible de rendre le contenu vulnérable aux attaques d'espionnage. Voici comment fonctionnent ces attaques : puisque la méthode Security.allowInsecureDomain() permet aux fichiers SWF servis sur des connexions HTTP d'accéder aux données HTTPS sécurisées, un attaquant qui s'interposerait entre le serveur HTTP et les utilisateurs pourraient remplacer votre fichier SWF HTTP par un fichier de son cru afin d'accéder à vos données HTTPS.

Autre méthode importante liée à la sécurité, Security.loadPolicyFile() permet à Flash Player de rechercher le fichier de régulation interdomaine à un autre emplacement. Pour plus d'informations, voir Contrôles de site Web (fichiers de régulation interdomaine).