There are over 1.2 million apps in the Apple App Store, over 9 million registered app developers, and the app revolution has added more than 291,250 iOS jobs to the U.S. economy since the introduction of iPhone in 2007.
This has resulted in Apple paying more than $9 billion in royalties to developers through the App Store. If you are one of these developers, then the annually planned and pending closure of the App Store for the holiday season is already on your mind. Looking forward to 2015, we wanted to share some information security tips to help you keep your app users safe, keep their information private, and help prevent malicious entities from stealing your hard work.
Transitioning to iOS 8
iOS 8 was released on September 17 of this year, and yet many apps haven’t finished the transition to iOS 8. We expect many developers have been using the first part of December to integrate those changes and release their first fully iOS 8 compliant app before the closure. One of the main changes for iOS 8 is how permissions are handled. Whether it is push notifications, location services, or authentication, there is a strong push to put explicit confirmation between the end user and your apps ability to perform those functions.
Changing the way an app manages permissions requires care and consideration for both how the code is handled and how the user experience is defined. Since these changes have already been documented by Apple, we’re going to focus on a few quick tips that can help you keep your app secure moving into 2015.
Is Apple Fairplay Enough?
Apps distributed in the App Store are protected with Fairplay DRM, which helps prevent theft and duplication of your apps. However, Fairplay has been broken for some time and tools are readily available to allow malicious users to remove DRM from apps.
This means the contents of an app can be easily investigated by third parties, potentially revealing sensitive information about the app, the developer, or how the app is being used.
Protect Your Assets
Knowing that DRM will only get you so far, you will want to protect the assets in your app to the best of your ability. One of the easiest ways people can extract information from your app is by investigating the contents through the file system. Here they can see all the files that make up your app.
Leaking Data Through Image Files
Do you have images that contain advertisements for unreleased apps, unlockable game features, or other sensitive content? One easy way to protect these assets from attacks is to use the XCode Assets Catalog instead of standalone images. This will get them out of the directory listing and place them all collectively in a binary format in the Assets.car file within your app.
An Asset Catalog may be enough protection for some, but these files can also be easily parsed with inexpensive tools. If you really have an artwork that you choose to protect then consider encrypting it and storing the encrypted version within your app. You can use an open source tool like RNCryptor and then protect the decryption key by defining it in your applications source code. This will make it extremely difficult (but not impossible) for attackers to extract the image files in your app and provide you fairly robust protection for your image assets.
Using a Cloud Backend?
Protect Your Credentials.
If you are using CloudKit or Parse.com, ensure that you aren’t placing your app’s authentication credentials in your apps info.plist file or in any external file that would appear in your app directory listing.
Secure Your Data.
Ensure that your Access Control Lists (ACLs) on parse.com and allowed URI’s on CloudKit are configured properly so you are not potentially exposing user data to those that should not have access to it. This is an easy one to overlook, especially since some developers open up ACLs in an attempt to make the development process easier. Then they forget to lock it back down once going to production. If you have done this in the past, then you should consider getting in the habit of having your development environment mirror production to prevent little surprises.
Using Third Party Services?
If you are using any third party services for scoring, data storage, authentication, or image management (the list goes on), then ensure that all network requests are over HTTPS and don’t rely on HTTP. HTTP would allow an attacker to MITM your app and intercept any communications between your app and that service, potentially disclosing everything your app does regardless of the confidentiality of that data.
You will also want to make sure that the HTTPS connection your vendor is providing is secure and patched to prevent existing known attack vectors. If you are uncertain whether your service provider is using an appropriate level of HTTPS, then you can use the DigiCert SSL Installation Diagnostics Tool to find out. Report any issues you find with your vendor and help drive awareness to the weaknesses they may have. You will not only be helping yourself, but all the customers using that service.
Upgrading to Facebook Login & API 2.0?
If you’re following the guidelines provided by Facebook then you are likely using this opportunity to upgrade your app to the new login and API 2.0 features provided by Facebook. When using the new Facebook login, you can ensure the authentication integrity of your app by using the new declined permissions selector on the active session:
NSArray* permissions = [[FBSession activeSession] declinedPermissions];
You should check this after every permissions request and confirm that the user did not decline a critical permission that is required for your application to function or a permission that allows your app to stay secure. This is important because this is probably an addition to the previous permission code flow that you already have in your app. Without this check, you may unsuspectingly allow a user to gain access to portions of your application that you do not want them to have access to.
Don’t Sign Your Own Certificates
Some developers have self-signed SSL Certificates on backend services they control. This is an extremely bad idea. Do not implement a code path like this in your app, you can easily get an SSL Certificate in your price range. The security risk here is that by instructing a NSURLConnection to accept untrusted SSL Certificates, you are opening up that service of your application to MITM SSL attacks.
Good Luck!
Hopefully this article provided you with a few things that you can do to help keep your app, users, and hard work safe from malicious third parties. Whether you are trying to squeeze in a release before the end of the year, update your app to iOS 8, or upgrade to Facebook login—now is a great time to ensure that you are doing your best to keep your app secure for 2015. We wish you many happy downloads!