Search code examples
iossecurityurl-schemephishing

Best practices in dealing with the abuse of custom URL scheme to make phishing attack ios

The Scenario:

A web application that once a new user completes the registration, an email will be sent, containing a URL that once tapped from within an iOS device, the iOS app will be launched. This scenario is a classic scenario to make users use the mobile app.

While implementing it (using URL scheme), we start wondering how secured is this method? Theoretically - a malicious app could sign up to the same URL scheme, and according to Apple:

Note: If more than one third-party app registers to handle the same URL scheme, there is currently no process for determining which app will be given that scheme.

Implementing Custom URL Schemes by Apple

In such scenario, if a user is tapping the url inside the email, it is unknown which of the two (or more apps) will be launched - ours or the malicious one. Lets say a different app is being launched - if its really malicious, theoretically it could mimic the login page of our app and grab the user's credentials.

Are there any best practices that handles such scenario? I've read many articles regarding the issue, all of them claims that the only solution is to wait for Apple to make these url schemes unique. example1, example2

I would love hearing about any solution to the issue if exist, Thanks in advance!

Solution

  • We have to assume the malicious app can intercept any data included in this url and that it's author has been free to reverse engineer any behavior included in your app so it can imitate your UI and any validation your app attempts to perform. However we can also assume that the malicious app is contained in its own sandbox so your app can communicate with your backend privately. The malicious app can imitate any such communication but this does allow us to construct a secret unknown to the malicious app. That gives us at least an opportunity to design some countermeasures.

    One option might be:

    1. As part of registration construct a public/private key pair and store it in your app.
    2. Send the public key to your web backend as part of the registration process.
    3. Encode they payload of your URL using that public key.

    Now we've sent data to your app which might be redirected to a malicious app but which the malicious app cannot read. That's a partial solution. We still need to be careful to design a UI which does not encourage a user to fall for a phishing attack since the URL might still launch the imposter.

    The encoded data might be a token we can use to authenticate the user and therefore never require them to re-authenticate within the app. Then there is no login screen to imitate (though a clever forgery might still be enough to trick users into divulging their credentials).

    An alternative might be to use a similar per-user secret stored on the client as a salt to combine with the user's password. Their password alone might then be insufficient to authenticate so a malicious app capturing their credentials is not immediately able to access their account.

    Another design could be to allow the user to customize their experience in a recognizable way. You might show their selected profile image on the sign in screen. If that selection is known only to your app then an imitator shouldn't be able to duplicate it reliably (again, no guarantee that means users will catch the deception).

    All of this introduces tradeoffs; users might still be tricked into revealing information to malicious apps no matter how different they appear from your legitimate client, client side secrets can be extracted by other attacks, and you need a plan to support users who switch, lose, or upgrade devices. You have to decide if any of this actually improves the security of your users and if it is worth the cost to implement.