How a Trusted Client Hides API Vulnerability?
A Case for Service Side Monitoring/Testing
A critical vulnerability in Apple “Sign Me In” feature was reported last week (Reference) that would allow a bad actor to first login through the Apple Client using their own credentials, then abuse the same login session to request a JSON Web Token (JWT) of a different user, thus allowing such bad actor to use the issued JWT token to gain unauthorized access to a victim’s account
This is obviously an example of the top Broken Object Level Authorization (BOLA) issue of the OWASP API Security Top 10 (https://owasp.org/www-project-api-security/). At first glance, it might be yet another reminder that risk to private data is real when APIs have become the primary method of accessing such data. Unlike many other API related massive data breach incidents, it was a whitehat researcher who found and reported the vulnerability before it was exploited. This begs the question: “What can be done to better discover these kinds of vulnerabilities?” Is there anything special about APIs that make their vulnerabilities harder to be found?
Counterintuitive as it might seem, a trusted client to an API service often hides API vulnerabilities. For example, consider the Apple vulnerability referenced above; the vulnerable APIs are supposed to be used only by a trusted Apple Client, which dutifully validates the user and uses the login user’s Apple ID as an input parameter when making the call to obtain a JWT. The vulnerability is not exposed simply because the trusted client is expected to do the right thing: calling the API with the Apple ID matching that of the user it validates. What it does not prevent, is a bad actor logging in with one’s own credential, then substituting the Apple ID with a victim’s Apple ID when making a call to exploit the vulnerable API.
Without the benefit of hindsight, most of the client side application security testing might not be able to capture such vulnerabilities either. A client side API security testing/scanning tool typically uses a browser plug-in or a client side proxy (sometimes it is a proxy in the cloud) to capture API calls made by a client. It then replaces data fields of those calls with some predefined patterns emulating certain known attacks (e.g. an injection attack) through a process known as “fuzzing”. In this example, the vulnerable Apple authentication server does validate to ensure input Apple ID is a valid one. Therefore, it is highly unlikely a fuzzed ID replacement would be successful in reviewing the bug.
A service side monitoring/testing can be much more effective in discovering/detecting such anomalies. The key difference from a client side test/capturing tool is that a service side monitor sees all API calls against a service. As all normal clients would login and obtain an Apple ID matching the login user, the Apple ID exchanged as input/output within a login session should remain constant — something we call a pinning effect. It will then appear to a service monitor an obvious anomaly when a bad actor switches the Apple ID input after login.
It should be quite obvious that when an application APIs are to be abused, the bad actor is not going to be limited by a trusted client. Therefore, we should not limit ourselves to just client side security testing/monitoring when it comes to API Threat Protection.