The folks over at Packt Publishing sent me a gift recently. It was a copy of one of their latest books, Pentesting APIs: A practical guide to discovering, fingerprinting, and exploiting APIs.

Oh, how fun. I love seeing more books published on the topic of API security testing. While Packt Publishing gave me this book, they know that my opinions and any review are my own.

So let’s take a look at it, shall we?

Author Background

I don’t know Maurício Harley. We’ve never crossed paths before, probably because he lives and breathes IT and appsec across the pond over in France. I know he works as a Senior Software Engineer for RedHat, focusing on their OpenStack Security, and contributes to OWASP over there.

You can read his bio on Amazon or check out his LinkedIn profile here.

I can say from reading past articles he has written along with this book, that he clearly has enough war wounds to be able to share his experiences.

Let’s look at his API pentesting book in more depth and see what he shares. 

Content Overview and Key Topics

We will start by reviewing the structure of the book. 

The book is about 260 pages long but includes a lot of screenshots that are hard to see in print form. I would imagine the Kindle or PDF versions look much better than print in this regard. 

It is organized into five parts. These include:

1. Introduction to API Security
   1. Understanding APIs and their Security Landscape
   2. Setting up the Penetration Testing Environment
2. API Information Gathering and AuthN/AuthZ Testing
   1. API Reconnaissance and Information Gathering
   2. Authentication and Authorization Testing
3. API Basic Attacks
   1. Injection Attacks and Validation Testing
   2. Error Handling and Exception Testing
   3. Denial of Service and Rate-Limiting Testing
4. API Advanced Topics
   1. Data Exposure and Sensitive Information Leakage
   2. API Abuse and Business Logic Testing
5. API Security Best Practices
   1. Secure Coding Practices for APIs

It’s an interesting structure. From recon and information gathering to basic attack testing, with a smidge of secure coding guidance for good measure. 

The last bit didn’t really fit for me. It’s odd and out of place. While I respect Maurício’s position that we should be looking at how to prevent attacks as well, I don’t think that’s the place of an API pentester. This final part of the book could have been better focused on how to communicate the weaknesses in the code (like I talk about here) to developers, and provide guidance for remediation that way. 

With the structure articulated, let me tell you what I thought about the book.  

My thoughts on the book

I want to start by saying everyone has their own methodology based on learned experiences. So, that leaves me with the need to express the caveat that my lived experiences are different from Maurício. We choose different tools and ways to attack APIs. And our views on what it means to pentest an API differ.

I am not saying his approach is wrong. But it feels incomplete to me.

Honestly, I had mixed feelings about this book as I read it. It “felt” rushed, with some areas completely glanced over, while others went far too deep in setting something up that doesn’t materially teach us anything of value. 

We don’t need over a dozen pages to show how to set up Open Bullet for credential stuffing, only to miss spending any time discussing how to extract common API artifacts and OpenAPI documentation metadata to help map areas to attack.

But I am getting ahead of myself. There are some areas in the book that I thought were great and worth pointing out that I’d like to focus on first.  

What I liked about the book

I’m a dork for dorks. So when I saw the book include some Google dorks to use during information gathering, I was happy. I felt the same way when I saw how he approached identifying data and scheme structures within an API.

I really appreciated the chapter on Error Handling and Exception Testing. Most people don’t realize that more vulnerabilities lie in the failure code paths, since they never get as much testing exposure as the success paths. It was far too brief of a chapter, but it was still great to see. He could have covered in more detail how to use failure messages to identify the tech stack better, as I’ve discussed here in the past.   

Areas I think could be improved

The structure of what is in the book is there. But in almost all areas, I always felt like there was more to say.

For example, there is a section on capturing API traffic using Wireshark. Yet most APIs work over a TLS/SSL channel, leaving you with the need to decrypt that through some sort of AITM methodology. There isn’t a connection to explain why ZAP and Burp Suite are better tools for that. It just didn’t “flow” right.

In covering testing API access tokens like JWTs, he doesn’t go deep enough to cover all the common attack paths that can and should be tested against tokens. He talks about the fact you can’t crack the tokens for common vulnerable APIs used for practicing like OWASP crAPI. That’s just wrong. I actually showed you years ago how to leverage HashCat running on GPU-enabled VMs in Azure to crack the signing key for access tokens. 

The coverage of Injection Attacks and Validation Testing was a missed opportunity. Think about some of the articles I’ve written about in the past. Like how to attack an API by tainting data in weird places. Or how to exploit an API using Structured Format Injection (SFI). Or topple an API by using server-side prototype pollution. And don’t forget about abusing the API parsers to trigger logic flaws through JSON injection. 

There was so much more that could have been said. And that seemed like a theme throughout the book. The sections weren’t wrong. They just felt like they were incomplete.

Who is this book for?

This book was an easy read for me. I think the ideal audience would be someone brand new to API security testing. Core foundational knowledge is shared within these pages, and everyone new to the tradecraft will need to know it.

Even though there is a section for securing coding, I wouldn’t think of this book as something developers will find useful, unless they already have an attacker mindset. I usually find bug bounty hunters find it easier to have an adversarial mindset than developers, which I have talked about here.

Experienced API hackers won’t really benefit from any new knowledge within this book. However, it never hurts to get exposed to different methodologies and tools our peers use.  

Conclusion

So, is the latest book on “Pentesting APIs” any good? 

I’m a lifelong learner. Any knowledge gained is worth it, and we should regularly practice our tradecraft. 

If you are brand new to pentesting APIs, you may find it valuable and helpful in your hacking journey. If you aren’t, you might find new ways to do things.

However, I’d recommend you check out my list of recommended books every API hacker should have on their bookshelf first. Some books like Corey’s Hacking APIs cover everything this book does, but in far better depth and breadth.

HTH. 

One last thing…

Have you joined The API Hacker Inner Circle yet? It’s my FREE weekly newsletter where I share articles like this, along with pro tips, industry insights, and community news that I don’t tend to share publicly. 
If you haven’t, subscribe at https://apihacker.blog.

The post Is the latest book on “Pentesting APIs” any good? appeared first on Dana Epp's Blog.

*** This is a Security Bloggers Network syndicated blog from Dana Epp's Blog authored by Dana Epp. Read the original post at: https://danaepp.com/is-the-latest-book-on-pentesting-apis-any-good