MACROMEDIA FLASH 8-ACTIONSCRIPT 2.0 LANGUAGE Reference page 1062

Security considerations: Flash Player provides
flexibility, but Macromedia recommends against calling this method. Serving a file over
HTTPS provides several protections for you and your users, and calling
allowInsecureDomain
how
allowInsecureDomain()
consideration.
The following information is only one possible scenario, designed to help you understand
allowInsecureDomain()
cover all issues with security architecture and should be used for background
information only. The Macromedia Developer Center contains extensive information on
Flash Player and security. For more information, see http://www.macromedia.com/
devnet/security/..
Imagine that you are building an e-commerce site that consists of two components: a catalog,
which does not need to be secure, because it contains only public information; and a
shopping cart/checkout component, which must be secure to protect users' financial and
personal information. Suppose that you are considering serving the catalog from http://
mysite.com/catalog.swf and the cart from https://mysite.com/cart.swf. One requirement for
your site is that a third party should not be able to steal your users' credit card numbers by
taking advantage of a weakness in your security architecture.
Suppose that a middle-party attacker intervenes between your server and your users,
attempting to steal the credit card numbers that your users enter into your shopping cart
application. A middle party might, for example, be an unscrupulous ISP used by some of your
users, or a malicious administrator at a user's workplace — anyone who has the ability to view
or alter network packets transmitted over the public Internet between your users and your
servers. This situation is not uncommon.
If cart.swf uses HTTPS to transmit credit card information to your servers, then the middle-
party attacker can't directly steal this information from network packets, because the HTTPS
transmission is encrypted. However, the attacker can use a different technique: altering the
contents of one of your SWF files as it is delivered to the user, replacing your SWF file with an
altered version that transmits the user's information to a different server, owned by the
attacker.
The HTTPS protocol, among other things, prevents this "modification" attack from
working, because, in addition to being encrypted, HTTPS transmissions are tamper-resistant.
If a middle-party attacker alters a packet, the receiving side detects the alteration and discards
the packet. So the attacker in this situation can't alter cart.swf, because it is delivered over
HTTPS.
1062 ActionScript classes
weakens one of those protections. The following scenario illustrates
can compromise security, if it is not used with careful
through a real-world example of cross-scripting. It does not
allowInsecureDomain()
to maximize