As the adage goes, the best defense is a good offense. While the OWASP API Security Top 10 provides a great starting point to learn about API security, CISOs should also consider API vulnerabilities from an adversarial mindset to defend against attacks.
By thinking like a hacker, security teams can improve security at all stages of an API’s lifecycle.
To better understand that mindset, we welcomed two leading cybersecurity experts to our recent API Security Summit, the industry’s first summit focused exclusively on API security. Our special guests included:
Below are a few key learnings from their sessions:
According to Corey, one of the most basic, yet highly effective, ways to attack an API is to use it as it was designed. Using APIs in the way they were intended to be used can provide an entry into further exploitation.
The OWASP API3: Excessive Data Exposure provides an excellent illustration of this form of attack. In the case of excessive data exposure, attackers make an API request; however, they are counting on the possibility that the API will provide more information than needed – ideally, sensitive information that they can use in more complex attacks. For example, an API request for user information might also produce the admin’s user name, multifactor authentication status, and other data that is completely unnecessary to the original request.
Peloton wanted and designed its application to be social by allowing users to see other users’ workout data. In the Peloton incident, back-end APIs disclosed users’ PII in response to legitimate queries. The flaw was that the back-end APIs expected the front-end to filter out all sensitive data, something that didn’t happen. Rubbing salt in the wound (pun intended), the Peloton flaw was also uncovered by an authenticated account user!
When you put on an attacker’s cap, you have a better chance at identifying how an abuse of a legitimate use of your API could allow bad actors to gain access to far more data than they should be able to get.
Katie envisions a hacker as a bit of a Sherlock Holmes. They’re out there searching for clues, looking for any signs of API vulnerabilities. Hackers will consider what could be there and try multiple exploits to uncover API flaws. If they try an exploit, and it doesn’t work, they figure out why, change the exploit, and try again.
Because of the nature of the attacks, API attacks take time. A single attack can unfold over hours, days, or even weeks. Therefore, security teams need event correlation and context over time to accurately identify API attacks, and traditional security solutions lack that context over time.
Many organizations mistakenly believe that authentication is sufficient to protect against authorization attacks. There’s an assumption that any user who can authenticate to the API can be trusted, but overreliance on authentication can actually increase an organization’s vulnerability.
In fact, empirical data from Salt Labs shows that 94% of API attacks occur against authenticated endpoints and users.
Attackers are out there, and they are targeting APIs as one of the top ways to attack organizations. With an adversarial mindset, organizations can stay ahead of the attackers, surfacing considerations to limit data exposure even as the API is being developed, such as:
“Every API that is consumed or provided by an organization is an expansion of that organization’s attack surface – every API, every endpoint, every third-party API, whether public or private – it doesn’t matter. Putting on the adversarial thought process against the API will help everyone along the way to consider features and other potential logic flaws that can be used against an API provider in order to compromise them.”
According to Corey, using the wrong tools to test the security of your APIs is like trying to check the temperature with a ruler. If you’re not using the right tools to test your API vulnerability, the results are not accurate. You might also get a false sense of security. You think you’ve done all the appropriate scans, and they came out clean – so you’re good, right? You are good, right up until your organization gets compromised.
“Applying the tools and techniques to deliberately vulnerable applications provides a good indicator of whether your current vulnerability management program is doing anything – or if it’s just giving you a false sense of security.”
In addition, API testing in isolation or statically will get you only so far. You need to see the API exercised to really understand what’s going on and to see whether they have any gaps in the logic flow. It’s precisely those missing logic steps that attackers are seeking.
The RapidAPI 2021 State of APIs developer survey report found that only a tiny fraction – 4.3% – of developers were conducting security testing on APIs.
Developers write APIs; however, their pre-prod test and static analysis fall woefully short in securing them. You must exercise the API – even in pre-production – to accurately see what’s going on. Security teams can support developers by bringing runtime insights back into the development cycle for the next round. Sharing runtime insights to harden APIs brings a lot of value into the process.
Source: The RapidAPI Developer Survey and Insights 2019 - 2020: https://rapidapi.com/blog/wp-content/uploads/2020/03/Dev-Survey-Updated.pdf
It’s extremely important to make sure your OAuth implementation is secure. The fix is just one line of code away. We sincerely hope the information shared in our blog post series will help prevent major online breaches and help web service owners better protect their customers and users.
We want to thank our customers, partners and friends for the calls and messages to our team showing your concern and support.