9

I am building an Apple iOS application that will have the following flow:

  1. A user completes registration from the web.
  2. Upon completion of registration, a link is sent to his email.
  3. Once the link is clicked on an iOS device, my iOS app will be launched and will prompt the user for credentials.

The thing is another malicious app can register to the same URL scheme as my app. In such a situation, the malicious app can be launched instead of my legitimate app, and easily steal the credentials of my users.

What can I do prevent data leakage in this situation? (i.e. make sure that the malicious app cannot imitate my app and/or implement a mechanism that will enable users to easily differentiate between my app and the malicious app)

I've seen some answers here: https://stackoverflow.com/questions/30461145/best-practices-in-dealing-with-the-abuse-of-custom-url-scheme-to-make-phishing-a

But all of them propose implementing a mechanism that will eventually enable the malicious application to completely imitate my application.

Community
  • 1
user3074662
  • 541
  • 2
  • 6
  • 11
  • 3
    Anything you put in your app can be duplicated by a malicious app, in this case you would rely on Apple not allowing a fake app. Another approach you CAN take is to let some action be initiated in the real app to establish secret credentials with the server, which the app would need to have once invoked via URL. – Natanael May 31 '15 at 12:19
  • You can use App Transport security. It is IOS 9 feature and provides unique bundle id mechanism for apps –  Nov 06 '15 at 08:39

1 Answers1

1

Before giving any solution, it is important to remember that, if an app is being installed on a user's device, then given time and dedication, a malicious user can replicate/reverse engineer the app. That said, there are certain techniques which can be used to make the job of reverse engineering the app difficult and eventually replicating the app difficult. Some of the techniques can be:

  • For every request a secret value can be sent, this secret value can be a hash of concatenated strings of (password + current time + domain + a constant string) etc. Any such scheme can be created, but make sure the code is obfuscated enough so that it is hard for the attacker to break. By frequently altering this algorithm, malicious app need to also do that to keep up.

  • Secondly, you can include anti-debugging checks like having ptrace with PT_DENY_ATTACH call or using sysctl approach. But again a determined and skilled attacker can circumvent these checks. These checks can be disabled by altering the app binary. But by having frequent hash checks of the binary can make the job of attacker further difficult.

  • Use of SSL pinning can also protect against some script kiddies from looking at network traffic, but tools like SSL KillSwitch makes bypassing this check trivial.

Jor-el
  • 2,061
  • 17
  • 24