The Rise in API Data Breaches

Protect against cyber attacks that exploit Application Programming Interfaces (API) vulnerabilities.

Cyber attacks and data breaches involving poorly protected Application Programming Interfaces (APIs) are rapidly increasing. In 2018, organizations such as high-profile food chains and software as a service (SaaS) providers had their APIs exposed to data breach. There is no-plug-and play solution to preventing data breaches. The Spectre, Meltdown, ShellShock and Heartbleed data breaches represented different types of attacks: man-in-the-middle attacks, session cookie tampering and distributed denial of service attacks. The rise in API data breaches means traditional application security is no longer enough to protect organizations and their data.

APIs are being added and consumed by organizations on a regular basis, making solutions to these data breaches more complex. With today's modern application architecture trends — including mobile devices, microservice design patterns and hybrid on-premises/cloud usage — API security is complicated, and there is rarely a single "gateway" at which protection can be enforced.

To provide context on the level of vulnerabilities, we recently conducted assessments of different organizations to gather further insight on API and data breaches.

Vulnerabilities exist across industries

In a recent API study for a global pharmaceutical company, the results found the ability to identify sensitive information on API response message and returned various details such as uptime, server version and framework in the header and bodies of the responses. Though no further vulnerabilities were found with this data, it could be used to plan further attacks on the application and infrastructure. By allowing system uptime as a valid response, attackers can see how long a system has been operating and determine if a software version has been patched. We also discovered that in certain error messages, the server version was identified in the page.

We recently completed another scenario with a Fortune 100 manufacturer, where we were to observe the device's network traffic through a proxy and determine whether or not SSL was implemented. In this case, data was encrypted to the site dashboard and the API. We found that if a request to the API was sent using HTTP, the unauthenticated session ID cookie was also sent unencrypted. Though not much information can be obtained with the unauthenticated session ID cookie, if an attacker were able to perform a man-in-the-middle attack and could force the user to send nonencrypted traffic, they could obtain authenticated cookies and other sensitive information from the company.

For a multinational corporation, we had an objective to identify sensitive information or any supplemental data that could be used to further attack the API and dashboard website. WWT manually walked through and fuzzed various parameters and data input areas of the API endpoints and dashboard website. Responses were checked and validated to ensure that proper error messages were provided and that no sensitive data was received by sending non-valid data. Various requests were sent to the API and dashboard website. Data returned in error messages and response headers allowed WWT to view API uptime, web server type and version and application framework. Attackers can determine if systems are patched for certain vulnerabilities when this information is viewable. This can give an attacker more information about the system to enable further information collection to plan an attack.

The last scenario involved a global retailer that wanted us to identify end-to-end encryption on the application layer. We found that with the API, it was possible to force the use of HTTP, which in turn, could be redirected to use HTTPS. The only issue with this was that the cookie session ID was sent in the HTTP request, making it possible for an attacker to perform a man-in-the-middle attack and force the user to send a request in plain text. The attacker could then preform the data breach and obtain the cookie and other sensitive information.

These are just a few examples of what is in hackers' minds as they try to breach APIs.

How to secure those APIs

The steps to secure those APIs is a journey, not a sprint, which requires patience and discipline. The first step is to discover and assess the organization's APIs to ensure they are covered by an overall web application security architecture. It is impossible to secure what you cannot find or categorize. Initial interviews with key API stakeholders when developing new security policies will allow for input from everyone.

One stakeholder should be the API product manager who might have input on making sure that the business functionality provided by the API is not compromised. It is important to talk to the developers and architects who can check that API security will not block or excessively slow down application delivery. Talk with operations, including IT, network and security operations. They will want to monitor API access and secure incoming calls. Next, seek out the identity architect, as they want to ensure that APIs support key identity standards such as OAuth 2.0 and OpenID Connect. Security architects and risk management are important to see risk-driven prioritization of API security. Last but not least, fraud prevention leaders will want to nail down protection from fraudulent activities that might result in reputation or financial loss. When your interviews and polices are complete, you will want to adopt a continuous approach to API security.

Simple next steps

After these assessments and interviews are complete, start with some basics:

1. Maintaining an inventory of your APIs, starting with externally exposed APIs
2. Develop API security policies — including authentication and authorization of API users, traffic management and content threat detection
3. Evaluate an API management gateway (there are many providers of API gateways and microgateway solutions) as the go-to technology
4. Evaluate existing platform vendors to determine how they can contribute
5. Remove or tokenize sensitive data in API URL path
6. Take a capabilities view of API security before implementing it in infrastructure such as API gateways

To start a conversation on preventing data breaches, leave a comment below or request a workshop.