Home > Flex/Air > Adobe AIR Security

Adobe AIR Security

Adobe AIR 1.5 has helped web developers build Rich Internet Applications (RIAs) for the desktop using their web development skills. Adobe AIR is cross platform. The applications developed in Adobe AIR have desktop and web access at the same time. For this reason the security features of Adobe AIR are different than the conventional web or desktop applications. The security measures of Adobe AIR are a combination of security rules of the desktop as well as web applications.

Some of the most significant features of Adobe AIR are:

Memory Management:
AIR applications are secure in terms of memory management. There are fewer chances of memory loss due to buffer overflow and memory corruption in the applications developed using Adobe AIR. The memory management is provided by the runtime environment because AIR applications are written using either the precompiled bytecode (SWF content) or interpreted scripts like JavaScript or HTML.

Code Signing
Adobe AIR requires developers to digitally sign their applications in order to maintain the integrity of the software and the identity of its publisher. The applications can be digitally signed by a Certification Authority (CA) or by constructing a self-signed certificate.

Users choose whether they prefer using the applications certified by the authority or the applications with self-signed certificates by ignoring the vulnerability risks in those applications. If someone is concerned about data and system security then the applications developed by renowned developers or signed by the authorities should be used.

The cross platform security architecture of Adobe AIR is very comprehensive. It allows desktop applications to access the internet while keeping the system secure from different vulnerabilities. The security architecture of Adobe AIR also restricts unauthorized access to the system files through the use of the AIR application. Different levels of security are defined within AIR in terms of Sandboxes. A sandbox acts independently to secure the local file system defined within that particular sandbox from the files residing in other sandboxes.  There are defined permissions in each sandbox for the access of each file in the AIR application. Because of this, files within different sandboxes are secure. Also, a malicious code from the web cannot access and destroy the local file system defined within a sandbox.

Different forms of sandboxes in the Adobe AIR architecture are:

Application Sandbox —   The files in the application sandbox have full AIR privileges and access to the system. The contents defined in the Application Sandbox have access to the AIR APIs, but the contents in the other sandboxes cannot access those APIs.

Non Application Sandbox – Files downloaded online or from other networks are included in the non application sandbox. This category of sandbox is further divided into subcategories according the set of rules and restrictions for different sorts of file systems. These are: remote, local trusted, local-with-networking and local-with-file system.

Data Encryption
For added security the AIR runtime provides the application and user the ability to store data in an encrypted format in a separate location.  The format used to store the data is AES-CBC128-bit encryption. With this, the application has the capability to save and retrieve a user’s data on the local hard disk in the encrypted format. That data gets saved from being decoded by other users and the other AIR applications. There is a separate storage area for each users’ encrypted data. Two applications cannot share the same encrypted local store. The local store can be used by applications to store each users’ confidential information separately. The Adobe AIR application uses DPAPI on Windows and KeyChain on Mac OS to associate the encrypted local stores to each user.

Sandbox Bridge
There are special restrictions and complex security arrangements for the access of scripts outside the “Application Sandbox” to the contents defined in that particular sandbox. A special mechanism called “Sandbox Bridge” is used by non-application-sandbox files to access the properties and methods of files in the application sandbox. The sandbox bridge does not guarantee security as it totally depends on how the Application Sandbox API’s are exposed to the non-application sandbox while implementing the sandbox bridge. It can be said that the sandbox bridge will expose only the permitted data to outside scripts or files.  In this case the scenario is more or less like the client-server model. However, when used correctly, the sandbox bridge can provide applications with an extra layer of security by restricting non-application content from accessing the contents of an application sandbox.

HTML Security
Added care must be taken when allowing dynamic HTML content to access the application layer of Adobe AIR. As the dynamic content may contain functions like eval (), that can create security risks by exposing data within the application sandbox. Such malicious dynamically generated codes can even delete the file system or alter them for continuous spying on the system without the intervention of the users.

The code in the application sandbox can only use some specified HTML methods like eval (), setting up of innerHTML properties, setting up of src and using a JavaScript URL scheme. These methods can only be used when the content is loading from the application directory. Execution of untrusted scripts is restricted by the code in the application sandbox, which has full access to the AIR APIs.
The HTML methods can also be used by the non-application sandboxes to generate dynamic code, but they do not have direct access to the application APIs. The sandbox bridge provides limited access to the application APIs by setting up means and restrictions.

From the above overview of the AIR security model, it can be assumed correctly that it is secure for developers and users. Still, common vulnerability risks are present, as they can be there in other applications developed by using any other platform. It is the responsibility of the users and the developers to maintain security by monitoring risks like importing files in the AIR application sandbox, being conscious while using external sources to determine paths and being very careful while storing and transmitting unsecured credentials.

Adobe AIR 1.5 Security Whitepapers, Retrieved Jan 22nd, 2008 from     http://help.adobe.com/en_US/AIR/1.5/AIR_security/WS5b3ccc516d4fbf351e63e3d11c0f598475-7ff3.html

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: