To mitigate these risks, AIR now provides a comprehensive
security architecture that defines permissions for each internal
and external file in an AIR application. Permissions are granted
to files according to their origin and are assigned to logical security
groupings called
sandboxes
. The runtime uses these sandboxes
to define access to data and executable operations:
-
Code in the application sandbox has access to AIR APIs,
has a limited ability to generate code dynamically after a page
loads, and cannot load content via a
script
tag.
-
Code in all other sandboxes (referred to as non-application
sandboxes) essentially mimics typical browser restrictions and behaviors
for local trusted HTML.
The application sandbox
The primary function of the application sandbox is to enable
interaction between AIR APIs and files in trusted directories. Isolation
from code in non-application sandboxes is maintained by disabling
the JavaScript parser after initial page load so that code such
as
eval()
throws an exception. Setting
innerHTML
is
permitted, but any script it contains is ignored. This provides broad
functionality without exposing AIR APIs directly to externally loaded
data.
Developers reference trusted directories within the application
sandbox using the
app:/
URL scheme. Even some files
in the application directory can be placed in a non-application
sandbox if they are loaded into a
frame
or
iframe
using
the AIR
sandboxRoot
and
documentRoot
attributes
if the
frame
or
iframe
. All files
included within an AIR installer are automatically installed in app:/
and therefore are part of the application sandbox. When the application runs,
these files are given the full set of AIR application privileges,
including interaction with the local file system. Content outside
app:/
is
not part of the application sandbox and is therefore treated the
same way as it is in the browser.
AIR APIs provide a secure means to safely bridge an evolved browser
security model with a desktop-like security model. The AIR sandbox
bridge model enables broader functionality and less risk than is
associated with typical browser-based applications.
The non-application sandboxes
The primary function of the non-application sandboxes is
to limit access to local files and AIR APIs unless permitted by
the developer. Content loaded from a network or Internet location
is automatically assigned to this sandbox. The non-application sandboxes
can use the
eval()
function, execute code via
innerHTML
assignments,
and so on. Code in non-application sandboxes is bound by a same-origin
policy and, by default, cannot do cross-domain data loading via
XMLHTTPRequest
.
However, code in a non-application sandbox cannot directly execute
AIR APIs.
Developers are encouraged to write code that runs in the application
sandbox, even if some restrictions for this sandbox make it behave
a little differently than the browser model.
The sandbox bridge
At their simplest, HTML-based AIR applications that use
network content consist of a root user interface (UI) file, the
data and files they download, and some application files (in the
application sandbox). However, if the external content and some
user interface files operate in non-application sandboxes and the
application files operate in an application sandbox, how does the
non-application sandbox content and application sandbox content
interact with each other?
The AIR solution is the
sandbox bridge
API, which enables
indirect communication between different sandboxes. Developers can
craft functions that call AIR APIs and then expose those “mediating”
functions on the sandbox bridge. These bridge functions essentially
“sit on the bridge” and wait for code in the non-application sandbox
to call them.
This architecture accomplishes two goals. First, non-application
sandbox content does not have direct access to the AIR APIs and
application content is protected from external data which is unknown
and potentially malicious. Second, only those APIs that the developer
explicitly chooses to expose via the bridge mechanism are exposed.
While the sandbox bridge does not guarantee security, developers
hold the keys for reducing risk in how they expose the AIR APIs
to untrusted content. Much like a client-server model, the server
should never trust the client, and the client should never trust
data loaded from third parties. Likewise, developers should not
use or trust code loading on the server as that could compromise
the server, which in turn has access to the operating system. So
for the client-server model in both the browser and in the AIR sandbox
bridge, primitive system APIs, like
writeFile()
and
readFile()
,
should always be protected from attack.
Adobe AIR security is designed with the web application development community
in mind. Adobe supports standards and methodologies that help to mitigate
security risks. Organizations such as the OpenAjax Alliance are
further helping to publicize these best practices:
-
Isolate untrusted content in a frame or
iframe
,
as leveraging the same-origin policy makes it difficult for attackers
to access the full DOM tree.
-
Data loaded to a frame from a different domain should be
given a unique JavaScript execution context and DOM tree.
-
Do not generate and execute code dynamically.
-
Avoid inserting HTML content that is not from a trusted source.
-
Use JSON securely.
AIR
provides the mechanisms for developers to follow these best practices
and thereby enhance the security of their HTML-based applications.
For more information, see
Ajax and Mashup Security
at the OpenAjax
Alliance.
The developer must explicitly bridge sandboxes.
Summary of sandbox privileges
Capability
|
Application Sandbox
|
Other (non-application) sandboxes
|
Direct access to AIR APIs?
|
Yes
|
No
|
Access to application sandbox functions
that use AIR APIs via the bridge?
|
N/A
|
Yes
|
Can load remote script such as
<script src='http://www.example.com /some_code.js'>
?
|
No
|
Yes
|
Can, by default, execute cross-domain requests
(XHR)
|
Yes
|
No
|
Supports dynamically loading strings as
code after the
load
event:
eval()
function,
setTimeout('string', milis)
,
javascript:
URLs,
attribute handlers on elements such as
onclick='myClick()
')
that are inserted via
innnerHTML
, and so on.
|
No
|
Yes
|
Ajax frameworks will work without any changes?
|
Some frameworks
|
Yes
|
|
|
|