Challenges engulfing mobile apps development and strategies

Posted on October 12, 2013 10:38 am

Mobile apps proliferation has undoubtedly created income for both developers and users. Take for example Mobile money transfer platform that has created millions of jobs in East Africa. Think of how much governments are saving for not printing money as more and more businesses are embracing cashless transaction. In Kenya, Uganda and Tanzania one can literally pay for anything whether it is a service or product with mobile money transfer platform. However, there are so many challenges that come with mobile development strategies and all are important. As an app developer it’s better to leverage the Permissions Model Used by the operating system whether it’s Android, Windows OS etc. In most cases, permission model used by most mobile operating systems are considerably strong on the base device. The permission models used by Android and iOS are good because the apps are isolated from each other and therefore the developer should be able to leverage as much as possible. In my experience, it is much easier to create a mobile apps that is granted access to the entire Operating System instead of taking the time to figure out which services, binaries, files, and processes it actually does need to function.

Under most circumstances, the security architecture of mobile devices will not let the application have such access so easily and a developer should be extremely careful by leveraging the permission model by the mobile operating system that ensures application plays by the rules. The other one is the least privilege model that should is used to develop application on a mobile device in a process that involves asking for what is needed by the application and amount of services, permissions, files, and processes the application will need and limit the application to those items. A good example is where an iPhone app does not need access to the camera on the iPhone and under all circumstances it should not grant itself access to the process that controls the camera. Other main problem that concerns me most is what we programmers call Sensitive Information Properly also known as SIP. I always encourage developers not to store sensitive information in clear text on the device. A competent developer should make good use of native encryption resources available on the major mobile devices, including the iOS and Android that should be leveraged. In fact nowadays most platforms provide the ability to store sensitive information in a non-clear-text fashion locally on the system and those features enable applications to store information properly on the device without needing third-party software to implement the functionality.

Mobile Application Security is not negotiable at all. An app developer should comply with application’s Code even if it does not make the code more secure. Australia just published new guidelines that most people hope will bring compliance to another level.The new guidelines allows users to know that an app has followed the practices required by the device’s application store like Apple’s app store and Google Play stores among others. Seasoned developers knows very well that, RIM’s BlackBerry and both Apple’s iOS have specific processes and procedures that must be completed before an application is published through their stores and often it requires application signing. When an app is going to perform in sensitive areas such as needing full access to the device, the appropriate signatures are required to complete actions and in case an application is not signed at all, it will have a much reduced number of privileges on the system and will be unable to be widely disturbed through the various application channels of the devices. Depending on whether or not the application is signed, or what type of certificate is used, the application will be given different privileges on the operating system.

There is also need as an app developer to focus on Secure and Strong Update Processes. Contador Harrison working experience shows that a secure update process needs to be figured out because an app not fully patched is a big problem for the application. The main idea behind this is to create a process where an application can be updated quickly, easily, and without a lot of bandwidth. If you ignore, it can balloon into a big problem if updating software after it lands on a mobile device proves difficult. Mobile application security represent the current wave of technologies as that has become the default computing method such as e-mail, online shopping, gaming, and even video entertainment. In developing regions of Africa, Brazil, India and China and Middle East mobile phones are the primary computing device in the household, not the personal computer like the case in developed Western World. One of the most interesting thing is that mobile migration has involved new hardware like iPhone 4,5 and now 5S , Nexus S, Samsung Galaxy S3 & 4 series, etc, new software, and new applications across the platforms which has brought whole new world of security challenges to app developers.

This as we have witnessed has become a new green field for attackers and fraudsters. Security threats that previously did not exist have become the norm especially on Google Play. A developer should also understand the Mobile Browser’s Security Strengths and Limitations. While writing an application that will leverage the mobile browser, developer need to understand security strengths and limitations. One should be able to understand the limitations of cookies, caching pages locally to the page, remember password check boxes, and cached credentials. It is critical for developers to understand security guarantees the mobile browser can provide the web application and then plan appropriately for any gaps. When a security expert demonstrated how to hijack a plane using Android left a lot to be desired. As a mobile apps developer, I realized despite the advance in development process some developer’s applications have “read-only” support and therefore, the user can access the mobile HTML page of the application with an option to view its contents. The user can add, update, or delete any information in this site unlike the case before when it was probably designed in mind that many mobile browsers and their devices are wildcards right now and anything more than read-only access would pose too high a security risk.

While am developing an application, my security book usually is filled with pages and pages of threats, exploits, and vulnerabilities and each of those cases, I do understand the risks to a given technology or topic. Threats to mobile devices and their apps are very real and it is important to understand which ones matter to a given application. My acquired knowledge has taught me the best way to start this process is to enumerate the threats that are real, design mitigation strategies around them, and note the others as accepted risks. This process is well-known in developer’s circles as a threat model for mobile application although the threat model should not be too exhaustive. Instead, it should allow app developers to understand all the threats to the system and enable them to take action on those that are too risky to accept. Use of secure and intuitive mobile URLs is equally important and must be adhered to all the time. I have dealt with login pages optimized for mobile web browsing but however, additional login pages and domains where users enter credentials gives the users a confusing experience. Such a move could be disastrous to anti-phishing especially where some companies use third parties to host their mobile websites and such sites stem from that third party’s domain, not the company one. I would like to conclude by saying that although the use of secure storage is imperative and implementing it on a mobile application for the iOS will always be different than on Android or Windows. Therefore, a developer should seek advise on each platform. Overall, mobile application security has so far proved to be an interesting industry to follow, and my blog was to help developers along that way.

Contador Harrison