Guidance on Security Finding for MSAL iOS Redirect URI Using Custom URL Scheme

Question

Guidance on Security Finding for MSAL iOS Redirect URI Using Custom URL Scheme

Kumar, Pavan 0

Hello Microsoft Team,

We are using the MSAL iOS SDK for SSO authentication in our iOS application.

As part of the MSAL implementation guidance, we have configured the redirect URI using the recommended URL scheme format:
https://learn.microsoft.com/en-us/entra/msal/objc/redirect-uris-ios

but we have reports from security scans for using URL schemas, and suggested to use universal links. but seems MSAL sdk does support that today, please suggest.

Below are the details of security findings
App Uses Custom URL Schemes Registered Which Are Susceptible to Hijacking
Description

The app defines some custom URL schemes.

Custom URL schemes can potentially be registered by other apps to intercept or 'hijack' URLs that use the custom scheme. This means that an app on the same device that registers the same custom scheme may be launched to handle URLs instead of the intended application. Any sensitive data contained in those URLs would be sent to the imposter instead.

Evaluation Criteria:

To determine exploitability of a custom URL scheme in iOS, there are several options:

Check the supported schemes in the Info.plist file. You can then dump strings from the app binary and search for any hardcoded URLs that match.

Also grep all the .ipa assets for the schemes - they will sometimes be embedded in JavaScript or JSON files loaded by the app.

Use frida-trace to hook the URL scheme handlers and log any incoming URLs while you exercise the app.

If the app is written in Objective-C it can be helpful to use r2 to examine the handlers used by the app to figure out the logic used to route incoming URLs.

Once a list of URLs is captured, try to load all of them and observe the app's behavior. Then you can get creative and do things like try to fuzz parts of the URL or any parameters passed to it. Any of these actions can be performed by other apps, so anything that exposes sensitive functionality or data should be considered vulnerable.

Testing Method

This test statically examines the app's Info.plist file looking for registered custom URLs, under the CFBundleURLTypes key.

Business Impact

The app is defining custom links that can be accessed by other apps on the device, which can expose sensitive information to those apps.

Recommended Fix

The best remediation for custom URLs is not to use them, and instead implement Universal Links.

If that is not possible, Apple recommends that all parameters are validated and any malformed URLs should be immediately discarded, In addition, limit the available actions to those that don't risk the user's data. For example, don't allow other apps to directly delete content or access sensitive information about the user. When testing your URL-handling code, make sure your test cases include improperly formatted URLs.

0 comments

1 answer

Your answer

Answer 1

MSAL for iOS does support universal links as a redirect URI.

Key points:

The default and recommended MSAL redirect URI format for most apps is msauth.[Your_Bundle_Id]://auth.
That default format is used for most scenarios, including brokered authentication and system web view.
If universal links are used as the redirect URI, the scheme must be https.
For universal links, the scheme does not need to be declared in CFBundleURLSchemes. Instead, the app and domain must be configured per Apple’s universal link requirements.
The app must still call MSALPublicClientApplication.handleMSALResponse when opened through the universal link.

For the security finding, the supported position from the documentation is:

Custom URL schemes are the default MSAL approach and are the recommended format for most apps.
Universal links are supported by MSAL for cases where a different redirect URI is needed.
If the goal is to reduce the risk associated with custom URL scheme collisions, moving to an https universal link redirect URI is the MSAL-supported option.

Implementation guidance:

If brokered authentication with Microsoft Authenticator is required, the documented broker-compatible redirect URI format is msauth.<app.bundle.id>://auth, and the app should add msauthv2 and msauthv3 under LSApplicationQueriesSchemes.
If switching to universal links, configure the redirect URI as https://..., configure the app/domain for universal links, and keep the MSAL callback handling in the app entry point.
If a custom redirect URI is supplied to MSAL, pass it in MSALPublicClientApplicationConfig. MSAL validates the redirect URI during initialization and returns an error if it is invalid.

Swift example for a custom redirect URI configuration:

let config = MSALPublicClientApplicationConfig(clientId: "your-client-id",
                                            redirectUri: "your-redirect-uri",
                                              authority: authority)
do {
  let application = try MSALPublicClientApplication(configuration: config)
} catch let error as NSError {
}

Swift callback handling:

func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
    return MSALPublicClientApplication.handleMSALResponse(url, sourceApplication: options[UIApplication.OpenURLOptionsKey.sourceApplication] as? String)
}

Practical conclusion:

The scan finding is valid as a general iOS custom-scheme concern.
MSAL does not require staying on custom URL schemes only.
Universal links are supported by MSAL on iOS/macOS and are the appropriate MSAL-supported alternative when the security review requires avoiding custom URL schemes.
If broker-based SSO with Microsoft Authenticator is a requirement, the documented broker flow uses the msauth.<bundle id>://auth redirect format.