Salt Security Details FinTech Firm’s API Security Breach
Salt Security today revealed that its researchers discovered a server-side request forgery (SSRF) flaw in an application programming interface (API) used by an undisclosed U.S.-based financial services firm that serves hundreds of banks and millions of customers.
Yaniv Balmas, vice president of research for Salt Security, said the flaw allowed administrative account takeover (ATO) that could enable a cybercriminal to gain access to financial transactions, personal data and allow attackers to transfer funds. Specifically, Salt Labs researchers could easily manipulate a number of these external interactions that required input values such as URL values, he said.
That issue has since been remediated, but Balmas said the design pattern for the API that led to the flaw being created is commonly used by many other organizations. In many cases, organizations are not aware of potential API security issues. Developers should pay particular 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 the first quarter of 2022 found 95% of organizations experienced an API security incident in the past 12 months. Overall, malicious API traffic increased 681% during the quarter, the report found. In addition, a full 86% of respondents said they lack confidence in their ability to know which APIs expose sensitive data, while 85% of respondents noted that their current tools are ineffective at stopping API attacks. An equal number of respondents said they lacked full confidence in their API inventory.
As APIs become more widely employed, the odds those APIs will be compromised only increases, said Balmas. Web application firewalls (WAFs) and API gateways are often unable to detect API manipulation, he added. Salt Security is making a case for 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 across the build, deploy and runtime phases, discovers all APIs and the data they expose to stop API attacks and surfaces insights that can be used to harden APIs.
The primary challenge many organizations face has little to do with the attacks themselves—the larger problem in many organizations is knowing who, exactly, is responsible for API security. In theory, the developers that create APIs should secure them; most, however, lack the cybersecurity expertise required to do so. It generally falls to security teams to protect APIs at runtime. Despite all the hype around shifting responsibility for application security further left toward developers, it will be security teams that will mainly rise to the challenge.
In general, 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-facing API can cripple a digital business transformation initiative if sensitive data winds up for sale on the dark web.
In the meantime, cybersecurity professionals would be well-advised to scan for so-called zombie APIs that a developer once created and then, later, abandoned without removing them from a production environment. After all, cybersecurity teams can’t defend attack surfaces they don’t know exist.
