MAX 2007: On AIR Security
Rough Draft Notes
Lucas Adamski
AIR Threat Model
Installation
Runtime managed dialog, application signed by CA, self-signed = unsigned
Line between guaranteed harmless/automatic execution to full privilege/explicit install.
Only time user makes a decision is on the security dialog
AIR updates must be signed by the same publisher
Elevation Attacks
Remote content should not be able to discover anything about local system.
Should not be able to cross sandboxes.
Injection Attacks
JSON isn't a problem, JSON by eval() is the issue.
Smallest sandbox is a frame.
Injection Vectors: Code importing, DOM manipulation, URI schemes, Code generating functions.
Focused on protecting the user, not the developer.
Mitigations: Escaping or stripping (requires diligence). Clearly separate code and data (SQL prepared statements are a good example).
Typical Desktop Application Threats
Writable files
Credentials stored insecurely
Default passwords
Buffer and stack overflow
Upgrade/downgrade attacks (manually uninstall to downgrade)
Applications should not update without explicit user permission, no runtime importing to application content from remote servers.
AIR Security Model
Scripting languages have greater access than browser
Dynamically loading shouldn't have access
Provide loading mechanism that puts loaded data in its own sandbox
Explicit communication mechanisms
Safer cross domain data
AIR Does Not
Can't run untrustworthy applications
Prevents security mistakes
Has sandbox to guarantees security
AIR Does Provide
Full system access
Explicit installation
Signed applications
Guiding Principles
Local and remote data is like running in a browser
AIR shouldn't be natively more dangerous than other platforms
AIR shouldn't be a vehicle for attacking machines
AIR shouldn't require security guru
Develop paradigm during beta process
Flash in AIR
app-resource vs. app-storage
Application content: no asfunction, loader.loadbytes(),
Non-application content: no direct AIR API
No one: no write to app-resource, sandboxBridge
HTML Security Model
Application (desktop model) vs. Classic Sandbox (Browser like)
Application: direct air access, set innerHTML but script ignored, dynamic allowed only during load
Classic: dynamic always permitted, script for JSON are fine, no direct AIR API
Have to wait for parent Sandbox bridge before you can do anything
Cookies can be turned on/off.
SSL supported
Secure local store API, generic secure key storage (app ID and user Key)
Q: If I download a SWF into application-storage will that have fewer privileges than a SWF loaded from application-resource? Yes. Looking in the long term to provide plug-in API (not 1.0). Bridging will get you there. In general it's not prevented just discouraged.