Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

3 iOS App Attack Vectors and How to Strengthen Your Defenses

DZone's Guide to

3 iOS App Attack Vectors and How to Strengthen Your Defenses

A silver-bullet solution to iOS app security simply doesn't exist. Effective mobile app defense begins where vulnerabilities and risks originate: in development.

· Security Zone
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

This article is featured in the new DZone Guide to Proactive Security. Get your free copy for more insightful articles, industry statistics, and more!

I hate to break it to you, but a set-it-and-forget-it, silver-bullet solution to iOS app security doesn’t exist. As I’ve seen over the past many years, adversaries continuously develop new ways to compromise mobile devices and apps — so developers and security teams also need to work continuously to improve the security of their iOS apps. Effective mobile app defense begins where vulnerabilities and risks originate: in development.

In my experience, iOS apps encounter security gaps in three areas:

  1. Insecure data storage on the device

  2. Insecure network communication

  3. Weak authentication

In this article, I’ll explain how developers can avoid or fix these issues. Comprehensive mobile app security extends beyond just these areas, but developers who follow these best practices will significantly strengthen the security of their mobile apps.

1. Insecure Data Storage on the Device

An iOS app might store data in any number of locations on a device, many times without a developer’s knowledge. Common storage locations to watch out for include:

  • Device logs

  • Private app directories

  • RAM

  • Keychain

Storing app data insecurely exposes sensitive user information if a device is lost or stolen. Or, in the event of device compromise, malware may harvest data stored in clear text and exfiltrate it to an unauthorized third party.

  • Avoid storing any sensitive data in the first place. Unfortunately, that’s not always possible. If sensitive data must be stored, encrypt it using a randomly generated master key in addition to a passphrase supplied by the user whenever data is accessed (i.e. a password-based key derivation function). This will make it more difficult for an attacker to recover data even if the master key is extracted from the device.

  • Explicitly disable “newCachedResponse” when implementing an NSURLConnection delegate. This will stop an app from caching web data, particularly HTTPS traffic. Many developers don’t realize that iOS caches HTTPS requests by default, potentially storing sensitive app data in the “Cache.db” file that resides in the private app directory. The code snippet below illustrates one possible method for disabling this option:

    NSURLSessionConfiguration *config =
    [NSURLSessionConfiguration
     
    	  defaultSessionConfiguration];
    
    config.URLCache = nil;
    NSURLSession *session = [NSURLSession
    sessionWithConfiguration: defaultConfigObject
                             
    	  delegate:self delegateQueue:[NSOperationQueue
    	  mainQueue]];
  • Finally, to validate that the app isn’t caching sensitive data, run the app on a test device, and perform testing to ensure that data isn’t left behind on the device.

2. Insecure Network Communications

Developers need to secure an iOS app’s network communications or they risk exposing credentials and other sensitive data. A number of vectors put a iOS app’s network traffic at risk, including man-in-the-middle attacks leveraging insecure Wi-Fi, a compromised wireless carrier network, or malware on the device that intercepts traffic. Developers can do three things to significantly reduce the risk of exposing sensitive data in transit.

  • Implement App Transport Security (ATS). ATS enforces a minimum network security policy that forces apps to connect to back-end servers using HTTPS instead of HTTP to encrypt data in transit. SDKs for iOS 9.0 and later enable ATS by default, but some developers opt out because their app relies on certain back-end services that can’t support TLS 1.2. This is no reason to completely opt out of all the security benefits of ATS. Use exceptions to opt out on a domain-by-domain basis.

  • The following code snippet from Apple shows the structure of ATS configurations:

    The following code snippet from Apple shows the structure
    of ATS configurations:
    NSAppTransportSecurity : Dictionary {
    	NSAllowsArbitraryLoads : Boolean
     	NSAllowsArbitraryLoadsForMedia : Boolean
     	NSAllowsArbitraryLoadsInWebContent : Boolean
     	NSAllowsLocalNetworking : Boolean
     	NSExceptionDomains : Dictionary {
     		<domain-name-string> : Dictionary {
     			NSIncludesSubdomains : Boolean
     			NSExceptionAllowsInsecureHTTPLoads : Boolean
     			NSExceptionMinimumTLSVersion : String
     			NSExceptionRequiresForwardSecrecy : Boolean
    // Default value is YES
     			 NSRequiresCertificateTransparency : Boolean
    		}
    	}
    }

    ATS should be enabled globally by linking to the iOS 9.0 SDK or later. Some developers opt out of ATS by setting the “NSAllowsArbitraryLoads” key to “Yes” or “True.” For security’s sake, opting out should be a last resort. For any existing apps which communicate to servers over HTTP, an exception must be set using either the “NSExceptionAllowsInsecureHTTPLoads” or “NSThirdPartyExceptionAllowsInsecureHTTPLoads” key.

  • Encrypt or encode sensitive values before transmitting them over the network for an additional layer of protection in the event TLS/SSL is compromised. Encrypt highly sensitive values with AES (also known as Rijndael) using a key size of 256. For hashing purposes, use an algorithm such as SHA-256 or higher.

  • Implement certificate pinning to protect against man-in-the-middle attacks resulting from an adversary using a fraudulent certificate to impersonate a back-end service used by an app. When an app “pins” the public key of a service it trusts, it will reject all certificates that do not match the hash of the pinned certificate. Rejecting a certificate will stop any connection to the endpoint and prevent the transmission of data over a potentially insecure channel.

3. Weak Authentication

Strong authentication practices verify a user’s identity. Attackers can exploit weak authentication measures to impersonate a user, bypass authentication to submit requests to an app’s backend services, or hijack a session to perform actions on behalf of the user within the app itself (for example, initiate transactions). We regularly identify one of three problems within iOS app authentication schemes and recommend that developers do the following to strengthen authentication within their mobile apps.

  • Implement two-factor authentication (2FA) to mitigate against attackers using stolen credentials. At the very least, 2FA should be used prior to the initiation of sensitive transactions. SMS is falling out of favor as a channel for 2FA, but it’s still better than no 2FA at all.

  • Configure session-management cookies securely, which includes making sure they’re of sufficient length, of sufficient entropy (i.e. unpredictable), and marked secure. If cookies are not of a sufficient length or sufficiently random, an attacker can execute a brute force attack by guessing or predicting the ID of a valid session or exercise all possible values. Marking a cookie as secure tells the browser to only send the cookie if the request is being sent securely, such as over HTTPS. If the cookie were instead sent over HTTP, the cookie could be sent in cleartext, potentially allowing an attacker to capture the session information and hijack an active session.

  • Perform authentication requests on the server-side and not locally because relying on client-side security alone is a bad security model. Never trust the client application when making authentication decisions. Implement server-side session timeouts, as well, because relying on the client to initiate a timeout may leave a session open long enough for an attacker to leverage.

Follow Secure Mobile Development Best Practices and Validate iOS App Security With Testing

Insecure data storage, insecure network communications, and weak authentication are certainly not the only attack vectors for iOS apps. They are simply common areas for improvement that we identify in our testing. Following the guidance above alone will not guarantee the security of your entire mobile app, but it will set a good security baseline. In addition to establishing security standards and following secure mobile development best practices, make sure to validate and certify the security, privacy, and compliance of your app with regular or even automated mobile app security testing after each build, as well as deep dive penetration testing prior to deployment and after each app update.

This article is featured in the new DZone Guide to Proactive Security. Get your free copy for more insightful articles, industry statistics, and more!

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

Topics:
security ,ios ,app security ,mobile app development ,authentication

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}