Selecting more secure compiler settings

In this section I discuss the optimal settings to use in the Publish Options in Flash CS3 Professional to help security in your Flash applications.

To see more information regarding this topic, see Specify publish settings for SWF files in the Using Flash CS4 Professional documentation.

The first consideration a developer makes is what Flash Player version the SWF application should be compatible with. All modern versions of Flash Player include an auto-update feature to notify users when a new version of the player is available and this has been highly successful in getting the majority of Flash Player users migrated to new versions quickly. The Flash Player home page tracks market penetration of the players and shows how quickly new versions are adopted (see Adobe Flash Player version penetration). Flash Player 9 compatibility achieved 90% cross-platform market penetration within approximately one year while Flash Player 8 compatibility has over 98% cross-platform penetration in major markets. For some applications, reaching 98% of customers is sufficient. However, for global organizations, the inability to reach 1.5% of the hundreds of millions of systems on the Internet still results in not reaching a few million systems. Some of the systems with older versions of Flash Player include older operating systems or systems that are part of a locked environment where they do not receive updates unless absolutely necessary due to system stability.

Newer versions of Flash Player frequently contain important security updates and features which can help to ensure that SWF files are not misused on the hosted website. Due to backwards compatibility requirements, in some instances Flash Player determines whether to enforce the additional security changes based on the version of Flash Player that the SWF was compiled for and not the version of Flash Player that is executing the SWF. For example, if the end-user has the latest version of Flash Player installed (version 9) but the end-user is playing a SWF file that a developer compiled for Flash Player version 7, then, in some instances, the end-user's Flash Player will mimic the behavior of Flash Player 7—which has a less mature security model for both the site developer and the end-user. One example would be that the default for "allowScriptAccess" is "always" in SWF files compiled for compatibility for Flash Player 7 and "sameDomain" for SWF files compiled for Flash Player 8. Consequently, you should compile for compatibility with Flash Player 8 or later to ensure that the SWF uses the more secure setting.

Additionally, you access better security tools when leveraging ActionScript 3.0. Developers using ActionScript 3.0 can take advantage of regular expressions which can make the process of performing data validation easier. Input controls within the language are more centralized. In addition, the AVM2 virtual machine used to process ActionScript 3.0 is faster, more robust and more stable then the AVM1 environment that supports the legacy ActionScript 2.0 and ActionScript 1.0 code. Developers who want to migrate from ActionScript 2.0 to ActionScript 3.0 should read Migrating from ActionScript 2.0 to ActionScript 3.0: Key concepts and changes, as well as check out the migration resources in the ActionScript Technology Center.

If you want to ensure your end-users are using a current version of Flash Player, then you can use the Flash Player Detection Kit provided by Adobe. It contains both client-side JavaScript and ActionScript code for detecting the Flash Player version and determining if the version is appropriate for your content.

Using the protect from import and permit debugging options

Related threats: Unauthorized local data access

The Protect From Import and Permit Debugging flags use an MD5 hash to password-protect SWF files from import into a Flash authoring tool. This protection is a basic protection for authoring tools that choose to honor it. A determined attacker could still decompile the SWF file to get the source code or strip the debugging flag from the binary. The MD5 hash used by these flags is subject to brute force dictionary-based attacks. Therefore, SWF files should not be considered to be a black box application even with the Protect From Import flag set. Any sensitive data or secrets stored within a SWF can easily be found. Developers should not store static passwords, encryption keys or other sensitive data within the source code of a SWF file.

Compiling clean code

Related threats: Unauthorized local data access

When creating applications, it is a best practice to remove all debug code from the final production releases. This is also a best practice for developing SWF applications. The Omit Trace Actions flag in Flash development environments tells the compiler to remove any trace commands when creating the compiled SWF file. This will make the published SWF smaller and it will remove any excess information or actions from the SWF.

Setting the minimum stage size

Related threats: Spoofing, clickjacking

The stage size should be set to a minimum of 215 pixels wide and at least 138 pixels high so that Flash Player messages from shared objects, microphone, camera and other components can be displayed fully to the user. To protect against clickjacking attacks, Flash Player requires the area of the stage displaying the dialog box to be visible with the default window mode set.

Page 3 of 13

Previous Page

Next Page