ACTIONSCRIPT 3 Developer’s Guide en

ACTIONSCRIPT 3.0 DEVELOPER’S GUIDE
Security
Risk from a downgrade attack
Adobe AIR 1.0 and later
During application install, the runtime checks to ensure that a version of the application is not currently installed. If
an application is already installed, the runtime compares the version string against the version that is being installed.
If this string is different, the user can choose to upgrade their installation. The runtime does not guarantee that the
newly installed version is newer than the older version, only that it is different. An attacker can distribute an older
version to the user to circumvent a security weakness. For this reason, the developer is advised to make version checks
when the application is run. It is a good idea to have applications check the network for required updates. That way,
even if an attacker gets the user to run an old version, that old version will recognize that it needs to be updated. Also,
using a clear versioning scheme for your application makes it more difficult to trick users into installing a downgraded
version.
Code signing
Adobe AIR 1.0 and later
All AIR installer files are required to be code signed. Code signing is a cryptographic process of confirming that the
specified origin of software is accurate. AIR applications can be signed using either by a certificate issued by an external
certificate authority (CA) or by a self-signed certificate you create yourself. A commercial certificate from a wellknown
CA is strongly recommended and provides assurance to your users that they are installing your application,
not a forgery. However, self-signed certificates can be created using adt from the SDK or using either Flash, Flash
Builder, or another application that uses adt for certificate generation. Self-signed certificates do not provide any
assurance that the application being installed is genuine and should only be used for testing an application prior to
public release.
Security on Android devices
Adobe AIR 2.5 and later
On Android, as on all computing devices, AIR conforms to the native security model. At the same time, AIR maintains
its own security rules, which are intended to make it easy for developers to write secure, Internet-connected
applications.
Since AIR applications on Android use the Android package format, installation falls under the Android security
model. The AIR application installer is not used.
The Android security model has three primary aspects:
Permissions
Application signatures
Application user IDs
Android permissions
Many features of Android are protected by the operating system permission mechanism. In order to use a protected
feature, the AIR application descriptor must declare that the application requires the necessary permission. When a
user attempts to install the app, the Android operating system displays all requested permissions to the user before the
installation proceeds.
Last updated 6/6/2012
1082