7 Replies Latest reply on Mar 3, 2008 7:06 AM by blaike

    Low Security

    Shakarhaba87
      Hey,

      Is there any plans to increase the security of the source code of the AIR apps?
      I'm currently developing two applications one using AJAX and the other one using Flash
      The problem is that when packaging and installing the program, AIR places all the source code (source files
      such as html,swf,as... files) on the program root so anyone with a little knowledge on those technologies could steal the source code
      or put at risk some information.

      For example in order to get a user logged in, I'd send a XHRequest to the server with the user info, using that
      request from the application anyone could run such opperation from any webpage or other AIR application.
      I'd like such things to stay private in order to make my program the only one able to access to the database.

      So, as I said, is there any plans to encode, or include the source codes inside the .exe/.dmg or something like that
      to make the source-code more secure and private?

      Thank you all for your time!
        • 1. Re: Low Security
          deplorableword
          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?
          • 2. Re: Low Security
            Oliver Goldman Adobe Employee
            The visibility of HTML and JavaScript files in AIR applications is no different than their visibility in web applications; simply select View>Source in the browser.

            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

            • 3. Low Security
              stevezzzz123456
              quote:

              Your server should use other means to protect itself.


              In what way would you suggest?
              • 4. Re: Low Security
                Shakarhaba87 Level 1
                Such as? I'd be very interested of knowing those alternatives
                • 5. Re: Low Security
                  stevezzzz123456 Level 1
                  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?
                  • 6. Re: Low Security
                    blaike
                    quote:

                    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:

                    quote:

                    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..

                    I guess I'll still stick to the Oliver's point: your server should use other means to protect itself. My points above are just the tip of the iceberg. If you're quite happy today, you could start by researching on things such as SSL, basic encryption, prevention of session hijacking, cross-site scripting, request forgeries, better authentication schemes and other fancy stuff. But if you're quite lazy today (both in spirit and in securing your application) then just minify your javascript. I wouldn't want to have to be the sucker trying to figure out reverse engineer that.

                    When all else fails, write lousy code. Good hackers hate reading lousy code. :)
                    • 7. Re: Low Security
                      blaike Level 1
                      @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