cfObjective(): Understanding Security In Adobe Air Apps with Jason Dean

Jason Dean did a very good job on this presentation. It was VERY informational on AIR security.

  • Is Air secure?
    • Air is not a web application
    • Security is the Developer's Responsibility
  • AIR is client-side
    • 100% client-side
    • Just like a web browser
    • Traffic to server can be intercepted
    • Even if over SSL
  • Installation and Security
    • Install screen cannot be modified
    • Except for the certificate
    • Code-signing Certificate
      • Applied through a company like Versign
      • Proves that the developer is you
  • Updating
    • Ye, updating is a security concern
    • Do NOT count on your users
    • YOU need to push new security fixes / features
    • Update notifications are required
    • If you do nothing else in your first version, make sure your app is self updating.
  • File System
    • Has same permissions as the user logged in
      • Any permission to the files the user has the AIR app has as well
    • Developers should not use the file system that could harm the system.
  • File System Best Practices
    • Apply to reading and writing
    • Do not allow Dynamic paths to be set
    • Try to use user and app specific file storage
    • The Static flash.fileSystem.File class has properties for system locations
    • Sensitive data should be encrypted before placing on the file system
  • Open Files in Default Application
    • AIR 2.0 offers the ability
    • It does limits the type
      • Does not allow execute zip, terminal, app, automater, exe, url, cdm, bat, csh, com, lnk, pif, jar, and more
  • Encrypted Local Store
    • Alternative to storing data on the file system or in the db
    • Uses the OS sore
      • Keychain for OSX
      • DPAPI for Windows
      • Either KeyRIng or Kwallet for Linux
    • Stores Binary data
    • Persistent Storage but can be lost.
    • Great for small bits of data (severe performances issues at 10mb)
    • Per-user, per-application store
    • Uses 128-bit AES/CBC Encryption
  • ELS StronglyBound
    • Normally, ELS certification is bound only to publisher ID
    • The stronglyBound property allows you to more strongly bind the ELS
    • Binds to the bits of app as well
    • If the app changes, then the ELS data will be inaccessible and need to be re-created
    • This includes when the app is updated
    • Really does not offer additional security
    • Better off not using it
  • Certificate Replacement
    • Vulnerability in the ELS
    • Installed app get replaced by a copy with a different publisher certificate
    • All Data prior to replace is safe
    • All data after replacement is threatened
    • Difficult to perform this attack
  • Native Processes
    • AIR app must be packaged as a native installer
      • DMG,EXE,RPM,DEB
    • Extended Desktop profile
    • Uses the same type of code-signing certificate
    • ANY executable can be run
    • BAT files are still prohibited on Windows
    • Is any part of the dynamic statement from a third-party?
  • AIR has sandboxes
    • Used to separate content
    • Used to separate permissions that your application
  • Application Sandbox
    • Directory where the application is installed
    • Allowed full access to the AIR API
    • All subfolders and files too
    • Restricted from loading JS files from remote locations
    • Only files in the sandbox can use the local file system
    • Restricted from using code that converts string into executable code
    • Except while the page is loading.
  • Non-Application Sandboxes
    • Flash Player Security Model/Browser Model
      • Remote
      • Local-trusted
      • Local-with-network
      • Local with filesystem
    • Have NO access to the AIR API
    • Can run code that turns string into executable code
    • Some other minor restrictions to JS apply
  • Code restrictions
    • Application Sandbox
      • Eval
      • innerHTML
      • Src Attrib
      • Javascript:
      • setTimeout
      • setInterval
      • Document.write
      • XMLHTTPRequest (onload)
    • Non-Application Sandbox
      • AIR API
      • XMLHTTPRquest???
      • Window.Open()
  • Avoiding Restriction Errors
    • Map app content to a different sandbox
    • Rewrite code to not use EVAL
    • Rewrite code for setTImeout and setInterval
      • Pass in a unanymous function into settimeout
    • Rewrite JS URL syntax
  • Sandbox Bridge
    • A path for one sandbox to access properties and methods from another
    • Involves a parent and a child
    • Works both ways
    • Uses properties childSandboxBridge and parentSandBoxBridge
  • Cross-Domain Requests
    • Request to a domain other than the originator
    • AIR Apps can run on the desktop, so any request to remote resources are corss-domain
    • Flash and Flex require cross-domain.xml
    • HTML/JS apps do not.
    • Of course just like in the browser, traffic is viewable.
    • SSL will only protect from eaves droppers.
  • Inter-Application Communication
    • Two applications on the local machine to talk with each other
    • With AIR appps can be done through localConnection class
    • Allows communication between an AIR app and a SWF in browser
    • Communications between two LocalConnections(same domain) is Secure
    • Traffic between domains can be allowed using
      • AllowDoman()
      • AllowInsecureDomain() (allows non-SSL)
    • In AIR 2.0 communication between AIR app and native app can be done using Sokcets
  • Local Database
    • AIR and SQLite Security
      • By default not secure
      • Unless locked in a closet
      • Susceptible to SQL Injection
      • Unencrypted, over-writable, and accessible by other apps
      • Other apps can read contents or even all.
    • Encrypted Database
      • Prevent Snooping
        • AIR provides support for Encrypted SQLLite DBs
        • Easy to do
        • Strong Encryptions (AES-128)
        • Keeps other apps from being able to open the DB
        • Will NOT prevent them from deleting or copying the DB
      • Using an Encrypted Database
      • Encrypted DB Considerations
      • Don't hard-code the encryption key
      • Weak Password == Weak Key
      • Data in memory is unencrypted
      • Shared DBs mean shared DB key
      • Keys can be stored in the ELS
      • If the key is lost, so is the data
  • Coldfusion AIR Offline Support
    • Coldfusion 9 introduced
    • AIR Sync with CF9
  • User Input Validation
    • Validate everything
  • Code Transparacy
    • Everything can be seen
  • Best Practices
  • Sign your code
  • Validate, validate, validate
  • Understand sandboxes
  • Enable self-updating
  • Use the ELS and Encrypted DBs
  • Think wisely about sandbox bridges
  • XML signature validator
  • Use the EncyrptionKeyGenerator
  • Read the docs and try things out

TweetBacks
Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
BlogCFC was created by Raymond Camden. This blog is running version 5.9.6.004. Contact Blog Owner