Why There Is No API Security

Whether we see them or not, application programming interfaces (APIs) are a crucial part of business today. They are used in virtually every aspect of IT and DevOps. APIs facilitate and even drive B2B and B2C partnerships, ecommerce acceleration, systems and application automation, and solution integrations. Without them, business and IT shops would not be able to deliver services anywhere near as fast and efficiently as they do today. However, this speed comes at a cost. User security is often a trade-off between security and usability and there seems to be a similar trade-off with leveraging APIs.

Businesses are pushing their application APIs harder to be more robust, flexible (a.k.a. open), and faster. API programmers often have to stretch the limits of operation to accept a wide variety of inputs. Even if a specification is produced to tell other programmers how the interface should be used, it is impossible to ensure that those same programmers will not misuse or otherwise find loopholes in the specification—but it is assured that threat actors will do just that. Though we have recourse with legitimate programmers, we do not have the same luxury with threat actors trying to do the same for malicious or otherwise nefarious purposes. This creates a problem for everyone using APIs to support business because they are simultaneously creating attack vector on their accessible API-enabled applications. While programmers can perform input validation, character filtering, and other checks on inputs to ensure they meet certain security requirements, security organizations will need to identify enhanced protection external to the application that has application-level intelligence for the inputs.

It is also interesting to note that insecurity with APIs has become pervasive enough that the Open Web Application Security Project (OWASP) added two areas of insecurity to their 2017 proposed list for Top 10 application vulnerabilities. Coming in at designation A7 is “Insufficient Attack Protection,” followed at designator A10 by “Underprotected APIs.” These are not a badge of honor. In fact, their rise to fame is a tragedy. As if we didn’t have enough to worry about, we created two new areas of concern with a failure to self-regulate the way we create and manage APIs. For More information on the new OWASP Top 10 click here to download the document.

[You might also like: Why ISP DDoS Services Typically Fail]

To understand why APIs inherently lack security, you must understand that API exploits attempt to compromise the application in one of two ways. The first is through application programming errors that attempt to reveal data or impair the operation of the application. These exploits manifest themselves through malicious inputs like SQL injection, cross-site scripting, and other such attempts at exposing data. Generally, applications can be secured against programming errors. This is often an iterative approach that can take months to years of use, testing, patching and retesting, but it can be done.

The second avenue is through attempts to exploit the business logic of the application to create unauthorized access or fraudulent transactions. The harder portion to identify and stop are the exploits of business logic. Applications are being designed to deliver micro-services which expose a large number of interfaces to the Internet. This creates a larger attack surface with a net effect of providing threat actors the opportunity to attack each micro-service rather than a single application, creating a greater risk to the organization that attackers can get access to data. Because applications exploit various facets of operation rather than programming flaws, they require a greater understanding of operation than programming checks. No single part of the application, nor any part of normal Internet filtering firewall defense, has enough visibility into the context to stop business exploits. Some examples of business logic exploits are:

• Modification of authentication flags and privilege escalations
• Business constraint exploitation/modification or business logic bypass to generate fraudulent transactions
• Requested parameter modification
• Developer’s cookie tampering and business process/logic bypass
• Exploiting clients’ side business routines embedded in JavaScript, Flash, or Silverlight
• Identity or profile extraction
• LDAP parameter identification and critical infrastructure access

Business logic attacks are not trivial in their consequences and are successful on even the largest organizations. A few of the large organizations that fell victim to business logic flaws are Facebook, Nokia, and Vimeo.

There are multiple approaches to protect against business logic exposure from outside the application. Two of the most prominent are prevention and continuous monitoring. Prevention requires testing both initial development and throughout the API and application lifecycle. It is critical not to take shortcuts on this lifecycle process with so much riding on the success or failure of business-critical applications. Continuous monitoring can be done through vulnerability scanning to identify programming errors, but not to identify business logic errors. Protection from business logic errors requires technologies that are both API- and application-aware so when fraudulent, probative, erroneous, or otherwise bogus inputs arrive, they can be detected and filtered. This is a primary function of a Web Application Firewalls were designed to do.