|
Although AIR applications are built using web technologies,
it is important for developers to note that they are not working
within the browser security model. This means that it is possible
to build AIR applications that can do harm to the local system,
either intentionally or unintentionally. AIR attempts to minimize this
risk, but there are still ways where vulnerabilities can be introduced.
This section covers important potential insecurities. The developer
documentation provides best practices for building applications
that avoid these risks.
Risk from importing files into the application security sandbox
Content the application sandbox have the full privileges
of the runtime. Developers are advised to consider the following:
-
Include a file in an AIR file (in the installed application)
only if it is necessary.
-
Include a scripting file in an AIR file (in the installed
application) only if its behavior is fully understood and trusted.
-
Do not use data from a network source as parameters to methods
of the AIR API that may lead to code execution.
Adobe AIR
protects content in the application sandbox from using data from a
network source as code, which could lead to inadvertent execution
of malicious code. This includes use of the ActionScript
Loader.loadBytes()
method
and the JavaScript
eval()
function
Risk from using an external source to determine paths
An AIR application can be compromised when using external
data or content. For this reason, applications must take special
care when using data from the network or file system. The onus of
trust is ultimately upon to the developer and the network connections
they make, but loading foreign data is inherently risky, and should
not be used for input into sensitive operations. Developers are advised
against the following:
Risk from using, storing, or transmitting unsecured credentials
Storing user credentials on the user's local file system
inherently introduces the risk that these credentials may be compromised.
Developers are advised to consider the following:
-
If credentials must be stored locally, encrypt the credentials
when writing to the local file system. Adobe AIR provides an encrypted
storage unique to each installed application, which is described
in detail in the developer documentation.
-
Do not transmit unencrypted user credentials to a network
source unless that source is trusted and the transmission protocol
uses Transport Layer Security (TLS), in other words https: or the
SecureSocket class.
-
Never specify a default password in credential creation —
let users create their own. Users who leave the default expose their
credentials to an attacker that already knows the default password.
Risk from receiving or transmitting remote data
When information travels over the Internet, it is subject
to eavesdropping and alteration. You can use the Transport Layer
Security (TLS) or the older Secure Socket Layer (SSL) protocols
to encrypt communication between a server and a client system. Use
the HTTPS protocol to protect Hypertext Protocol (HTTP) communication.
Use the SecureSocket class to protect TCP socket communications.
In both cases, the server providing the data must use TLS or SSL
in order for your AIR application to send or receive the data securely.
The SecureSocket class was added in AIR 2 and can be used by content
running in the AIR application sandbox. Developers are advised to
consider the following:
-
Provide access to sensitive data hosted by a server using
the most recent version of the TLS protocol supported. (At this
time, AIR supports TLS version 1 and SSL version 4.)
-
Use HTTPS to transmit or receive sensitive data using the
HTTP protocol.
-
Use the SecureSocket class to transmit or receive sensitive
data using a TCP socket.
Risk from a downgrade attack
During the application installation process, 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 of the existing application against the version
that is being installed. If this string is different, the user can choose
to upgrade their installation. The runtime cannot 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. This risk can be
mitigated, and the developer documentation provides best practices
for implementing version schemes and update checks to avoid risks.
|
|
|
