New SNAFUs Illustrate Scope of API Security Challenge and Hacker Tenacity

Though it's hard to imagine anything rising above the noise coming out of Washington, DC this week, the InterWebs have managed to surface two separate issues that further illustrate several of the important realities of API security. To be clear, API security is very hard. There are a multitude of layers to the so-called API "stack" (eg: the API endpoint itself, the applications that access the API, the network between them, etc.) some of which overlap the layers of an organization's basic IT stack.

All of these layers require the attention of personnel who are experts in securing them. Furthermore, one area that is severely neglected by most API providers has to do with educating their API consumers (the developers) on how to build secure applications. This isn't just about learning how to properly interact with an API's OAuth configuration for authentication. If API provider's don't take an active role in educating developers on how to build secure apps, then the application layer of the Internet -- the front line of defense to APIs -- will end up largely compromised and vulenerable to hackers with nefarious intent. 

The two issues that surfaced on ProgrammableWeb's radar this week that are worthy of the attention from IT and API security folks have to do with how APIs can be reverse engineered to compromise the privacy of your customers and how one of those aforementioned layers that can't be ignored has to do with the software development kits (the SDKs) that API providers offer to make developers more productive in their favorite languages. In the case of the latter, which involved a PHP SDK, it's just more evidence of a point that I keep making whenever I present on API security: this stuff is so hard that even the biggest companies with the deepest pockets to hire the best talent make mistakes. 

The first incident however has to do with the interactions between a tenacious (and thankfully good-intentioned) hacker who used a tool we've written about before -- MITMproxy -- to run a man-in-the-middle attack on an application from his insurance company.  MITMproxy makes it possible to intercept and decrypt application-specific network traffic that is thought to be secure which in turn makes it possible to reverse engineer the contracts of any APIs in use which, in turn, as you'll see if you read the article, can eventually lead to a compromise to the privacy of the application provider's customers. 

The article -- How my car insurance exposed my position -- was written by Andrea Scarpino and its headline doesn't quite capture the gravity of the vulnerability he was so tenacious in uncovering. After all, based on what he wrote -- that you only need the license plate of a car that's covered by the insurance company in order to retrieve "all the travels made by that car, the full name of the person owning it and its position in real time" -- the level of potential customer exposure is pretty frightening. 

Then, from seclists.org comes news of a cross-site scripting (XSS) vulnerability in the beta version of a PHP SDK from Google that's designed to work with Google+, Google Drive and YouTube.  According to seclists.org, 

ThunderScan SAST discovered Cross Site Scripting vulnerability in Google's PHP client library for accessing Google APIs (google-api-php-client). The vulnerabilities were found in the sample code for using the Google's URL Shortener.

The Cross-Site Scripting vulnerability can enable the attacker to construct the URL that contains malicious JavaScript code. If the administrator of the site makes a request to such an URL, the attacker's code will be executed, with unrestricted access to the site in question. The attacker can entice the administrator to visit the URL in various ways, including sending the URL by email, posting it as a part of the comment on the vulnerable site or another forum.

In other words, in order for this vulnerability to work, there are several prerequisites. It requires catching a human off-guard with something like a phishing attack in which they click on a malicious link. That human needs to have administrative rights to a server. And lastly, that server has to be hosting a PHP application that relies on the beta PHP SDK from Google. While all of that sounds like a fairly credible barrier to a compromise, we need to keep in mind that, to hackers, there's pretty much no such thing as a credible barrier (as somewhat evidenced by our friend Andrea who persisted until he cracked the code of his insurance company).  Furthermore, if you think the complexity of the vulnerability seems a little too far fetched -- for example, the idea of a sysadmin being successfully phished -- think again. A few years back when Buffer suffered a major attack that turned into a security compromise for Twitter and Facebook, the post-incursion investigation revealed a strong likelihood that several key stakeholders (developers and support personnel) were successfully phished for access to secure resources. 

Thankfully, again, the hackers were "white-hatters" (well-intentioned hackers) that notified Google of the vulnerability. But this inicident is a stark reminder that your company could be the biggest internet company in the world -- one that has nearly infinite financial resources to invest in digital security -- and somehow, your API solutions will never be bulletproof.  Knowing that, there is no excuse for a lackadaisical attitude towards API security. An API-security first mindset and constant vigilance are imperative.  

David Berlind is the editor-in-chief of ProgrammableWeb.com. You can reach him at david.berlind@programmableweb.com. Connect to David on Twitter at @dberlind or on LinkedIn, put him in a Google+ circle, or friend him on Facebook.

Comments