The top 3 code security mistakes made by iOS developers
Apple has done a lot to foster a reputation for strong security and privacy in iOS, their mobile OS. So it’s surprising to see that the vast majority of iOS apps that come to me for penetration testing have fundamental — and easy to fix — security problems.
I recently wrote a post with a long checklist of security points to verify before you release your iOS app. Some developers have even been kind enough to tell me that they found it helpful. Others, rightly, point out that this is just the tip of the iceberg.
This post, by contrast, points out the most common 3 security errors I find in iOS apps. All of them are easily addressed.
So: does your app definitely avoid all of these traps?
Security flaw 1: Not storing security tokens and passwords properly
iOS comes with Keychain, a hardware-backed security store designed for small pieces of data like passwords or authentication tokens. You should use this to store any OAuth token, for example.
The benefit to the user is that this data can’t be grabbed by someone, even if they have physical access to the phone. In fact, its usage and distribution is sensibly limited even if you are allowed access to it.
Learn about how to use the Keychain here.
Security flaw 2: Developer assistance left in
For testing whilst developing apps, developers can find it really useful to disable certain security controls or create backdoors. Testing in-app purchases is frustratingly long-winded, for example, so it’s common to write code which bypasses the purchase stage in order to test that the item purchased works correctly.
Similarly developers often leave details of their test back-ends (and sometimes even credentials) in the code.
The rule is: all this must be ring-fenced during dev, and must be removed for every public release.
Whilst we’re at it, you also need to remove logging — or at the very least remove anything that could potentially log anything sensitive.
Security flaw 3: Unsafe handling of input data
All input data needs sanitising to avoid things like SQL injections attacks. That means removing bad characters or escape sequences from anything input into your app.
Input data isn’t just data that the user has typed, selfied, or sung into the app. It also applies to anything you download from the back-end or anything from an external storage location or API.
The basic rule is: check that the data looks like what you expect, before you use it.
Special care is needed when deserialising objects with NSCoding. This has a known security vulnerability in that it can instantiate an object which runs code, without knowing. There is a replacement called NSSecureCoding which in many cases can replace NSCoding without any extra changes needed.
These are the most common issues that I find when security testing iOS apps. Note, by the way, that in general they are pretty simple to fix. Yet the majority of iOS apps have these problems, and others.
Tom Colvin is a mobile security expert and founder of Conseal Security, the mobile app security experts, and Apptaura, the app development specialists. Do get in touch if we can help with penetration testing of your app!
