Exposed Sensitive IOS Url Scheme
Exposed Sensitive iOS URL Scheme
Overview of the Vulnerability
A URL Scheme helps facilitate the transfer of a limited amount of data between iOS applications on Apple mobile devices. iOS applications operate in separate sandboxes to limit the access and transfer of data between applications. However, it is possible to perform an App-in-the-Middle (AitM) attack where a malicious application sends a manipulated URL Scheme to trick a legitimate application into sharing a user’s sensitive data, bypassing access controls of the legitimate application.
The application has an exposed sensitive iOS URL Scheme, which an attacker can take advantage of to perform an AitM attack, bypass the access controls of the application, and gather sensitive user data. This data could be used to perform further attacks on the application, the business, or its users, including account takeover.
Business Impact
This vulnerability can lead to reputational damage and indirect financial loss to the company through the impact to customers’ trust. The severity of the impact to the business is dependent on the sensitivity of the accessible data being transmitted by the application.
Steps to Reproduce
Enable a HTTP interception proxy, such as Burp Suite or OWASP ZAP
Use a browser to navigate to: {{URL}}
Login to an account that should not be able to perform {{action}}
Forward the following request to the endpoint:
{{request}}Observe that the account now has additional user functionality and access to data it was previously not authorized to access
Proof of Concept (PoC)
The screenshot below demonstrates the broken access control:
{{screenshot}}
Recommendation(s)
Broken access controls can be remediated by implementing a handful of best practices relating to authentication and session management to ensure secure implementation. These include:
Ensuring that access controls are designed thoroughly upfront and that each request goes through some form of access control check. By default, specific requests that are not explicitly allowed should be denied.
All users, programs and processes should follow the principle of least privilege and only be given as little access as possible in order to complete their business functions.
An application’s code should not contain any hardcoded roles as these can become fragile and difficult to enforce and audit.
For more information, refer to the following resources:
Last updated