iOS secure development for banking apps

Published in

Digital Banking Labs

3 min readMay 31, 2017

This article is an attempt to help developers to secure their iOS applications from an attacker and covers iOS general system securities, memory safety and suggestions. Here I’m going to explain very few basic things.

Jail-broken Test

If you’re working on applications that deals with financial entities you must ensure that your application should never work on jail-broken devices, because these devices are more vulnerable to attacks and iOS won’t be able to protect your personal information. This makes it easier for the attackers to hook into your application and take sensitive information along with user’s personal details. There are various tools like Cycript, GDB, Snoop-it etc to perform runtime analysis and steal sensitive data from within your application.

Follows a very small code snippet for jail-broken test in iOS.

Using third party libraries

When using compiled libraries from untrusted sources, always make sure it doesn’t contain any hidden surprises. Best way to do this is to go and read the source! This will of course take away some of your precious time but you get to see what’s really happening behind the scene and sometimes you get to see clean practices or good coding standards by other awesome developers which you can absorb into your coding skills.

Leaking sensitive data while application pauses

How many of you know that when you pause an application there is a minor chance that some or all of your sensitive data can be leaked ? When an application goes into background a screen shot of the app might get saved to an unencrypted cache on the local file system. Attackers can easily get this screen shot from the local file system which may contain sensitive information. During such cases and if you are dealing with private user data, Apple documentation recommends developers to replace the sensitive information with a blur screen or a splash screen in your applicationDidEnterBackground method.

Alternatively, you can disable allowScreenShot.

Handle the pasteboard securely

If the pasteboard is marked as persistent it may also get saved to local storage along with potentially sensitive user data. So make sure to clear pasteboard when an application goes into background.

Check documentation for UIPasteboardNameGeneral & UIPasteboardNameFind.

Avoid SQL Injection

During using persistent storage it is important to verify that your application is resistant to SQL injection attacks. This will also leak sensitive information from the database or at worse may even inject malicious payloads.

Check for calls to sqlite3_exec() and other non-prepared SQL functions. The functions sqlite3_prepare*() should be used instead.

Vulnerable code:

A more polite way:

Configure Application Transport Security (ATS)

By default, applications linked against iOS 9 cannot create insecure HTTP connections. Review that the ATS configuration is correct and check,

No exceptions are there in the Info.plist.
The list of HTTPS domains in the Info.plist are correct.

In iOS 10, a few more options are available:

For streaming media using AVFoundation
NSAllowsArbitraryLoadsInWebContent for exempting ATS in WKWebView

Use native TLS/SSL securely

SSL should be used on all communications to prevent the attackers from reading or modifying traffic on the network.

All APIs besides local WebViews use SSL (https scheme, no http).
There are no debug options for SSL set in your release build.

Prevent WebView UI redressing

Developer must understand that the WebViews can be used for UI redressing attacks. For example, a full screen WebView which looks similar to your application UI might accidentally let the user input sensitive content. Such WebViews could be used by attackers to do phishing.

I would recommend to disable all protocols other than http and https. Whitelist any individual protocols if required.

Avoid XSS in WebViews

Developer must ensure the UIWebView/WKWebView is properly handling strings because attacks similar to XSS can occur. An XSS in a UIWebView can potentially leak local data, for example the address book. Also make sure that the WebView is not prone to redirection which can be utilized for phishing. Please refer here on how to avoid this.

Data storage practice

A stolen or lost iOS device can be jail-broken or disassembled and the contents of the local file system can be read. Therefore developers need to make sure that they are encrypting any sensitive information like credentials or other private information which are persisted by your application.

The safest scenario would require flagging items as device-only, requiring Touch ID for access, and invalidated if passcode is ever removed. Most of the developers save their data in Preferences, if this is a sensitive information consider encrypting it before it is saved.

More…

For more information check out the Apple iOS Security white paper.