Subscribe to the Salt blog to learn about the latest developments in API Security

Blog Post

How Thinking Like an Attacker can Improve your API Security

Jennifer Dignum
Mar 23, 2022

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:

  • Corey Ball – OSCP, CISSP, CISM, and author of Hacking APIs
  • Katie Paxton-Fear – lecturer in cybersecurity, Manchester Metropolitan University, PhD in machine learning and cybersecurity, and ethical hacker

Below are a few key learnings from their sessions:

Attackers Often Use the API as Designed

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.

The Experian and Peloton incidents both highlighted the potential for significant data exfiltration simply by abusing an API as it was designed to work.

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.

API attacks take time

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.  

Organizations have security misconceptions

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:

  • Do we need to send all this information?
  • Is this request absolutely necessary for business purposes?

Corey elaborated:

“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.”

Testing (with the wrong tool) gives a false sense of security

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.

Corey added:

“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.

Security teams and developers need to work together

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.

We invite you to listen to the API Security Summit on-demand in its entirety. If you’d like to learn how Salt Security can help your organization secure its APIs, please contact us.

__________________________

Source: The RapidAPI Developer Survey and Insights 2019 - 2020: https://rapidapi.com/blog/wp-content/uploads/2020/03/Dev-Survey-Updated.pdf

Tags

Salt Security Blog

Sign up for the Salt Newsletter for the latest resources and blog posts.

July 26, 2024

Hadar Freehling
Principal Solution Engineer

Salt Labs

Another API Security Breach: Life360

The latest API breach occurred on the Life360 platform where an advisory was able to gleam 400k user phone numbers.

Read more

July 24, 2024

Eric Schwake
Head of Product Marketing

Industry

How Salt Catches Low and Slow Attacks While Others Can’t

Most API security solutions are designed to stop simulated attacks in a lab environment. They fail miserably in real world, low and slow attacks which are how attacks happen in practice

Read more

July 23, 2024

Eric Schwake
Head of Product Marketing

Industry

Detecting API Threats In Real Time

Recognizing the value of the sensitive data APIs carry, attackers have adapted their tactics, necessitating a fundamental shift in the approach to API security.

Read more

Download this guide for advice on evaluating key capabilities in API Security

Get the guide
Back