Yeah, sure I had fun making the Planet of the Apes pun, but this really is the planet of the APIs (application programming interfaces). Want to travel around the earth? You’ll go online to book your trip, and in doing so you’ll be using software that uses APIs. OK, you could call to book your trip, but a customer service representative will use software that uses APIs. Want to go to the moon to escape all of these APIs? Sorry to bring you back down to earth, but there’s no escape. How do you think you’ll order supplies? Yep, at some point APIs will come into use.

APIs, known as application programming interfaces, are ubiquitous. Right now, you are connected to the Internet, maybe using a cable modem, perhaps a router, or some other hardware device to interface with your ISP or employer’s network. Speaking of routers and other IoT devices, the Mirai botnet uses APIs too!

Every one of the 16 critical infrastructure sectors defined by CISA, relies upon APIs for day-to-day operations. And yet API security has never been the topic of any the hundreds of presentations at the thousands security conference presentations I have attended, and I really did listen to some of them.

The lack of general awareness of the need for API security is concerning. Have you ever seen a t-shirt that has both of the words “API” and “security” at RSA, InfoSec, or any security tradeshow for that matter?  Like gravity before Newton, API security doesn’t exist without a t-shirt. There are security vendors who offer API protection products. API security technology is typically a component of web application firewalls (WAFs). In fact, if a WAF isn’t providing API security, it isn’t protecting many web applications. WAFs are not, however, the only products that offer API security; there are many others as well. Of course, that means there’s a need to validate the efficacy of products claiming to provide API security. Guess what SecureIQLab is about to be testing? In addition to measuring efficacy, we correlate multiple metrics to assess the operational efficiency and return on security investment (ROSI). This provides governments and enterprises with information that is required to select products based on empirical evidence.

API Insecurity

API security awareness is increasing and will do so at a rapid rate. APIs are arguably what supply chain runs on. What could possibly go right wrong with that? Companies use APIs to communicate and exchange data with one another every second of every day. They who control the APIs, control the flow and content of data, and all the systems that are controlled by  the APIs. Yes, APIs are the building blocks of supply chain… I think you get the point.

Attacks Against APIs

OWASP has an API Security Top 10 list, as well as some great resources for testing and securing APIs. In fact, rather than link to the OWASP 10 ten. I’ll do your search for you. https://owasp.org/search/?searchString=api+security

What is the most porous attack surface any organization has? Yeah, the end user (EU). But that is really far too simplistic. Take the endpoint away from the end user and the endpoint is not vulnerable to the end user vulnerability. But what if we can automate the end user insecurity? How? APIs!!! Yes, insecure APIs are a serious threat. Two of the top ten API Security issues are Broken Object Level Authorization, and Broken User Authentication. Why phish the user for credentials when you can “be” the user? As opposed to broken user authentication, broken object level authorization is an endpoint security issue that isn’t the end user’s fault but is a common endpoint API issue.  When it comes to APIs, the endpoint can be a very porous attack surface.

Excessive Data Exposure. APIs consume and provide information to objects. These objects can contain sensitive information that should not be exposed. Many large companies have a secure by design lifecycle (SDL) that should identify and prevent excessive data exposure, but many companies do not. How many IT departments developing in-house APIs have training in API security? Food for thought. Excessive data exposure includes cute little things like social security numbers, addresses, phone numbers, and employee best if used by dates. The kind of stuff that allows attorneys to afford the best schools for their children as a result of data breaches caused by API insecurity. There is a silver lining. I haven’t had to buy identity theft insurance for a decade, and I’m all set for the next three years too.

Lack of Resources and Rate Limiting: Essentially, exploitation of these security issues facility DDoS attacks and credential stuffing.

Broken Function Level Authorization: Conceptually, we’re talking about privilege escalation.

Mass Assignment: Ignoring the how’s and what’s, the effect is that object properties can be modified in manners that make attackers smile. When an attacker smiles, you don’t.

Security Misconfiguration: What can I say about this that isn’t documented on three floors of books in the library of congress? These problems range from insecure default settings to unsecured cloud storage, to error messages that expose useful information for attacker reconnaissance.

Injection: API injection is the sequel to SQL injection. If you break into the API data stream, you end up with the same types of issues encountered with SQL injection attacks, command injection attacks, and so forth.

Improper Assets Management: That sounds a bit like Shadow IT. You can’t protect what you can’t manage. Deprecated APIs can pose the same threats as vulnerabilities in unpatched programs. Many companies use vulnerability scanners to identify vulnerable applications as well as vulnerable shared resources such as public DLLs. Asset hygiene is important, but you have to inventory and secure the assets.

Insufficient Logging and Monitoring: Logs must contain enough data for anomaly detection and to enable forensics. But, even the most comprehensive logs, like a tree in the forest, will fall without making a sound if they are not monitored. Oh yeah, do you use APIs to collect and monitor log data?

In our upcoming API security testing SecureIQLab will be putting API security solutions to the test to enable quality data-driven decision making for the public. But there’s something else we do for you. In testing these products, we provide information to the vendors to help them improve their offerings. In a best-case scenario, things like price, user expereince, and service should be the differentiators of security products. Until security efficacy is no longer a differentiator, we’ll keep breaking things so that they don’t break you!

Stay tuned for the results of our API Security Test coming to you via download API soon! In the meantime, our very own David Ellis discusses Testing Cybersecurity Solutions on the SecureIQLab Reining In The Cloud Podcast.

Randy Abrams
Senior Security Analyst
SecureIQLab