Flex – Résoudre les problèmes de sécurité

A partir de Flash 9, Adobe à mis en place une politique de sécurité assez restrictive dès lors qu'une application Flex doit communiquer avec un service situé sur un autre domaine.

Pour paramétrer cette sécurité, il faut d'abord la comprendre.

Voici un article qui présente cette politique et comment la configurer ou la contourner.
^_^

Lorsque qu'on lance une application Flash, le runtime de Flash va déterminer une politique de sécurité (sandbox type) à lui appliquer à partir de l'environnement d'exécution du fichier et des contrôles de sécurité.


Les Sandbox de sécurité

Il existe 5 types de 'sandbox' :

  • REMOTE : le fichier SWF provient d'une URL Internet et par défaut n'accepte qu'aux ressources situé sur le même domaine.
  • LOCAL_WITH_FILE: le fichier SWF est un fichier local et ne peut accéder qu'aux ressources locales.
  • LOCAL_WITH_NETWORK: le fichier SWF est un fichier local, il peut accéder à Internet mais ne peux pas accéder aux ressources locales.
  • LOCAL_TRUSTED: le fichier SWF est un fichier local et peut accéder aussi bien à internet qu'aux ressources locales.
  • APPLICATION: quand il s'agit d'une application AIR (WindowedApplication au lieu de Application) avec les mêmes droits que le LOCAL_TRUSTED.


Les contrôles de sécurité

En plus de ces sandbox de sécurité, le Flash player tient compte des contrôles de sécurité.
Dans l'ordre, on appliques les paramètres de sécurité de l'administrateur de la machine, de l'utilisateur, du site web et enfin du développeur.

Localisation des différents paramètres :

  • paramètres de l'utilisateur : se situe dans le Setting Panel du Setting Manager (qui sera abordé infra)
  • paramètres du site web : se situe dans un ou plusieurs 'policy files'
  • paramètres de l'auteur : se font par programmation, dans les fichiers sources

hierarchie des controles de securite flash

Résolution par la pratique

Il faut considérer 2 cas :
- phase de développement : c'est le cas où vous êtes en train de développer sur votre poste de travail et vous voulez accéder à un domaine sur internet.
- phase de production : ici vous avez fini votre développement et vous avez placé votre application web (contenant votre fichier SWF) sur un serveur web. C'est celui-ci qui va accéder à internet.

Pour illustrer la problématique de sécurité, nous allons étudier un cas de test.

Cas de test:
Une application doit présenter le code source d'une page web dans un TextArea.
Le domaine ne dispose pas de fichier crossdomain.xml et il n'est pas prévu qui y soit.

Pour ce cas de test, on va créer un TextArea et y ajouter le contenu d'une page Web, on prendra comme exemple l'url suivante à inclure: http://www.free.fr/adsl/index.html
J'ai choisi de 'coller' le contenu de la page www.free.fr car il n'y a pas de fichier crossdomain.xml pour ce domaine (contrairement à www.google.fr).
A l'heure de cette article, il n'existe pas de fichier à l'url suivante : http://www.free.fr/crossdomain.xml

Développement en local

Cette partie représente la phase de développement de l'application.

Nous aurons par exemple le code suivant :

<?xml version="1.0" encoding="utf-8"?>

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
backgroundGradientColors="[0xFFFFFF, 0xAAAAAA]"
horizontalAlign="left"
verticalGap="15"
horizontalGap="15"
creationComplete="showSecurity();">

<mx:Script>

<![CDATA[
import mx.controls.Alert;
import mx.rpc.events.ResultEvent;
private function resultHandler(event:ResultEvent):void {
//Alert.show(event.result.toString());
var test:String = event.result as String;
resultatArea.text = test;
}
private function showSecurity():void {
//Security.showSettings(SecurityPanel.SETTINGS_MANAGER);
Alert.show(Security.sandboxType,'Sandbox de securite');
}
]]>
</mx:Script>
<mx:HTTPService id="freeService" url="http://www.free.fr" result="resultHandler(event)" resultFormat="text"/>

<mx:Panel title="Test" width="100%">

<mx:TextArea id="resultatArea" width="100%" minHeight="400">
<mx:text>Aucune reponse</mx:text>
</mx:TextArea>
<mx:Button label="ping Free" click="freeService.send();"/>

</mx:Panel>

</mx:Application>

Si vous travaillez en local avec FlexBuilder, vous aurez le message : localTrusted correspondant à la valeur du sandbox de securité de type LOCAL_TRUSTED.
Si vous travaillez en local, vous aurez surement le message suivant : localWithNetwork correspondant à la valeur du sandbox de securité de type LOCAL_WITH_NETWORK.

Pour information:
Pour avoir le sandbox de securité de type LOCAL_WITH_FILE, il faut ajouter au compiler l'argument -use-network=false qui par défaut est à true.

Avec la sandbox LOCAL_TRUSTED, nous n'aurez aucun problème mais si vous avez une sandbox de type LOCAL_WITH_NETWORK, vous ne pourrez pas accéder à certaines ressources distantes.

A partir d'ici, vous avez 2 options :

  • Soit configurer le Setting Manager pour autoriser le répertoire d'exécution de votre fichier SWF.
  • Soit demander discrètement à Free d'ajouter un fichier crossdomain.xml à la racine de leur serveur web, cependant d'après notre cas de test, nous dirons que c'est impossible.

Nous allons donc voir comment configurer le Setting Manager.

Configuration du SETTING MANAGER

Pour ouvrir le Setting Manager, vous avez besoin d'une connexion internet.

Ensuite il faut ajouter le code suivant:

Security.showSettings(SecurityPanel.SETTINGS_MANAGER);

et l'appeler depuis une fonction, un bouton ou autre :

A l'exécution du code ci-dessus, vous devez avoir l'écran suivant :
panneau_securite_big

Cochez la case "Toujours autoriser" et ajouter le répertoire dans lequel vous lancez votre SWF locaux, vous pouvez mettre un dossier parent, par exemple le dossier de votre workspace Flex.

config1_big

config 2_big

Donc maintenant, vous êtes libre d'appeler n'importe qu'elle ressource distante même si elle n'a pas de fichier crossdomain.xml.

Déploiement de l'application

Ici, on est dans la phase de production, vous avez terminez votre développement et maintenant vous devez installer
votre application sur un serveur web (ou d'application).

Notez bien que dans le cas où vous faites des appels serveur en restant sur le même domaine, vous n'aurez pas de problème d'accès.
Par contre, vous aurez des problème d'accès si votre application web (contenant votre fichier SWF) nécessite une ressource situé sur un autre domaine et comme par hasard c'est notre cas ^_^.
Dans les deux cas, vous aurez la sandbox de sécurité de type REMOTE.

Reprenons donc notre cas de test pour garder la problèmatique d'accès.

Pour gérer les accès distants dans ce type de sandbox, Flash se repose sur un ou plusieurs fichier "crossdomain.xml" qu'on appelera les policy files.
Il faut savoir qu'il y a une notion de 'master policy file'. Il s'agit d'un fichier  crossdomain.xml qui est chargé à la racine du domaine distant. Son nom et son emplacement sont fixes.

Le master policy file

Il ne peut y avoir qu'un seul master policy file, tous les autres policy files sont dépendants du fichier maître.
Vous pouvez charger d'autres policy files d'un autre emplacement que celui par défaut mais sans master policy file, le Flash Player n'en tiendra pas compte.
Vous n'êtes pas obligé de les nommer 'crossdomain.xml'.

Cinématique générale d'une demande d'accès :
Fichier SWF --> demande ressource sur autre domaine --> master policy file --> (autre policy file) --> appel ressource accordé ou refusé

Exemple de crossdomain.xml:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">

<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
<allow-access-from domain="*" to-ports="*" secure="false"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>

La balise site-control n'est présente que sur le master policy file, dans les autres cas, elle n'est pas prise en compte.
C'est cette balise qui va autoriser ou non le chargement d'autres policy files.

Tout ceci pour vous dire que, dans notre cas de test, nous sommes un peu dans une impasse.
Je vais donc vous montrer un moyen de contourner cette obstacle.
^_^

Contournement du fichier de configuration

Bien que le Flash Player vous interdise de communiquer avec l'extérieur, il ne vous interdit jamais de vous parler à vous même, c'est à dire sur votre domaine.
La solution consiste à déléguer l'appel de la ressource distante par un service de votre application web et de retourner le résultat de cette appel à votre fichier SWF.

J'ai choisi d'utiliser une page JSP (dans la même application web) qui va jouer le rôle de 'proxy' pour notre fichier SWF
mais vous pouvez très bien utiliser autre chose, comme par exemple une servlet, une page PHP, ASP, etc.

Exemple d'une JSP intermédiaire : proxy.jsp

<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@page import="java.io.BufferedInputStream"%>
<%@page import="java.io.IOException"%>
<%@page import="java.io.PrintWriter"%>
<%@page import="java.net.URL"%>
<%

String urlToOpen = request.getParameter("url");
if(urlToOpen != null){
String forward = urlToOpen;
PrintWriter writer = response.getWriter();
try {
URL url = new URL(forward);
BufferedInputStream in = new BufferedInputStream(url.openStream());
int c = (int)' ';
do {
c = in.read();
writer.write(c);
}while(c != -1) ;
writer.flush();
writer.close();
in.close();
} catch (IOException e) {
// rien pour la demo
}
}

%>

Dans la partie du fichier MXML

Remplacer :

<mx:HTTPService id="freeService" url="http://www.free.fr" result="resultHandler(event)" resultFormat="text"/>

Par :

<mx:HTTPService id="freeService" url="proxy.jsp" method="POST" result="resultHandler(event)" resultFormat="text" >
<mx:request>
<url>http://www.free.fr</url>
</mx:request>
</mx:HTTPService>

Cette méthode vous permet de contourner la contrainte du fichier crossdomain.xml et d'appeler n'importe quelle ressource distante.
Vous êtes à présent libre comme l'AIR...
^_^

J'espère que cette article vous sera utile pour la résolution de vos problèmes de sécurité.
😉

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.