Some Recent API Security Related Gaffes, And How They Might Have Been Avoided
This is the second of three guest blogs as part of our collaboration with Cequence. In the first blog on August 30, I wrote about how we’ve seen the level of API security knowledge increase since our initial research in 2019 but more must be done to secure the use of APIs in today’s hyperconnected world. In that first blog, I noted that CISOs (particularly in financial services organizations) and software developers have stepped up their API security game and I’ve seen a general increase in API security maturity. Nonetheless, reported API security vulnerabilities and API-related security breaches continue to pop up every month. Hence, more must be done.
In the last 60 days, we’ve seen API vulnerabilities reported for Cisco’s networking equipment, Bumble’s dating application, Microsoft’s PowerApps Platform, and Valve Software’s Steam Portal. In the case of Microsoft’s PowerApps Platform, cybersecurity firm UpGuard linked the API vulnerability to the disclosure of as many as 38 million records containing personally identifying information (PII). Security researchers reporting these vulnerabilities made the following cause attributions:
- Cisco – Improper access control in an API that could lead to an attacker being able to read or write to files – and ostensibly tampering with device firmware. Impacted products included Cisco Application Policy Infrastructure Controller (APIC) and Cisco Cloud Application Policy Infrastructure Controller (Cloud APIC). Details can be found in CVE-2021-1577. This stemmed from broken authentication, #2 on the OWASP API Security Top 10 list.
- Bumble – A security researcher received a $2,000 bug bounty for reporting a location-based vulnerability stemming from a poorly designed API endpoint. The vulnerability could be exploited by an attacker to spoof their location and determine the precise location of a Bumble user without authorization. A separate API vulnerability would allow an attacker to access a user’s profile information without being in their feed. This resulted from broken object level authorization, #1 on the OWASP API Security Top 10 list.
- Microsoft – An open data protocol API used by PowerApps had a default setting that turned off table permissions and this made data publicly accessible. The primary cause was attributed to broken authentication, #2 on the OWASP API Security Top 10 list.
- Valve Software – A vulnerability in the Steam Wallet API created the situation where a user could add value to their account by modifying user input. The input schema was protected by a hash function, but the implementation was flawed. The vulnerability was attributed to poor enforcement of payload schemas and netted a $7,500 bug bounty from Valve.
Fine, let’s just stipulate that despite improvements in API security maturity, the creation and implementation of APIs are complex and are still a challenge for many organizations and development teams. Additionally, security teams often lack the tools to test APIs to look for these vulnerabilities. But in the case of the first three examples, the OWASP API Top 10 has detailed descriptions and recommendations to help developers avoid these authorization and authentication issues. The Valve Software vulnerability is a bit more complex but could have been avoided via secure coding practices.
To be clear, simple awareness and cursory testing are not sufficient to avoid these security gaffes. API security maturity encompasses many other factors including designating an API security point of contact, maintaining an inventory of internal and external APIs, and publishing an API catalog or API development portal to assist internal developers or external implementers with API implementation.
More specifically, creating an API specification for each API using a standard such as OpenAPI or API Blueprint will define how the API functions and its relationship to data sources and other APIs. Through the development of the spec, it’s possible to uncover potential authentication and authorization shortfalls. Spec development can also lead to a threat modeling exercise with security professionals to determine “…so, what’s the worst that can happen?”
Now is the time to embark or double down on your API security improvement program. I’ll be covering additional aspects and recommendations in the upcoming third blog and a joint webinar with Cequence “Shielding Right to Strengthen Shift Left: Here’s How” on October 6th.
Joseph has been a cybersecurity analyst since 2019. He’s worked in information security for more than 45 years. His previous roles include operations officer for the U.S. intelligence community, a CISO at large publicly traded companies, and a cybersecurity strategy consultant for Accenture and PwC. He has worked in 115 countries, and he’s keenly interested in disruptive and emerging cybersecurity technologies.
The post Some Recent API Security Related Gaffes, And How They Might Have Been Avoided appeared first on Cequence.
*** This is a Security Bloggers Network syndicated blog from Cequence authored by Joseph Krull. Read the original post at: https://www.cequence.ai/blog/some-recent-api-security-related-gaffes-and-how-they-might-have-been-avoided/