1062 ActionScript classes
Security considerations
: Flash Player provides
allowInsecureDomain()
to maximize
flexibility, but Macromedia recommends against calling this method. Serving a file over
HTTPS provides several protections for you and your users, and calling
allowInsecureDomain
weakens one of those protections. The following scenario illustrates
how
allowInsecureDomain()
can compromise security, if it is not used with careful
consideration.
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.
NO
TE
The following information is only one possible scenario, designed to help you understand
allowInsecureDomain()
through a real-world example of cross-scripting. It does not
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/..
Summary of Contents for FLASH 8-ACTIONSCRIPT 2.0 LANGUAGE
Page 1: ...ActionScript 2 0 Language Reference ...
Page 1352: ...1352 ActionScript classes ...