This is seventh part of ProgrammableWeb’s series on Understanding the Realities of API Security. It is based on the testimony offered by ProgrammableWeb’s editor-in-chief David Berlind to the ONC’s API Security and Privacy Task Force. In the previous part -- Part 6 -- Berlind answers the following question posed by the ONC: How Many Production Deployments Exist of APIs and Third Party Apps?
The first thing to consider when answering this question is how APIs are, in some ways, gaining a reputation for becoming a wonder drug of the type that the Web was in the mid-90’s.
Back in the mid-90s, as the World Wide Web caught-on --- thanks in a large part to the tech and mainstream media --- as means for businesses to very cost-efficiently communicate with their customers, it wasn’t long before every business was racing to attach one or more Web sites to the Web. Soon, it was inconceivable that a business could exist without also hanging its shingle on the Web. Today, APIs are the new Web. And thanks to the way the tech and mainstream media are painting a picture of APIs as the new must-have in order to not only conduct, but to reinvent business for participation in the new economy, businesses are once again racing to PUT API technology into production (and rightfully so in a great many cases). As the virtues of APIs are extolled in business media such as Forbes and Fortune, CEOs are scrambling their IT teams to beat the competition to the API-punch.
However, while there is no shortage of information about this API gold rush that’s not to be missed, there is a distinct lack of information about the security and privacy risks that go with APIs and the degree to which a so-called “rush-job” could endanger the same digital assets that the API was meant to leverage.
I want to be clear here; every digital technology that the human race has found to be both promising and useful has also come with its risks. No such technology has proven to be infallible. But we, as people, very often come to the conclusion (one that I agree with), that the efficacy of the technology greatly outweighs the risks associated with using it. I believe this to be the case with APIs, or I wouldn’t be here at this hearing, or in this job as the editor in chief of ProgrammableWeb.
That being said, as thousands of companies rush to put their APIs on the Web, very few if any fully appreciate the difficulty in securing them. In other words, the widely-perceived state of API security reflects a belief that if you rely on well-known Internet, Web, and API security standards to provision your API, then your API will be secure. However, in practice, this dangerous assumption has not borne out to be true and here are some reasons and real-world examples why:
- Since 2014, many of the biggest Internet companies on the planet -- the ones with nearly unlimited financial resources to devote to API security (in other words, they can employ the very best experts) -- have either fallen prey to, or discovered a major API vulnerability in their API(s). This includes companies like Google, Apple, Facebook, Pinterest, and Snapchat. In the last month alone, both Trend Micro (a company devoted to security) and Verizon were the latest companies to have experienced highly publicized API security challenges. In my opinion, security oversights and/or an API design flaws were major contributors to all of the vulnerabilities. In other words, “human error.” This begs a very important question: If these companies, with the deepest pockets to employ the best experts, are experiencing challenges in securing their APIs, how can less resourced organizations be expected to do the same? This question matters mostly when API security is a forethought, long before anyone sits down to design an API. In a great many cases, API security is an afterthought.
- When mobile applications are in use -- which involves a great many API cases -- the majority of the API secrets that are (a) shared between the mobile application and the API and (2) presumed necessary to secure the API and any communications with it, are easily discoverable even when standard security technologies like HTTPS are thought to have secured those communications. Not only are there are a variety of methods to expose these secrets, there are a variety freely downloadable tools -- even ones that we can download to our smartphones -- that require almost no expertise to operate. The only topic I currently speak about publicly (at conferences, etc.) is API security. During these talks, I show examples of how easily this is done.
- One of the most promising aspects of APIs is how they scale. APIs make it possible for one application to repeat its instructions to another application with extraordinary speed. As such, APIs are ready made for hackers looking to do a lot of damage in a short period of time; which is invariably their M.O. The pupils in hackers’ eyes swell at the sight of potentially exploitable APIs.
- Depending on the importance of the objective, most successful real-world API exploits involved a very multi-dimensional attack that is very difficult to defend against. For example, in October 2014, when hackers stole the security tokens (known as OAuth tokens) that it made it possible for them to impersonate thousands of Twitter and Facebook users, the attack involved phishing attacks on two separate companies, the unauthorized access of a Github source Code Repository, the penetration and subsequent “screen-scraping” of a customer support application, and then finally thousands of unauthorized Twitter and Facebook posts (whose links very likely infected users who clicked them with malware). The damage was done before any of the involved parties knew what hit them. In other words, the juicier the carrot, the more sophisticated the series of orchestrated exploits to GET to it. Hackers will literally stop at nothing and are usually doing this while multiple vulnerabilities are left unguarded.
- API security, like many forms of security, is a cat and mouse game. Just when you think you’ve got a security scheme that will keep the bad guys out, they find another way in (which invariably sends everyone back to the drawing board to close that loophole). Case in point? In the aforementioned October 2014 attack, the hackers gained unauthorized access to Oauth tokens that in turn allowed them to impersonate the end users that those tokens represented. In recent months, the Internet Engineering Task Force (IETF) has been moving quickly to ratify the necessary security standards that will require a program to prove that it has the right to use an Oauth token on behalf of some user. This is called “proof of possession” or “POP.” Had this standard been baked into commonly used API software configurations prior to October 2014, it might have prevented the aforementioned attack. This issue also speaks to the lag time between the ratification of new security standards and the time it takes for those standards to take root in the solutions that API providers use to manage and secure their APIs.
In the next part -- Part 8 -- of ProgrammableWeb’s series on Understanding the Realities of API Security, ProgrammableWeb editor in chief David Berlind answers the following question posed by the ONC: How Can API Risks and Vulnerabilities Be Mitigated?