Top 5 iOS Application Security Flaws

balaji
By balaji

December 30, 2011

Apple's AppStore is currently the biggest mobile application store with over 500,000 applications and more than 10 billion downloads. The iPhone and iPad have become household names today. With the increasing adoption of the iOS platform, more and more developers have started developing their own iPhone applications. Although they work hard on the look and feel of the application, the developers often ignore the security aspect. Let us discuss a few common mistakes made by iOS application developers.

Apple's AppStore is currently the biggest mobile application store with over 500,000 applications and more than 10 billion downloads. The iPhone and iPad have become household names today. With the increasing adoption of the iOS platform, more and more developers have started developing their own iPhone applications. Although they work hard on the look and feel of the application, the developers often ignore the security aspect. Let us discuss a few common mistakes made by iOS application developers.

1. Sensitive Data on device not protected

Almost every application stores certain data on the device. Data can be stored in the SQLite database or in plain files inside the application's Home directory. If this data is not encrypted, it can be easily stolen by anyone having access to the device.

Sensitive data should be stored on the device only if it is required. Use encryption to protect sensitive data. The iOS provides an easy-to-use API for this - the Data Protection API! Although, one can use a custom algorithm to encrypt data, it is advisable to use the built-in Data Protection API to do so as this API has been thoroughly tested by Apple.

The Data Protection API ensures that the data is encrypted securely as soon as the phone is locked. The iOS automatically decrypts the data once the phone is unlocked. The Data protection API leverages each user's unique device passcode in concert with the hardware encryption on an iPhone and iPad to generate a strong encryption key. This key prevents data from being accessed when the device is locked, thus ensuring that critical information is secure even if the device is compromised. Applications must designate which data files need to be protected and assign appropriate metadata attributes to them. This protection requires the user's device to have the passcode lock setting enabled and a valid passcode set.

2. Improper implementation of URLSchemes used to perform sensitive actions

Native iOS applications and web applications running on Mobile Safari can use these schemes to integrate with system applications and provide a more seamless experience to the user. For example: if your iOS application displays telephone numbers, you can use an appropriate URL to launch the Phone application whenever someone taps on one of those numbers. Similarly, clicking an iTunes link, launches the iTunes application and plays the song specified in that link. What happens when a user taps on a link (a URLScheme) depends on how the installed applications implement URLSchemes.

URLSchemes are also used to share data between multiple native applications. For example, consider a Point-of-Sale (PoS) application (App1) which reads the credit card information, validates this information at the server, and it calls another native application (App2) to perform the actual checkout action. In this case, App1 calls App2 using the URLScheme defined by App2. The URLScheme would look something like this –

app2://item='flowers'&amountSanctioned='1000'&deliveryAddress='Mumbai'

On accessing this URL, App2 will open with initial parameter values passed through the URL. Here, App2 will blindly trust the data received through the URL.

To prevent the application (App2) from accepting data from an untrusted source (a malicious application), the application should verify the invoker application (App1). As of iOS 4.2, the iOS APIs provide a mechanism to identify the Bundle ID of the invoker app. The application that is being invoked should maintain a white list of BundleIDs of trusted applications.

3. No SSL or Improperly Configured SSL

Many iOS applications communicate with the server using the HTTP protocol. The information transmitted to the server is often protected by using HTTP over SSL (i.e. HTTPs) in order to prevent eavesdropping and MiTM attacks. Typically this is done using the NSURLConnection class. This class establishes a connection with the server over HTTPs and warns the user if the certificate is not valid. But, the user has the option to dismiss the warning and continue with the invalid certificate. Developers often work in UAT environment wherein they do not have a valid certificate signed by a trusted CA. In order to avoid repetitive warnings, they use unsafe methods such as setAllowsAnyHTTPSCertificate which accept invalid certificates without warning the user. Such code should be removed before moving the application to the production environment (AppStore). Also, the application should implement a fail-safe mechanism using NSURLConnection class's didFailWithError delegate to avoid connections with invalid SSL certificates.

4. Data Leakage via Screenshot Backgrounding

The iOS platform uses certain features to improve the OS performance but some of these features can result in data leakage. For example, in order optimize the UI performance, the iOS takes screenshot of the application screen before moving it to background. When the application is relaunched, as the actual UI is loading in the background, it displays the screenshot in the foreground. This makes the application loading appear swift. The application blindly takes a screenshot of whichever screen appears before moving it to the background, even if the screen contains an input field where you have entered your Credit Card Number or other secrets. The application should thus ensure that it clears the sensitive information from the screen before moving it to the background. This can be done either by, blanking out the screen (so that the screenshot is blank) or by just clearing the fields which contain sensitive information, before the application goes into the background.

5. Unprotected UIWebView

UIWebView is used to embed the web content in the application. One can load the web page as it is inside the application by simply passing the URL to the UIWebView class object. This object renders the HTML as the iOS Safari browser (webkit) would render it. It can also execute JavaScript. Since JavaScript executes on the user's device, it can be used to attack the device. This is similar to the conventional XSS attack. Hence, the application should ensure that it validates and sanitizes the incoming data before passing it to the UIWebView class object. The input should be validated to check if it contains any special characters which can be used to build XSS attack vectors.

In this article we saw some of the best practices that help in securing an iOS application. However, they might not be feasible to implement for every application depending on the business requirements. Following these practices does not make your application 100% secure and there are still other ways of attacking the application by exploiting the backend services.

References

  1. iOS Application Programming Guide
  2. OWASP Mobile Security Project

Tags: Features

About

balaji

SUBSCRIBE TO OUR BLOG

Buyers-Guide-Collateral

WHITEPAPER

Buyer’s Guide to Managed Detection and Response

Download
MDR

Get AI Powered

Managed Detection and Response

MDR-learmore-btn

 

MDR-Guide-Collateral

REPORT

AI-Driven Managed Detection and Response

Download Report
Episode

EPISODE-25

Red-LineAsset-6

Why Your ‘Likes’ on Facebook May Be Revealing Far More than You Thought

Click URL in the Post for the Full Podacst
  • FacebookAsset
  • LinkedinAsset
  • TwitterAsset