The monolithic applications of yesteryear seem simple and straightforward when considered through the lens of today’s containerized, microservices-oriented environment. Surprisingly to some, many modern applications on their own are now as intricate as the entire internet of only a decade ago! While these advances have served to speed online business, they have also introduced some potential vulnerabilities that you may not expect.
Yesterday’s applications relied upon direct connections. Back in the day, if you wanted access to the content housed in the giant server in the computer center, you needed to have a specific software client that could take your request, deliver it to the server, ensure that the request was understood, get your answer, and bring the requested data back to you. Today’s applications have grown out of the enterprise computer room to the datacenter and into the cloud. New advances in modular computing have enabled the different parts of an application or service to be located in a variety of different physical places including the public or private cloud. Services can be abstracted to virtual machines or housed in containers or sidecars that enable consistent operation across various computing environments. These computing resources can now house different services within a single server, making it possible to scale infrastructure to support high-demand functions (such as getting quotes or viewing buying options) without disturbing the entire app. Calls to an application can now take a variety of different paths to reach their destination, depending upon location, workload or other variables. This architecture is similar in function to how the internet itself works, and for the same reason; it is highly available and resilient. Unfortunately, however, with increasing complexity comes increasing risk.
One of the lynchpins in today’s architecture is the Application Program Interface, or API, which enable different computing languages and operating systems to communicate. APIs themselves are not new; low-level function calls that enabled parts of early PCs to communicate with other parts have been around for decades. The APIs of today have expanded upon that role, acting as the communications “glue” that allows different elements of a service to interact with the others, both externally and internally. One of the interesting things about APIs, however, is that as they have become increasingly ubiquitous, they have also grown to pose a larger, often overlooked and poorly understood security risk.
APIs – the Oft-forgotten Link in the Kill Chain
As the “front end” of many applications, external APIs are subject to similar dangers as the applications behind them. One such danger is the threat of Distributed Denial of Service (DDoS) attacks, which was notably seen when the FCC’s Electronic Comment Filing System (ECFS) was overwhelmed in 2017. In that case, John Oliver’s television show, Last Week Tonight, ran an episode encouraging users to file comments on the topic of Net Neutrality. It appeared that the number of comments hitting the external API that directly connected viewers to the appropriate page, rather than forcing them to navigate from the home page brought down the service. FCC investigators later determined that the event was actually caused by a DDoS event. In this case the API served to increase the attack surface in such a way that it caused unforeseen consequences.
A volumetric DDoS event caused by an API being overwhelmed is only one issue. The popularity and mission-critical nature of APIs in today’s web environment poses some specific and unusual risks. One of the biggest hazards arises from the fact that APIs have become so common that some enterprises may not be aware of where they are, or the function that they perform. While this can cause problems for the backend site when an external API is overwhelmed, it can cause huge issues in the cases where that API is connected to another inside the application. The possibility for lateral movement can wreak havoc similar to what was seen when an attacker made use of a third party’s VPN access to get into Target’s POS system. While the internal API might be protected from standard incursion, it may well be open to an attack from another interface with which it expects to interact.
Then there is the nature of APIs themselves. As in any situation when a computing interface is quickly assimilated into wide operation, there can be problems with loose specifications. Developers can now use APIs to shave months off application development. Because these interfaces are often viewed as commodities, performing necessary functions without the need for custom work, they may not always be scrutinized as closely as custom code. One example is an OpenAPI spec which allows the entry of a parameter string of any size or value. This can open the backend server to attacks that include SQL injections or buffer overflows, to name a few. The reliance upon CMS/open source libraries and plug-ins as a means to get an app to market quickly has the potential to propagate vulnerabilities across systems and throughout the application lifecycle. These elements are dependent upon code injection and internal APIs to provide the information that they need to function, which opens them – and the enterprise – to possible attack.
Further complicating the situation is the fact that today’s infrastructure is not homogenous. This is particularly true when considering internal APIs, which may interact with legacy systems as well as distributed, containerized applications. One example is the financial services industry, which has long been cited as operating under particularly heavy “technical debt,” with systems that might be running COBOL or DB2. Internal APIs are used to extract, transform and load (ETL) data between these different architectures, creating the kind of baffling complexity that is ripe for exploitation.
What to Do
APIs have become a mission critical element in the modern computing environment. There is no option to simply cut them out of the infrastructure. The trick is to determine best practices by which you can use APIs safely. Simply limiting requests or monitoring traffic rate might be a good start, but a more robust application security strategy that includes APIs is essential.
You probably wouldn’t consider deploying a web app without considering things like payload inspection and security, looking at elements like JSON, XML and HTTP. These security measures must extend to APIs as well. Signature-based inspection is another vital consideration. Common types of signatures include those that you’re probably already using, including PHP vulnerabilities as well as those that are specific to CMS, such as WooCommerce, Magneto, Drupal and more. Finally consider API endpoint-specific controls. These controls consider the source IP to perform specific rate-limiting actions, add redirections, or issue authentication challenges
One of the easiest ways to get these protections is to use a cloud-based web application firewall, or WAF. WAFs can be used to validate all API requests made to the micro-services and serve as an additional layer of protection as your business evolves. Look for a vendor-neutral offering to ensure that your web applications can easily grow in step with your business.
Read the next blog, All Attacks Are Not Created Equal.
