The original version of this post was published in Forbes.
It’s obvious that just about every entity with an online presence thinks APIs (application programming interfaces) are pretty cool—and necessary.
A survey by One Poll found that organizations manage an average of 363 different APIs, with 69% of organizations making those APIs accessible not just to their partners but to the public as well.
For good reason. As a description in TechCrunch put it, APIs provide “critical connective tissue and increasingly important functionality” among software components. That includes rules about how different parts of online applications such as databases and webpages should interact with one another.
Unfortunately, cyber criminals think they’re pretty cool too. Because misconfigured or otherwise vulnerable APIs can amount to the digital version of unlocked doors or broken windows, making just about every “room” in the house available.
Again TechCrunch: “APIs are an attractive target for threat actors because they act as the glue linking different services—they allow data to flow freely from one area to the next, and thus provide a rich vein of information if they are compromised.”
API attacks on the rise
Jesse Victors, security consultant at Synopsys, said he has seen multiple instances where “an API allows users to log in and authenticate themselves, but doesn’t perform any authorization checks beyond that point. As a result, someone can retrieve information belonging to another user—a privilege escalation.”
That is not a technical problem with the API itself, he said, “but rather an implementation failure to secure it against common and well-known types of attacks.”
There are an alarming number of recent examples.
Just a few weeks ago, security blogger Brian Krebs reported that the U.S. Postal Service had allowed an API weakness that exposed account details for about 60 million users to go unpatched for more than a year after it had been notified about it by a security researcher. The researcher, who wanted to remain anonymous, got so frustrated he eventually contacted Krebs.
Krebs verified the vulnerability, which he said “let any logged-in usps.com user query the system for account details belonging to any other users, such as email address, username, user ID, account number, street address, phone number, authorized users, mailing campaign data and other information.”
Once Krebs contacted the USPS, the agency fixed the problem, saying in an emailed statement to Threatpost that “the information shared with the Postal Service allowed us to quickly mitigate this vulnerability.”
Quickly—after more than a year of ignoring it.
Unfortunately, the USPS is not alone. The list of high-profile companies that exposed information on customers due to API problems in just the last few months includes online retail giant Amazon, telecom T-Mobile, food retailer Panera Bread, and the Black Hat security conference, where an attendee hacked his own badge and demonstrated that he could access the data of everybody else who had attended, thanks to a “legacy” (i.e., leaky) API used by the BCard maker, ITN International.
Are APIs inherently unsecure?
Does this make APIs the new “weakest link in the security chain”?
Not necessarily. Part of the problem is that there are more—a lot more—of them to secure. “As technologies shift to single-purpose microservices, we are seeing more and more APIs to facilitate that communication, and thus there are more APIs and implementation to configure and secure,” Victors said.
Andrew van der Stock, senior principal consultant at Synopsys, added, “The attack surface is greater simply because of the greater demand for B2B connectivity. The information was always there, but difficult to get at. APIs make the friction of doing business much less, so we expect to see explosive growth of APIs—the business need is just too great to stopper this genie.”
And Chris Schmidt, senior staff research engineer at Synopsys, said APIs are no weaker than any other component of application development, but have become a more popular target because many were designed to support functionality internally and were therefore protected by “upstream” security controls. But when they are exposed as public, “those controls are no longer present.”
Also, based on recent events, they are probably among the most ignored of security chain links. Nicholas Weaver, researcher at the International Computer Science Institute and lecturer at University of California, Berkeley, told Krebs that implementing access controls is “not even Information Security 101, this is Information Security 1,” and that the failure of the USPS and others to do so was “catastrophically bad.”
Indeed, multiple experts have noted that APIs should enforce both authentication (Who are you?) and authorization (Should you have access to this?) for every request.
Which means that buried in all this bad news is good news: This is a problem that can be fixed, by deploying APIs correctly and with better security testing. Doing the basics, in other words.
How to prevent unsecure APIs
Van der Stock said the security industry needs to “shift left”—start security testing early and continue throughout the development process.
“They need to adopt the same tooling as developers and write the sort of tests that fully exercise APIs, particularly those that have the potential to extract bulk personal information,” he said.
Victors added that engineers building an API, a protocol, or any other structure should “take the time to consider how their application handles unusual requests. A good place to start would be the 2017 OWASP Top 10, which lists and describes the most common application risks and is based on an industry analysis of more than 100,000 real-world applications.”
Indeed, Victors said the flaw in the USPS API is known as “broken access control” in the industry “and ranks as No. 4 in the OWASP Top 10 list. It can be identified in multiple ways—tested with static or dynamic application security testing (SAST or DAST) tools.”
And Schmidt said it is important to note that these problems are design flaws. “There’s no specific bug in the code—the APIs do exactly what they were designed to do, but the lack of proper design around mitigating controls and authorization for operations will continue to plague APIs,” he said.
API security starts with the basics
Bottom line: While nothing can make an organization bulletproof, most of these recent incidents could have been prevented—note how “quickly” the USPS fixed its API when it finally decided to do so.
Victors said while the API attack surface has grown in recent years, “the industry has responded with better and better tools for setting up firewall restrictions, access control, and authentication. It is simply a matter of applying them.”
Which ought to be automatic. Because the inevitable results of not fixing them are not pretty. Breaches can be legal disasters, PR nightmares, and, with laws like the EU’s General Data Protection Regulation (GDPR), very expensive.
“It’s worth the investment to take measures to avoid them,” Victors said.
*** This is a Security Bloggers Network syndicated blog from Software Integrity authored by Taylor Armerding. Read the original post at: https://www.synopsys.com/blogs/software-security/api-security/