Guide de reference du langage ActionScript 2.0 - PowWeb

Section relative à la sécurité: Flash Player fournit allowInsecureDomain() pour une plus
grande souplesse, bien que Macromedia en déconseille l'utilisation. La transmission d'un
fichier avec le protocole HTTPS offre plusieurs protections pour vous et vos utilisateurs. Le
fait d'appeler allowInsecureDomain affaiblit l'une de ces protections. Le scénario suivant
illustre la façon dont la méthode allowInsecureDomain(), si elle n'est pas utilisée avec
prudence, risque de compromettre la sécurité.
Remarque : les informations suivantes constituent uniquement l'un des scénarios possibles et
sont conçues pour vous aider à comprendre allowInsecureDomain() par l'intermédiaire
d'un exemple réaliste de programmation croisée. Cet exemple ne couvre pas tous les
problèmes relatifs à l'architecture de sécurité et doit être utilisé uniquement comme référence
générale. Le Centre de développement de Macromedia contient des informations détaillées
sur Flash Player et la sécurité. Pour plus d'informations, consultez le site http://
www.macromedia.com/devnet/security/.
Imaginons que vous deviez créer un site d'e-commerce comprenant deux composants : un
catalogue, qui ne doit pas nécessairement être sécurisé, dans la mesure où il contient
uniquement des informations publiques, et l'autre composant, un caddie/une caisse, qui doit
être sécurisé pour protéger les informations financières et personnelles des utilisateurs.
Supposons que vous placiez le catalogue dans http://mysite.com/catalog.swf et le caddie dans
https://mysite.com/cart.swf. L'un des éléments du cahier des charges stipule qu'aucun tiers ne
doit pouvoir voler les numéros de carte bancaire des utilisateurs en exploitant une faiblesse de
l'architecture de sécurité.
Imaginons qu'un intermédiaire malveillant tente d'intervenir entre le serveur et vos
utilisateurs pour s'emparer des numéros de carte de crédit que vos utilisateurs pénètrent dans
votre application de caddie. L'intermédiaire, peut être un FAI peu scrupuleux, par exemple,
ou un administrateur malveillant travaillant dans la même entreprise que certains utilisateurs,
ou de façon plus générale, toute personne ayant la possibilité d'afficher ou modifier les
paquets réseau transmis sans protection sur Internet, entre vos utilisateurs et vos serveurs.
Cette situation n'est pas rare.
Si cart.swf utilise HTTPS pour transmettre les informations bancaires aux serveurs,
l'intermédiaire ne peut pas voler directement ces informations en détournant les paquets
réseau, dans la mesure où la transmission HTTPS est chiffrée. Cependant, l'attaquant peut
utiliser une autre technique : modifier le contenu de l'un de vos fichiers SWF pendant sa
remise à l'utilisateur, en remplaçant le fichier SWF par une version modifiée qui détourne les
informations relatives à l'utilisateur vers un autre serveur.
security (System.security) 1099