Skip to content

On the top 5 iOS appsec issues

Nearly 13 months ago, the Intrepidus Group published their top 5 iPhone application development security issues. Two of them are valid issues, the other three they should perhaps have thought longer over.

The good

Sensitive data unprotected at rest

Secure communications to servers

Yes, indeed, if you’re storing data on a losable device then you need to protect the data from being lost, and if you’re retrieving that data from elsewhere then you need to ensure you don’t give it away while you’re transporting it.

Something I see a bit too often is people turning off SSL certificate validation while they’re dealing with their test servers, and forgetting to turn it on in production.

The bad

Buffer overflows and other C programming issues

While you can indeed crash an app this way, I’ve yet to see evidence you can exploit an iOS app through any old buffer overflow due to the stack guards, restrictive sandboxes, address-space layout randomisation and other mitigations. While there are occasional targeted attacks, I would have preferred if they’d been specific about which problems they think exist and what devs can do to address them.

Patching your application

Erm, no. Just get it right. If there are fast-moving parts that need to change frequently, extract them from the app and put them in a hosted component.

The platform itself

To quote Scott Pack in “The DMZ”, If you can’t trust your users to implement your security plan, then your security plan must work without their involvement. In other words, if you have a problem and the answer is to train 110 million people, then you have two problems.

{ 2 } Comments

  1. Jeremy Allen | May 26, 2011 at 8:27 pm | Permalink

    Hello. Original author of the top 5 post. We recently published an updated version of this blog post in the form of iOS coverage of the OWASP Mobile Top 10 at: (

    To address the other concerns: Buffer overflows are a legitimate concern. Every year at Pwn2Own someone breaks Safari (running in the mobile user context). The idea is to just be cautious when using C based components. For example, if you are reading in some JSON and you use some C based JSON parser your application is vulnerable to memory corruption and all of the data in your application is easily accessible. I don’t see this as very controversial. ASLR in iOS 4.3 may change that a bit.

    The point regarding the platform and patching is to simply be aware of the pitfalls and the additional risk these introduce. You still have to make decisions that have a definitive security impact related these two issues. Deciding to move components to a hosted service because they change rapidly is the exact kind of risk trade off the app store update process forces. It is not good or bad, just a thing to think about.

  2. Jeremy Allen | May 26, 2011 at 8:29 pm | Permalink

    One additional (separate) point for consideration regarding ASLR is that it can be defeated. See: for more details 🙂