This content has been marked as final. Show 7 replies
I'm also suprised at how easy it is to see the source of a Air app, esp ones written in html/js.
It seems that anyone could extract my files and recompile their own version of my Air app very easily.
How can I keep my app secure?
AIR is unlikely to include any additional features to obfuscate the source code. If you're interested in this, you should explore libraries or other third-party solutions that might offer such features.
You should realize that no such feature is sufficient to prevent your server from being called form other applications, AIR or otherwise. Your server should use other means to protect itself.
Oliver Goldman | Adobe AIR Engineering
Your server should use other means to protect itself.
In what way would you suggest?
Such as? I'd be very interested of knowing those alternatives
As a php programmer, I would at least require a username and password, then I would set a $_SESSION variable if they were a valid user. I could normally maintain this variable across php pages, but with AIR you would not stay in a server side php page.
My first thought would be to use AIR to browse to a php page to logon, then
if successful, respond with a random key perhaps via XML that AIR would maintain and allow database updates.
Another thought might be to require entry of a username and password into an AIR html form, that is then POSTed via AJAX to a server side script for user validation, with an XML response (random key?) so that re-entry of username and password is not required for every subsequent change and / or AIR to maintain the username and password in a js variable??
What are the pros and cons of the above?
Your server should use other means to protect itself.
One thing springs to mind: an API...
When you're creating an AIR app that connects to a remote server, it would be a huge mistake to have the app connect directly to the server functions without a secure interface. My advice is that you should plan your app and api together.
See for instance how Twitter or Basecamp uses an API to stand between third party applications and the main applications. The main point is that these web apps use carefully crafted APIs to limit external apps from accessing sensitive data.
As for the example of the authentication code. Yes, there is the possibility of anyone getting the code from the application and using it on another air application or webpage to run the operation. But if this login code can jeopardize your authentication, then it would be best to rethink your authentication methods.
Just because someone can create a form and put a little submission logic, it doesn't mean that the validation and authentication functions of the server will become unsafe. That would be like saying that because I can see GMail's login source code that I could also see the login information of every Google user. Or to put it poignantly, even if a bad guy tried to send a username and a password using the same code on your air file, it doesn't guarantee that they will actually be given access--unless of course you were actually shortsighted enough to place sensitive information on your code (such as actually placing usernames, passwords and encryption keys).
Now, about code extraction and recompiling the air application. This is where the Code Signing feature of Adobe Air comes into play. To quote the developer guide:
Code signing is a cryptographic process of confirming that the specified origin of software is accurate.
If you're seriously considering the security of your application, you could use this feature to sign your air packages. By using third party software security certificates, you can be assured that your application cannot be tampered with. If an application is secured via Code Signing, then the Air app installer will notify the user. Of course you still have to tell your user before they install the application that they need to check this before actually installing the application--and that's just as easy as putting it on your download page right?.. And don't worry. If your code is signed via a code security certificate, bad guys can't recompile a secure and safe version even if they have all your code--unless of course you were actually shortsighted enough to package the certificate together with the application..
When all else fails, write lousy code. Good hackers hate reading lousy code. :)
@stevezzzz123456: That would be a good solution. Many applications with external interfaces actually use that method--sending a random "session-key" string after a valid login. The external app will the use this session string instead of the username and password for authentication in any subsequent requests to the server.
The big risk of course is that of session-hijacking. Just like cookies, session keys can be copied by a bad guy, thus hijacking the session of the user, allowing him to access the users data.
A basic solution to this problem is to store the user's authentication information on the cache and constant expiration of the session-key. For instance, you could automatically "expire" a session key every 5 minutes on the server side. The application can then ping the server and if the server fails to authenticate the application (because the session key it uses has already expired) then the app can again issue an authentication request using the cached user credentials and obtain a new session key. Although it is not fail safe, it still gives you the advantage over the bad guys in the sense that they could only hijack a session for a very specific amount of time--which might save you a little more in damages.
I could only give you some advice, sorry for that. I guess you'll find more information around.. :D