The thing is, though, it's been my experience that many times the very people who write the apps themselves fail to sufficiently understand and internalize just how the attacks will happen. Sure, we've all read about various hacks, but to many people, those are nothing more than abstract thoughts. When it comes to understanding how someone will attack your work, however, it becomes real. So let's consider that a bit.
Which of the following do you think are likely to happen to your app:
- Do you think your attacker will install and run your app to try to learn how it works? Sure, that's a given, right?
- Do you think your attacker will work his/her way through all the views and data fields in your app, and perhaps try various dictionaries of the big bad boys (e.g., SQL Injection, Cross-Site Scripting (XSS)) and so on? Sure, that too is a given, right? Even if those attacks aren't in any way relevant to the technologies in your app, they're going to try them anyway.
- Do you think your attacker will look through all the files in your app's sandbox (e.g., its ~/Documents folder), looking for potentially damning information like a user ID, password, or session token in a .plist file? Yup. Plenty of tools make that one real easy too.
- Do you think your attacker will configure a network proxy to intercept all of your app's communications to/from its server(s), looking for login credentials, session tokens, etc.? Oh yeah, still well in the realm of feasibility here.
- Do you think your attacker will use that same network proxy to try to get your app to connect to a server that he configures -- perhaps with a self-signed SSL certificate, or with a signed certificate where the root CA has been installed as a profile on the attacker's iOS device? Ruh roh! (Now I'm starting to hear "They can do that?!")
- Do you think your attacker will examine your app's executable file, doing surface analysis of it to look for strings, symbols, and other telltale info in the binary executable itself? Of course. But executables in the App Store are encrypted, you say? On a jailbroken device, an attacker can use a debugger to access the unencrypted executable commands just fine. (They have to execute, after all...)
- For that matter, do you think an attacker will load your app on a jailbroken device, put it into a debugger, and single step through it, looking for crypto keys and other sensitive data? Ruh roh, indeed!
- Do you think an attacker will try to tamper with the Objective C runtime by intercepting messages to/from the various objects in your app?
- Do you think an attacker will attempt to inject messages into your app in that debugging session, and get your app to misbehave?