Astuce Guide sur les fichiers de stratégie inter-domaines

Tous les développeurs Flash ou Flex ayant eu à accéder à des ressources distantes ont rencontré un fichier de stratégie crossdomain.xml à un moment donné. Cet article examine la nature de ces fichiers de stratégie, leur fonctionnement et la manière dont vous pouvez en créer un pour vous-même..

Exemple

Jetons un coup d'oeil à un exemple de ce dont nous parlons:

Quel est si spécial à ce sujet? Eh bien, le fichier SWF charge l'image de smiley à partir de http://mytestgae.appspot.com/images/smiley.jpg, pas à partir du domaine Activetuts +. Sans fichier de stratégie interdomaine, toute tentative de chargement de l'image déclencherait une erreur SecurityError..

Qu'est-ce qu'un fichier de stratégie interdomaine??

Le modèle de sécurité connu sous le nom de stratégie de "même origine", mis en œuvre par la plupart des navigateurs Web modernes, empêche l'accès ou la modification de certains types de contenu si le fichier existe dans un autre domaine. Ce n'est pas une règle absolue. Les pages HTML afficheront avec plaisir les images et le code HTML des pages d'autres domaines. Mais pour JavaScript, la même politique d'origine empêche un document ou un script chargé à partir d'une origine d'obtenir ou de définir les propriétés d'un document à partir d'une autre..

Flash inclut une stratégie de sécurité similaire qui empêche généralement une application Flash d’accéder aux données hébergées sur un domaine distant. Cependant, dans de nombreuses circonstances, il est non seulement utile, mais attendu, que les ressources soient accessibles à distance. Un album photo en ligne se trouverait limité si des applications externes ne pouvaient pas télécharger ses images. Il serait également ridicule qu'un service Web n'autorise pas les applications extérieures à interagir avec lui..

Pour cette raison, il est possible de créer un fichier XML, appelé crossdomain.xml, spécifiant comment les données d'un domaine peuvent être consultées par une application Flash hébergée sur un domaine distant. Pour la plupart, ces fichiers de règles sont assez simples, mais il est utile de connaître quelques détails..

Si vous hébergez du contenu auquel vous souhaitez accéder par des applications Flash externes, vous devez créer un fichier crossdomain.xml. Commençons par regarder un exemple de base.

Étape 1: Un fichier crossdomain.xml de base

Voici un fichier très simple crossdomain.xml. Lorsque ce fichier est hébergé à la racine de votre domaine, il permet aux applications Flash externes d’accéder à toutes les ressources de votre domaine..

Le fichier de politique contient un seul étiquette. À l'intérieur de cela, vous pouvez avoir zéro ou plus Mots clés. Chaque tag peut être utilisé pour définir un domaine ou une adresse IP à partir duquel une application Flash peut accéder aux ressources locales. L'attribut domaine = "*" spécifie que tous les domaines ont accès. C’est grâce au caractère générique astérisque, qui est utilisé ici pour faire correspondre tous les domaines et adresses IP.

Dans la plupart des situations, ce fichier de stratégie "autoriser tout" est suffisant. Il accorde aux applications Flash l’accès à toutes les ressources publiques, tandis que toute sécurité en place (telle que les pages protégées par mot de passe) empêchera toujours les applications Flash d’accéder aux données sensibles..

(Notez que vous ne pouvez pas placer sur votre domaine un fichier crossdomain.xml qui permette aux fichiers SWF de votre domaine d’accéder également aux fichiers distants. un autre domaine!)

Étape 2: Domaines spécifiés

Si vous ne souhaitez pas autoriser un accès global à vos ressources publiques, l’attribut de domaine de la tag peut être utilisé pour accorder l'accès à des domaines spécifiques.

Vous pouvez spécifier un domaine dans son intégralité. L'exemple ci-dessous donnera accès aux applications Flash hébergées dans le domaine www.example.com.

Vous pouvez utiliser le caractère générique astérisque pour faire correspondre les domaines qui se terminent par le suffixe donné. Ici, nous accordons l'accès aux applications Flash sur les domaines example.com, www.example.com, any.example.com, etc..

Étape 3: Adresses IP spécifiées

Vous pouvez spécifier l'accès par adresse IP, tout comme vous pouvez accorder l'accès aux applications Flash hébergées sur des domaines spécifiés. Les mêmes balises et attributs sont utilisés, sauf que dans ce cas, vous utilisez une adresse IP:

Étape 4: Travailler avec HTTPS

Par défaut, une application Flash hébergée sur un serveur HTTPS ne peut accéder aux ressources que sur des serveurs HTTPS distants. Mais compte tenu de la surcharge que HTTPS peut ajouter à un serveur, vous ne voudrez peut-être pas l'utiliser. Dans ce cas, le réglage garantir attribuer à faux permettra à une application Flash sur un serveur HTTPS d'accéder aux données d'un serveur HTTP.

Étape 5: Applications Flash distantes

Et si vous ne voulez pas que des applications Flash distantes accèdent à vos données? Vous pouvez créer un fichier crossdomain.xml qui n’inclut aucun fichier. Mots clés:

Ou vous pouvez simplement ne pas avoir de fichier crossdomain.xml.

Étape 6: Contrôle granulaire des sous-répertoires

Un fichier de stratégie interdomaine contrôlera l'accès au répertoire dans lequel il réside et à tous les sous-répertoires situés en dessous. Voici comment placer un fichier de stratégie "Tout autoriser" à la racine de votre domaine permet d'accéder à l'intégralité de votre domaine. Mais il peut arriver que vous souhaitiez uniquement autoriser l'accès à un certain sous-répertoire.

Avec les dernières versions de Flash Player, cela nécessite deux fichiers XML. Tout d'abord, vous devez placer un fichier crossdomain.xml à la racine de votre domaine, ce qui permet à Flash de traiter des fichiers de stratégie inter-domaines supplémentaires dans les sous-répertoires. Ceci est fait avec le étiquette. Dans l'exemple ci-dessous, nous définissons la politiques de domaine interdites autorisées attribuer à tout, ce qui signifie que les fichiers de règles interdomaines pouvant exister dans les sous-répertoires seront traités. Ce comportement est une modification de Flash Player 9 Update 3 et versions ultérieures. Auparavant, les fichiers de règles des sous-répertoires étaient traités par défaut sans avoir à définir le politiques de domaine interdites autorisées attribut.

Notez que nous n'avons ajouté aucun balises, ce qui signifie qu'en l'absence de fichiers crossdomain.xml supplémentaires dans les sous-répertoires, les applications Flash distantes n'auront pas accès aux ressources de ce serveur..

Vous pouvez en savoir plus sur les options de méta-politique dans cet article.

Ensuite, vous placez un fichier crossdomain.xml dans le sous-répertoire que vous souhaitez contrôler..

Pour voir un exemple de cela en action, consultez ce fichier. Ce fichier de règles, situé à la racine du domaine http://mytestgae.appspot.com/, utilise le balise pour déléguer le contrôle à tous les fichiers crossdomain.xml pouvant exister dans les sous-répertoires. Ensuite, ce fichier de règles situé dans le sous-répertoire / images / accorde un accès complet au répertoire et à tous les sous-répertoires situés en dessous. Ainsi, une application Flash distante pourrait accéder à l'image du visage souriant dans le répertoire images de la manière suivante:

Cependant, l’accès à l’image smiley dans le répertoire / images-restricted / n’est pas autorisé car il n’existe pas de fichier crossdomain.xml dans le répertoire images-restricted pour remplacer l’accès (inexistant) accordé par le fichier crossdomain.xml dans le répertoire. racine du domaine. L'exécution du code ci-dessous entraînera la génération d'une exception:

L'exception se lit comme suit:
SecurityError: Erreur # 2123: Violation du sandbox de sécurité: LoaderInfo.content: fichier: /// D | /CrossDomain.swf ne peut pas accéder à http://mytestgae.appspot.com/images-restricted/smiley.jpg. Aucun fichier de politique n'a obtenu l'accès.
à flash.display :: LoaderInfo / get content ()
à MethodInfo-635 ()

Étape 7: Stratégie inter-domaines et pare-feu

Les informations ci-dessus semblent donc indiquer que les fichiers de stratégie interdomaines peuvent être utilisés pour limiter efficacement l'accès aux applications Flash non hébergées sur votre propre domaine. Bien que cela soit vrai, vous ne devez pas vous fier à un fichier de stratégie inter-domaines pour limiter l'accès aux informations sensibles. Bien que Flash puisse respecter un fichier de règles crossdomain.xml, d’autres plates-formes telles que PHP ne le feront pas. Faites une recherche sur le proxy PHP pour voir ce que je veux dire. En utilisant un proxy, il est possible d'avoir accès à toutes les données accessibles au public, indépendamment de l'existence de fichiers de règles interdomaines. Et vous n'avez même pas à payer pour un serveur PHP - comme je le montrerai dans un prochain article, Google App Engine peut être utilisé comme proxy sans frais supplémentaires..

L'essentiel est que les fichiers de stratégie inter-domaines fournissent un moyen d'accorder de manière sélective l'accès aux ressources locales par des applications Flash distantes, mais uniquement si tout le monde respecte les règles. Si vous voulez vous assurer que vos données privées restent privées, rien ne remplace un pare-feu..

Conclusion

Traiter des fichiers de politique inter-domaines n'a pas besoin d'être compliqué. Une fois que vous avez compris les bases de leur fonctionnement, il est assez facile d’accorder ou de restreindre l’accès à vos données par des applications Flash distantes. Sachez simplement qu'ils ne sont pas aussi sûrs qu'ils le paraissent.

J'espère que vous avez aimé ce petit conseil, merci d'avoir lu!

Code