Sanboxes in AIR

Some interesting questions have been raised regarding sandboxing in AIR, and whether the AIR Application sandbox is “weaker” than the equivalent browser sandbox.

On the face of this, this seems like a reasonable assumption to make. Simply adding system access to a browser sandbox would indeed be much scarier, but that is not what happened. In fact, AIR Application sandbox is significantly different from a browser sandbox insofar that many high-risk APIs have been disabled or severely restricted, making it far more difficult to attack such applications. So the AIR sandbox is not weaker than a browser sandbox; it is different, and in many respects stronger.

Code injection (aka cross-site scripting or XSS), essentially happens because applications fail to validate all data to ensure that no code can be included. Injection happens when code gets turned into data through a variety of different APIs. It can also happen when the developer imports code (such as using the SCRIPT tag for JSON loading) but for some reason assumes that they are only loading data.What we have done in AIR is to identify those API’s and either prohibit or severely restrict their using at application runtime. For example, a partial list of things prohibited in an AIR HTML Application sandbox:* 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()method 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().For a more comprehensive treatment of the HTML sandboxes, please see the HTML security section in the Livedocs.Similar restrictions have been placed on Flash content, however the Flash model is generally more resistant to injection attacks (as there are very few APIs that can turn data into code) so fewer changes were required.Of course the Application sandbox is not the only sandbox present in AIR. In fact only content originally installed with the application should be placed in the Application sandbox. All other local and remote non-application content is placed into the same equivalent Flash or HTML sandbox that it would be in the browser. Click here for detailed information on sandboxes in AIR.

Comments are closed.