The OWASP Mobile Top 10 Risks is an overview of a generic list of the most common risks found in mobile applications. We see these risks in mobile applications every day. When we see them they often show up as vulnerabilities in the applications we are assessing. No list, such as this, can adequately cover *every* issue an application will face. However, this is a good starting point for a security team or development team looking to understand the most common mobile application security issues for iOS. This article focuses on these risks (and ways to mitigate them) for iOS. For a more generic look at these controls and for further ideas on mitigations check out the OWASP Mobile Top 10 Controls.
1 – Insecure or unnecessary client-side data storage
This risk addresses the obvious concern of sensitive data being stored on mobile devices. All developers must carefully consider if storing a piece of data on a mobile device’s persistent storage is absolutely critical to the application’s correct functioning. If it is not the data should simply not be stored. If the data is required, and it is sensitive, it must be protected. Data protection often means “encryption”. For iOS developers, this is not an onerous problem. Apple provides a very easy to use, and secure, data protection mechanism for iOS 4 and newer devices using 3GS or newer hardware. The mechanism is aptly referenced as “Data Protection”. Apple provides two methods of doing this that very straight forward to use. Pass in the correct option (NSDataWritingFileProtectionComplete) to NSData writeToFile:options:errors:and the file is protected and encrypted when the device is locked. Alternatively, you can use NSFileManager setAttributes:ofItemAtPath:error: and pass in theNSFileProtectionKey attribute with the NSFileProtectionComplete value to protect existing files.
For more information see: Implementing Common Application Behaviors.
Note: The user must have a passcode for this to work. iOS 3.x on 3G and older devices do not have this capability and require much higher effort and less secure/user friendly solutions.
2 – Lack of data protection in transit
After data has been secured on the device the next high concern area is protecting the communications between the mobile application and the server. By far, the most common communication protocol is HTTP. For iOS developers this typically means using the NSURL or NSURLConnection class. By default,NSURL or NSURLConnection will fail with an error in the event of an SSL issue. Development environments do not, typically, have a valid SSL certificate, which creates a problem. NSURL and NSURLConnection behavior is changed to accept invalid certificates to continue development without hassle.
With NSURLConnection an application must implement the delegate methodscanAuthenticateAgainstProtectionSpace anddidReceiveAuthenticationChallenge to ignore SSL issues. Implementing these methods also gives you the opportunity to warn the user in the event of an invalid SSL certificate. The best behavior is to fail with an error the user can’t accept for production builds. Conditional code that is never compiled into the production binaries (that excludes the risky code) is best. Make sure all production code has development oriented SSL code pruned out of it.
The long and short of it is that you have to actively work at making this insecure on iOS.
3 – Personal Data Leakage
This is less of a technical issue and more of a purposeful choice that must be made as a developer. Developers must take care to guard their user’s private information. Applications must protect their user’s personal data. Use the same data protection mechanism described in the previously discussed risk “Insecure or unnecessary client-side data storage” to protect personal user data. Beyond this it is an application design decision about how the application will handle the user’s personal data. Personal data privacy has become a hot topic and user’s are becoming much more aware that their private data may be at risk in mobile applications.
4 – Failure to protect resources with strong authentication
This issue is something of a server and client issue. Very little authentication is typically performed on a mobile device. The majority of the authentication that mobile devices encounter is oriented around a server authenticating a mobile application. Application’s on mobile devices rarely authenticate other services directly. If this does occur an application is usually being asked to share a resource, such as a photograph or some other piece of data managed by the application, with a server.
The main concern is that iOS applications properly authenticate to servers and that they implement strong authentication that uniquely identifies each mobile application user to the server. One of the main concern for developers is to never embed client side secrets in their application and then use those as an integral part of an authentication method.
5 – Failure to implement least privilege authorization policy
For the local side of things only request permissions you absolutely need. Does your application *really* need access to the user’s GPS? This falls more along the lines of protecting your user’s sensitive privacy oriented data. Be judicious with what resources you attempt to access.
The other part of this issue is server application oriented issue. The key issue at hand is that applications, especially thick-client oriented applications, may contain a great deal of functionality that is not available to lower privilege users. The server is responsible for checking that a user can perform a requested action. Even if the functionality is accessed in the application, the server must not allow lower privileged users to access and execute higher privileged server side functionality. Vertical privilege escalation is a constant risk to server side applications.
Horizontal privilege flaws allow users of mobile applications to easily circumvent authorization controls and access the data of other users at the same privilege level. Care must be taken to only allow a mobile application to access server side data that belongs to the currently authenticated user.
6 – Client-side injection
Client side injection is an interesting problem that can lead to a variety of issues depending on the application and how it operates. Many iOS applications utilize SQLite, which means that at some level those applications may be vulnerable to SQL injection. Often the consequences of SQL injection against a client side application are minimal.
A recent vulnerability in the Skype client for the Mac (I know, it isn’t an iOS app) illustrates the possibilities of “Rich User Environments” and the consequences they can have when an application implicitly trusts input.. The vulnerability was a simple cross site scripting attack that allowed remote code execution. Similar issues can surface in mobile applications if the application uses UIWebView or other rich environments and does not carefully check user (and other!) input.
The mitigation falls down to standard data validation. Any specific advice given here would be to specific to be useful in a general way. Make sure your data confirms to your expected length, range, type and format. Length is obvious, range is for data that has expected numerical ranges (positive integers only), type is for any sort of integer or other data structure being read and format is for the actual data formatting (such as phone numbers).
Data type is actually an interesting one. Any sort of serialized NS objects are inherently insecure and should never be trusted from a remote source. Similar to NIB files (serialized objects), they must only be used locally and only come from trusted sources. If a user can directly input objects into the system and manipulate them a variety of difficult to catch security bugs can result.
Another interesting issue is with format strings. From the comfortable confines of the NS* Objective-C environment it barely feels like you are writing code that gets compiled down to native instructions. Drop down to a library, like SQLite and that illusion is quickly shattered. Format strings using the %@ formatter are vulnerable to a variety of interesting attacks: ()
7 – Client-side DOS
This issue is fairly obvious. Make sure you are being a defensive programmer. This can result from development errors and bad logic. Modern mobile applications do a lot of parsing of formats such as XML and JSON. Defects in these parsers or in the way they are used can result in unexpected DoS.
8 – Malicious third-party code
Assume the device is jailbroken. Let me say that again: assume your user’s device is jailbroken. Act accordingly. Also, even on legitimate, non jail-broken devices there are interesting problems that can arise related to the URL / Protocol handling mechanism. iOS is not very big on Inter Process Communication. One of the few mechanisms available to iOS developers to accomplish this is the custom URL scheme. Use these with extreme caution. External (malicious) web sites can call these. The behavior when multiple applications define the same scheme is undefined (and you can’t stop an application from trying to usurp your scheme).
From iOS 4.2 and on there is a better IPC mechanism (application:openURL:sourceAppplication:annotation). If you need to perform IPC, use this. You can even pass real objects instead of hacking them up into a URL ready format (see: trusting serialized objects is a bad idea).
9 – Client-side buffer overflow
This is still quite possible. Since Objective-C is a strict superset of C there is no limit to the depth in which an iOS can get itself in trouble with old C programming issues. I won’t belabor them here, but they are quite possible. Pay careful attention to your string formatting (NSLog, etc.). Stick to the NS* class hierarchy when at all possible. Abstract away your C code to the smallest amount possible and be extremely cautious with any C string and memory operations.
10 – Failure to apply server-side controls
See: The OWASP Top 10.
For some other thoughts on iOS application security please visit our earlier blog post on the topic.
Published date:  24 May 2011
Written by:  jeremy.allen