A Case For Securing API Actions. What Words Of Wisdom Two Thousand Years Ago Can Teach Us About APP Security
Confucius taught us more than 2000 years ago: “Listen to his claims, but watch his actions.” Things are not what they claim to be. Such words of wisdom speak volume in light of the most recent Facebook access token leak.
According to one of Facebook’s blog, a large number of access tokens were potentially stolen by hackers due to vulnerabilities in the “View As” feature. Facebook executives offered more details according to this TechCrunch report. There are three key take-aways:
- The vulnerability seemed to be introduced in 2017, but it was only discovered a few days ago—more than a year later—when services are used to implement other features.
- “The attackers used our APIs to access profile information fields like name, gender, hometown, etc. But we do not yet know if any private information was accessed that way,” Facebook CEO Zuckerberg said.
- Access tokens stolen affect other services relying on Facebook as a trusted source of user identity.
While all vulnerabilities can be traced back to some implementation bugs or mistakes in implementation, we can all agree that bugs happen. Worse, vulnerabilities resulted from bugs can lay undetected for an extended period of time. As it is important to seek improvement in secure implementation practice, it would be equally prudent to find ways to improve detection should the rare but unavoidable bugs happen.
An access token is sometimes called a “claim” of certain permission granted by a trusted party to perform certain actions. In Facebook’s case, the access token is key to APIs of services owned by Facebook or other “relying party” services. Standard practice of API security would simply allow an API invocation after validating the access token. Such API calls are sometimes logged by the service provider, but these logs are kept inside individual providers. These call logs are mainly kept for debugging purposes. They lack context information (such as caller user ID, caller location information, etc.) and are rarely shared.
There is only one purpose for attackers to steal access tokens: to get to private information via APIs. Proactively tracking API actions, while not a method to prevent access tokens from being stolen, can help us first detect any anomalous actions using stolen tokens, but more importantly, prevent compromised access tokens from being used to steal valuable information.
Monitoring, correlating, and eventually enforcing policies against API actions should not be left to individual programmers whose job and skill set are to implement the API functions themselves. The API security layer should be part of the infrastructure. It should not impact the development or deployment of an application. It should also be pervasive, covering all application infrastructure: traditional web service, containerized micro-services, message oriented architecture, edge computing, you name it.
In summary, lessons learned from the most recent event and Confucius’ teaching more than 2000 years ago all pointed to the importance of tracking actions. A caller should not be automatically trusted simply based on what s/he or a 3rd party claims what his/her role to be. We should watch for his actions.