Salt Security revealed today that its researchers discovered a server-side request forgery (SSRF) failure in an application programming interface (API) used by an undisclosed US-based financial services company serving hundreds of banks and millions of customers.
Yaniv Balmas, vice president of research at Salt Security, said the flaw allowed the takeover of administrative accounts (ATOs) that could allow a cybercriminal to gain access to financial transactions, personal data, and allow attackers to transfer funds. Specifically, the Salt Labs researchers could easily manipulate several of these external interactions that required input values such as URL values, he said.
That issue has since been fixed, but Balmas said the design pattern for the API that led to the flaw’s creation is commonly used by many other organizations. In many cases, organizations are not aware of potential API security issues. Developers should pay special attention to user-controlled input values, adding validation and behavioral detection to protect data from SSRF attacks, he noted.
The recent Salt Security State of API Security report for Q1 2022 found that 95% of organizations experienced an API security incident in the last 12 months. Overall, malicious API traffic increased 681% during the quarter, according to the report. Additionally, 86% of respondents said they are not confident in their ability to know which APIs expose sensitive data, while 85% of respondents said their current tools are ineffective at stopping API attacks. An equal number of respondents said they did not fully trust their API inventory.
As APIs become more widely used, the chances of those APIs being compromised only increases, Balmas said. Web application firewalls (WAFs) and API gateways often can’t detect API tampering, he added. Salt Security is championing a security platform that leverages big data and machine learning algorithms to create a baseline of activity across millions of users and API calls. An API Context Engine (ACE) protects APIs in the build, deploy, and runtime phases, discovering all APIs and the data they expose to stop API attacks, and displaying information that can be used to harden APIs .
The main challenge many organizations face has little to do with the attacks themselves; the biggest problem in many organizations is who, exactly, is responsible for API security. In theory, the developers who create the APIs should protect them; most, however, lack the cybersecurity expertise to do so. It’s usually up to security teams to protect APIs at runtime. Despite all the hype around shifting responsibility for app security to developers, it will be the security teams that will primarily rise to the challenge.
Overall, the rate of change being made to APIs is increasing thanks to the rise of microservices-based applications that are driving digital business transformation initiatives. Cybercriminals, of course, are looking for APIs through which they can surreptitiously exfiltrate data. A successful attack against an external API can cripple a digital business transformation initiative if sensitive data ends up for sale on the dark web.
In the meantime, cybersecurity professionals would do well to look for so-called zombie APIs that a developer once created and then abandoned without removing them from a production environment. After all, cybersecurity teams can’t defend attack surfaces they don’t know exist.