This article is the second in a series illuminating the developer’s perspective on mobile app security by guest contributor and developer Evan Rose — managing partner at Rose Digital. The first post covered planning mobile API security, and in this installment Evan explains what developers need to keep in mind as they code their mobile apps.
Concerns while coding
While writing mobile applications, many developers overlook security best practices in order to speed time to market. So much so, in fact, that nearly 25 percent of mobile applications contain at least one major security flaw. That is a huge number of critically flawed applications. For organizationes, having a mobile security breach can discourage users from using your app and do serious damage to your adoption rates. Thankfully, there are a few rules to follow while developing that will help cover your bases.
On-device token storage
Secure OAUTH token storage within your application can be a make-or-break factor in your app’s security. Storing the token anywhere it can be accessed by a malicious entity can put not only your app at risk, but your API security as well. While storing sensitive data to device storage is always a risk, you may mitigate that on mobile devices by storing your data in two locations:
One particularly damaging type of security breach is the exposure and publishing of sensitive user data. Where are you storing data in your application? Are you sure that storing the data is absolutely necessary? As a developer, it is important to operate with the assumption that there is no secure storage on a mobile device because operating systems will always have bugs that allow malware to root or jailbreak the device and read data written by your app. Before you make the decision to store your data on the device, weigh your security and usability concerns. If you do decide to store your data on the device then you need to consider which method of encryption you will use to protect that data from prying eyes. Any personally identifiable information (PII) stored in local storage must be encrypted. Use the iOS and Android encryption libraries for this. Most importantly, always encrypt any communications from your app!
Keep the client dumb
Presentation-layer code is not the place to keep the organization logic or ‘brains’ of your application. Assume that any logic you include in the client can be seen or compromised. For web apps, this is as simple as opening up Chrome DevTools and de-obfuscating your code. For native mobile apps, many reverse engineering tools exist to help an attacker understand how your app works in detail, exposing your intellectual property and highlighting potential attack vectors. When and if a malicious individual reverse-engineers your app, you don’t want them to find the proprietary algorithm that drives the whole experience!
Watch your third party libraries
Most engineers know the mantra “don’t repeat yourself” (DRY). The principle often extends to not reinventing the wheel by re-creating commonly used libraries for yourself. While this is largely a good thing because it has led to a proliferation of packages in popular programing languages, it also fosters a reliance on other people’s code. Using other people’s packages can be done, just try to make sure that you’re vetting the people and companies whose code you are putting into your app. If you can’t see the code before packaging, you’re dealing with the equivalent of candy from a stranger. You would be wise not to take it.
What to do before delivery
Before sending your app to production, you should evaluate your app’s back-end security posture with a few quick sanity tests:
- Fuzz and invalid input testing — Testing randomized inputs and explicitly invalid inputs to be sure that your validators aren’t fooled.
- Malicious input — This testing covers a wide set of malicious attacks including cross-site scripting, SQL injection, HTTP verb tampering, LDAP injection, ORM injection, XML injection, SSI injection, code injection, OS command injection, and buffer overflow.
- Cross-site request forgery — This attack causes users to take state-changing action within your application without knowing they are doing it. This type of attack is a bit more difficult with mobile applications, but if your application is cracked — then it is possible.
- SSL/TLS configuration weakness — To successfully use TLS, you must ensure that your protocols, ciphers, keys, and renegotiation are configured properly. You also need to ensure certificate validity.
To learn more about security testing, you can check out OWASP, which provides excellent resources for learning more about how you can secure and test your application. Also, take a look at the NowSecure collection of more than 50 Secure Mobile Development Best Practices.
If your organization doesn’t have a security team, then it is difficult to pull engineers from their assigned tasks to do periodic reviews. Using mobile app security testing tools help you understand how your application stands up against the latest exploits.
Good luck out there and happy coding!