Reader small image

You're reading from  Defending APIs

Product typeBook
Published inFeb 2024
PublisherPackt
ISBN-139781804617120
Edition1st Edition
Right arrow
Author (1)
Colin Domoney
Colin Domoney
author image
Colin Domoney

Colin Domoney (BSc. MSc. CSSLP, CEH) is an API Security Research Specialist and Developer Advocate with deep expertise in the development of secure software. As VP of AppSec, he took on the challenge of securing software on a large scale and running the global AppSec program at Deutsche Bank. At Veracode, as an evangelist, he produces countless webinars, and blog posts, and speak globally at conferences. Currently, he has embraced the challenge of securing APIs with 42Crunch where he has produced the API industry's first security maturity model and contributed to numerous webinars, talks, and blogs. Currently, he is working on the industry's first defensive API developer training course. He is also the curator of the APISecurity weekly newsletter.
Read more about Colin Domoney

Right arrow

Attacking APIs

In the previous chapter, we explored the passive and active techniques that can be used to discover APIs. The focus in this chapter moves on to actively attacking and exploiting those APIs using various methods to exploit vulnerabilities in the API design or implementation. By the end of this key chapter of the book, you will be able to attack APIs on your own using various techniques. As a builder of APIs, one of the best ways to test their defense is to attack them yourself.

Secure APIs rely on strong authentication and authorization. In the first topic, we will learn how to attack by identifying design and implementation weaknesses. Fuzzing and brute force attacks are among the easiest to perform, and you will learn how to use automated attacks to crack open an API. Next, the focus turns to data-based attacks: either learning how to trick an API into accepting more data than expected (often leading to injection-based attacks) or finding APIs that leak excessive...

Technical requirements

For this chapter, you will need a development machine capable of the following:

  • • Running Docker locally
  • • Running VS Code with various marketplace extensions
  • • Access to the internet and a GitHub account to access the examples

This chapter contains many code samples in various languages; these can either be run locally, which will require the installation of compilers, SDKs, and frameworks, or from within a Docker build container.

The example code and various breaking changes to the instructions can be found in the Chapter 7 folder on the book’s GitHub repository here: https://github.com/PacktPublishing/Defending-APIs/tree/main/Chapter7

Authentication attacks

APIs are secured by controlling access based on a client’s identity (their authentication) and their permissions (their authorization). One of the most obvious and popular means to attack an API is to bypass the authentication controls by impersonating a client. Typically, this is done by guessing access credentials, stealing or forging credentials, or exploiting weaknesses in the authentication logic.

Insecure implementation logic

From an attacker’s perspective, there are two primary attack vectors: attacking a design weakness or exploiting an aspect of insecure implementation logic. Let us look at them in the following sections.

Credential attacks

For an API with a human user (where the authenticated user is a human or is delegated access to an authorized intermediary, such as an OAuth2 client), there will almost always be the need for credentials to be provided by the user. This is one of the most obvious points for an attacker to...

Authorization attacks

We now have a thorough understanding of the wide array of attacks that can be used on the authentication mechanisms of an API. Let us now turn the focus to the counterpart of authentication: authorization.

Object-level authorization

As a reminder, broken object-level authorization (BOLA) occurs when an API becomes confused about the right to access an object and allows unauthorized access. In Chapter 3, Understanding Common API Vulnerabilities, this is covered in detail in the API1:2019 — Broken object-level authorization section.

Conceptually speaking, BOLA attacks are simple to originate using the following recipe:

  1. Identify an API operation that takes an object ID as a parameter.
  2. Create a resource for the first user (call them user A).
  3. Confirm that user A can access the new resource.
  4. Using a second user (call them user B) who does not have access to the new resource, attempt to access the same resource. If you succeed, you...

Data attacks

Data attacks (covered in Chapter 3, Understanding Common API Vulnerabilities) are one of the most common attack vectors for an attacker since, inevitably, the data is most valuable on the black market. While data attacks are most commonly read attacks (mapping to the API3:2019 — Excessive data exposure category section), the write attack (mapping to API6:2019 — Mass assignment) can be damaging to an API since this can be used to modify permissions and confidential data of users. Let us look at both types of data attacks.

Excessive information exposure

The numerous API breach examples covered in Chapter 4, Investigating Recent Breaches, have one thing in common: they all involve excessive information exposure. APIs can expose excessive information in several ways, and as an attacker, you need to know where to look for it.

The most obvious place is in the response itself — always make sure you are looking at the API responses either in your...

Injection attack

Injection attacks are one of the oldest and most well-known software vulnerabilities. Although originally a common defect in web applications, they are quite frequently encountered in APIs, particularly when an API accepts user-supplied input. We will cover the basics of the main injection attack types. Readers wanting more details on topics including hands-on laboratories are advised to take a look at the Further reading section in this chapter, particularly the PortSwigger resources.

Detecting injection vulnerabilities

The concept of an injection attack is extremely simple: where an API expects input data, inject one of several types of payloads and observe the behavior. For example, by passing JavaScript into a website form, can you force the website to display a message box? If so, you have found a webpage that is vulnerable to XSS attacks.

For APIs, there are numerous locations where inject payloads can be placed:

  • Query strings in the URL (for...

Other API attacks

Finally, let us conclude this chapter with an overview of the catch-all API attacks not covered in one of the broader OWASP API Security Top 10 categories already covered.

API abuse

First, API abuse is considered an API attack that is not reliant on an actual vulnerability in the API itself but rather the abuse of the API, usually by using it in a way in which it was not intended. Typically, this attack vector includes excessive data exfiltration via APIs (think of scraping data from airline booking sites or estate agencies) or via discovering APIs’ underlying websites and using them in ways that are not possible via the website.

Unrestricted access to sensitive business flows

This is a new vulnerability category in the OWASP API Security Top 10 in 2023 that, like API abuse, revolves around using an API (or a collection of APIs) to exploit the underlying business flow it enables. The canonical example is an online booking system whereby an attacker...

Summary

Congratulations on reaching the end of this chapter – we have covered a lot of in-depth information on the practicality of attacking an API. At this point, you should have an appreciation for the fundamentals of many of the different attack types, and hopefully, you’re curious to try out some of these attacks yourself.

The attack techniques we covered align with the OWASP API Security Top 10 vulnerabilities, with a focus on authentication, authorization, and data-oriented attacks. By some measure, the most significant topic was the variety of ways in which authentication can be attacked and subverted in API systems — as a defender, this should be your first attack vector. Second only to authentication is the broad range of attacks that can be leveraged against authorization at both the object and function levels. We also learned key skills in attacking API data regarding both requests and responses. Finally, we covered a miscellany of attack types (injection...

lock icon
The rest of the chapter is locked
You have been reading a chapter from
Defending APIs
Published in: Feb 2024Publisher: PacktISBN-13: 9781804617120
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
undefined
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at €14.99/month. Cancel anytime

Author (1)

author image
Colin Domoney

Colin Domoney (BSc. MSc. CSSLP, CEH) is an API Security Research Specialist and Developer Advocate with deep expertise in the development of secure software. As VP of AppSec, he took on the challenge of securing software on a large scale and running the global AppSec program at Deutsche Bank. At Veracode, as an evangelist, he produces countless webinars, and blog posts, and speak globally at conferences. Currently, he has embraced the challenge of securing APIs with 42Crunch where he has produced the API industry's first security maturity model and contributed to numerous webinars, talks, and blogs. Currently, he is working on the industry's first defensive API developer training course. He is also the curator of the APISecurity weekly newsletter.
Read more about Colin Domoney