Ray Pompon, Principal Threat Research Evangelist at F5 Networks, examines the ongoing challenge of API visibility and security
The word is out. Organisations across the world are finally waking up to the potential of application program interfaces (APIs) transforming business models and directly generating revenue.
Momentum has been building steadily. Back in 2015, the Harvard Business Review reported that 90% of Expedia’s revenue was driven by APIs. eBay and Salesforce also claimed 60% and 50% API-driven revenue, respectively
In simple terms, an API is a user interface for other apps instead of users. They are often managed with API gateways, which are lightweight pieces of software running on an application server that manages those connection points for other app services or mobile apps to push or pull data. This helps define the API in relation to other APIs and clients, enabling organisations to use the output of the original service in different ways, apps or environments without starting from scratch. This is a big deal for those looking to leverage existing infrastructures with minimal modifications.
The influence and spread of APIs has continued to grow in recent years, with the portal and community forum programmableweb.com listing 12,000 in 2015. In October 2019, the number stood at nearly 23,000. Naturally, this hasn’t gone unnoticed by hackers and cybercriminals.
One of the biggest issues is overly broad permissions, which means attacks through the API can basically give bad actors visibility into everything within the application infrastructure. API calls are also prone to the usual web request pitfalls such as injections, credential brute force, parameter tampering, and session snooping.
Visibility is another major an increasingly pervasive problem. Organisations of every stripe – including IT vendors – have a notoriously poor track record of maintaining situational API awareness.
2019: the year of misconfigured access control
In the latest instalment of our 2019 Application Protection Report, F5 Labs discovered that all of 2018’s recorded API breaches up until November focused on large platforms with significant numbers of APIs, and mobile apps heavily dependent on a few of them to function.
However, every single breach discovered by F5 Labs from November 2018 to the present was the result of misconfigured access controls.
In other words, system owners did not realise that their API was wide open. The good news is that the principal threat actors were primarily fame-hungry security researchers with no intentions to leak or exploit data. Next time, organisations may not be so lucky.
In another notable near-miss from last year, a North Carolina State University study found that more than 100,000 code repositories on GitHub had API tokens and cryptographic keys—the literal tools for API access control—stored in plaintext and visible in plain sight. It is a trend we’ve seen for a while: developers using workarounds or insecure practices during development, and then failing to mitigate those issues when the project goes live. Storing API authentication information in plaintext on GitHub is just the latest incarnation of an enduring issue.
To stay ahead of the API security curve, the F5 Application Protection Report urges organisations to:
- Keep an inventory. Understand where your APIs exist and how they contribute to business operations. Context is king. Perimeter scans (to get the “hacker’s eye” view”) and in-depth discovery interviews with development and operations teams are essential. Get all the details on the table and prepare risk assessments accordingly.
- Authenticate. F5’s 2019 State of Application Services Report found that 25% of surveyed organisations do not use API authentication. 38% reported that they did so “some of the time,” and 37% said it was “most of the time.” This a big problem. There are different forms of API authentication and a risk-based approach is advised before committing to anything. Credentials are the keys to the kingdom and must be stored in a secure way, whether in the form of user/password combinations (for either machines or human users) or API keys (which are simplified authentication strings that have specific uses).
- Authorise. No APIs should pass unsanitised or unvalidated input to applications. That is a sure-fire recipe for an injection attack. API credentials must be treated using the principle of least privilege. Role-based access control is the best way forward. At a minimum, it should entail limiting HTTP methods that specific roles can implement. Organisations need to allow their environments and business logic dictate decisive action. It is also possible to define sequences of actions that correspond to the specific API use case.
- Log API connections. Log and review all API connections, regardless of outcome and behaviour. It is also best practice to monitor the assets that the APIs serve.
- Encrypt. We increasingly encrypt all user traffic on the web and APIs are no different. Encrypt connections and validate certificates, as with any other service.
- Explore API security tools. Use an “API-aware” proxy or a firewall to inspect, validate, and throttle requests. Some API security services can analyse the originating client and attempt to determine if a request is legitimate or malicious. They can also ensure that API requests stay where they’re supposed to.
- Continuously test. The prevalence of APIs is matched only by their obscurity. Constant testing is required to stay current. It is also a good idea to place a bug bounty on API vulnerabilities and harness the insight of proactive security researchers.
APIs are not new, but they are increasingly relevant for the way the Internet is growing and applications are evolving. In many ways, they reintroduce existing risks in forms that are more likely to be exploited, more impactful, and harder to recognise. See, for example, Cambridge Analytica’s notorious recent exposure of social media API loopholes that enabled it to collect millions of users’ data. At the same time, APIs are an unavoidable component in contemporary architectures, which means that avoiding or ignoring any related security issues is no longer an option.