Adversaries may register Uniform Resource Identifiers (URIs) to intercept sensitive data.
Applications regularly register URIs with the operating system to act as a response handler for various actions, such as logging into an app using an external account via single sign-on. This allows redirections to that specific URI to be intercepted by the application. If a malicious application were to register for a URI that was already in use by a genuine application, the malicious application may be able to intercept data intended for the genuine application or perform a phishing attack against the genuine application. Intercepted data may include OAuth authorization codes or tokens that could be used by the malicious application to gain access to resources.[1][2]
| ID | Mitigation | Description |
|---|---|---|
| M1013 | Application Developer Guidance |
Developers should use Android App Links[3] and iOS Universal Links[4] to provide a secure binding between URIs and applications, preventing malicious applications from intercepting redirections. Additionally, for OAuth use cases, PKCE[2] should be used to prevent use of stolen authorization codes. |
| M1005 | Application Vetting |
When vetting applications for potential security weaknesses, the vetting process could look for insecure use of intents. Developers should be encouraged to use techniques to ensure that the intent can only be sent to an appropriate destination (e.g., use explicit rather than implicit intents, permission checking, checking of the destination app's signing certificate, or the App Links feature added in Android 6.0). For mobile applications using OAuth, encourage use of best practice.[5][6] |
| M1006 | Use Recent OS Version |
iOS 11 introduced a first-come-first-served principle for URIs, allowing only the prior installed app to be launched via the URI.[1] |
On Android, users may be presented with a popup to select the appropriate application to open the URI in. If the user sees an application they do not recognize, they can remove it.