ACTIONSCRIPT 3 Developer’s Guide en

ACTIONSCRIPT 3.0 DEVELOPER’S GUIDE
Security
Dynamically generated code, such as that which is made when calling the eval() function, would pose a security risk
if allowed within the application sandbox. For example, an application may inadvertently execute a string loaded from
a network domain, and that string may contain malicious code. For example, this could be code to delete or alter files
on the user’s computer. Or it could be code that reports back the contents of a local file to an untrusted network
domain.
Ways to generate dynamic code are the following:
Calling the eval() function.
Using innerHTML properties or DOM functions to insert script tags that load a script outside of the application
directory.
Using innerHTML properties or DOM functions to insert script tags that have inline code (rather than loading a
script via the src attribute).
Setting the src attribute for a script tags to load a JavaScript file that is outside of the application directory.
Using the javascript URL scheme (as in href="javascript:alert('Test')").
Using the setInterval() or setTimout()function where the first parameter (defining the function to run
asynchronously) is a string (to be evaluated) rather than a function name (as in setTimeout('x = 4', 1000)).
Calling document.write() or document.writeln().
Code in the application security sandbox can only use these methods while content is loading.
These restrictions do not prevent using eval() with JSON object literals. This lets your application content work with
the JSON JavaScript library. However, you are restricted from using overloaded JSON code (with event handlers).
For other Ajax frameworks and JavaScript code libraries, check to see if the code in the framework or library works
within these restrictions on dynamically generated code. If they do not, include any content that uses the framework
or library in a non-application security sandbox. For details, see “Restrictions for JavaScript inside AIR” on page 1035
and “Scripting between application and non-application content” on page 1079. Adobe maintains a list of Ajax
frameworks known to support the application security sandbox, at
http://www.adobe.com/products/air/develop/ajax/features/.
Unlike content in the application security sandbox, JavaScript content in a non-application security sandbox can call
the eval() function to execute dynamically generated code at any time.
Restrictions on access to AIR APIs (for non-application sandboxes)
Adobe AIR 1.0 and later
JavaScript code in a non-application sandbox does not have access to the window.runtime object, and as such this
code cannot execute AIR APIs. If content in a non-application security sandbox calls the following code, the
application throws a TypeError exception:
try {
window.runtime.flash.system.NativeApplication.nativeApplication.exit();
}
catch (e)
{
alert(e);
}
The exception type is TypeError (undefined value), because content in the non-application sandbox does not
recognize the window.runtime object, so it is seen as an undefined value.
Last updated 6/6/2012
1073