We interviewed Colin Tankard, Managing Director of the cyber security and data encryption company Digital Pathways, pictured, in our July print edition. Here he writes of APIs as the new threat.
Application programming interfaces (APIs) have become the must have option for many organisations, with enterprise developers relying heavily on them to support the delivery of new products and services. This is no surprise since APIs allow programmers to integrate functionality from externally provided services instead of having to build those functions themselves.
While interconnections offered by APIs have been around since the first programmes were written, the landscape is changing, especially with the rapid growth of mobile applications. Even legacy applications now have API’s written for them, to extend their life cycle which otherwise would make them redundant, as rewriting an old application to work with new processes would be too costly.
However, with the rise of APIs also comes the potential for more security holes, meaning developers need to understand the risk to keep corporate and customer information safe. The challenges start with programmers’ priority lists, as they tend to be driven by functionality and style rather than areas such as security. This is seen as a speed bump in design. Companies rely on their APIs to build applications that drive innovation and revenue, so there is no room for deployment delays. But many reports indicate that projects have had to slow down a rollout of a new application because of an API security concern.
Furthermore, the increasing regulatory focus on sensitive data leaks is impacting profitability and, the Public is taking notice. Poor API design and security practices are often at the root of sensitive PII data leaks. Consider the Experian breach, here a flaw in an API, that was designed to assess an individual’s credit worthiness, was exploited. The API was found to be leaky, based on the information it used to identify the API caller and the personal data it served back in the response. The credit information returned by the Experian API included Fair Isaac Corporation (FICO) scores and risk factors that impact the given individual’s credit history, such as proportion of balances to credit, number of accounts, and length of time accounts have been open. This information should not have been shared outside of Experian but was an example of how an API can be exploited to retrieve more information than it should do.
Gartner reported on API Security in, “Predicts 2022: APIs Demand Improved Security and Management” which outlines the risks and even predicts that API security will be the top exploit in 2022.
This report has the latest key trends and insights into what security and engineering leaders can do to proactively protect APIs. Gartner recommends that software engineering leaders, responsible for API technologies, should:
“Manage and govern all APIs by investing in discovery, cataloguing and automatic validation and by using an adaptive governance approach to manage a wide range of use cases and API types.
“Improve API security posture by developing a security strategy for threat protection, API security testing and API access control that leverages newer approaches and vendor solutions.
“Improve architectural resilience by actively managing the consumption of APIs – that is, the use of both internal APIs and third-party APIs.”
Whether you realise it or not, APIs are everywhere, and they exchange highly sensitive data constantly, making them a rich target for attackers, which explains why we’ve seen a significant increase in attacks targeting APIs in recent years.
Attackers have moved beyond well-known methods such as cross-site scripting (XSS) and SQL injection (SQLi) attacks to focus on finding unique vulnerabilities in APIs. Again, traditional solutions such as Web Application Firewalls (WAFs), which depend on signatures and known attack patterns, cannot detect or prevent these new attacks targeting the unique nature of APIs. Because they validate transactions one at a time and cannot correlate activity over time, they cannot detect the reconnaissance behaviour of a bad actor looking for a business logic flow in a company’s APIs.
There are many tools and solutions for API testing, but the starting points are:
Test for Parameter Tampering
Parameter tampering is often performed using hidden form fields. You can test for the presence of hidden fields using the browser element inspector. If you find a hidden field, experiment with different values, and see how your API reacts.
Test for Command Injection
To test if your API is vulnerable to command injection attacks, try injecting operating system commands in API inputs. Use operating system commands appropriate to the operating system running your API server.
Test for API Input Fuzzing
Fuzzing means providing random data to the API until you discover a functional or security problem. You should look for indications that the API returned an error, processed inputs incorrectly, or crashed.
Test for Unhandled HTTP Methods
Web applications that communicate using APIs may use various HTTP methods. It is easy to test if HTTP methods are supported on the server side, by making a HEAD request to an API endpoint that requires authentication. Try all the common HTTP methods—POST, GET, PUT, PATCH, DELETE, etc. If the HTTP method is unsupported on the server side, this creates a security vulnerability in the API.
APIs are incredibly powerful tools that can help an organisation advance its business goals and better integrate with customers, vendors, and business partners. However, in the face of constantly changing application development methods, and pressures for innovation, some organisations have not fully grasped the potential risks associated with making their APIs available to the public. Regardless of how many APIs are shared publicly, the security considerations should never be forgotten, and it is for the executives responsible for security and governance to ensure development and network teams never lose sight of establishing strong security policies upstream and managing them proactively, over time, for each development.
