Real-World Bug Hunting

Yaworski built this book out of publicly disclosed HackerOne reports. Each chapter names a bug class, explains the mechanism briefly, and then spends most of its length on real findings against real companies, walking through what the hunter noticed and why it was worth pulling.

That structure is its whole value and its whole limitation. You will not come away with a procedure. You will come away with a couple of dozen worked examples of somebody looking at something ordinary and seeing that it was strange, which is the skill a procedure cannot give you.

Why it is on this shelf

Because CTF authors read the same reports. A surprising number of web challenges are a disclosed bug rebuilt as a puzzle, and having seen the original makes the puzzle legible. It is also the best correction available to the belief that finding bugs is about knowing more payloads.

Chapter 7, Cross-Site Scripting

The XSS chapter is where the case-study format pays off most, because textbook XSS is a solved subject and real XSS is not. The reports here are all about context: a payload that is harmless in HTML and executes in an attribute, a sanitiser that runs before a second decode, a field the developer never expected to be rendered anywhere.

The recurring pattern worth naming is that the injection point and the execution point are usually different places, often different pages, sometimes different applications. A value stored by one feature and rendered by another is where stored XSS lives, and it is invisible to anyone testing one page at a time. XSS in CTF covers the mechanics; this chapter covers where to look.

Chapter 15, Race Conditions

The clearest short treatment of the class in any of these books, and the reason the tokens module cites it. His framing: a race condition is a process that makes a decision based on a condition, and finishes acting after that condition has stopped being true.

The examples are the classic shapes - an invitation accepted several times before the acceptance counter updates, a balance transferred twice because both requests read the balance before either wrote it, a coupon redeemed in parallel. What makes them useful is that they are all the same bug, and the pattern is recognisable in advance: any operation that checks then acts, on state shared between requests, is a candidate.

The practical detail he gets right is that near-simultaneous is not enough. The requests must arrive inside the window between the check and the write, which is why single-packet and parallel-connection techniques matter. Race conditions in web challenges covers the timing side, and the request replayer is where to fire them.

Chapter 18, Application Logic and Configuration Vulnerabilities

The chapter for the bugs that are not a class at all: a workflow that can be entered at step three, a permission checked on the interface and not on the endpoint, a configuration left at its default in one environment, a value the server trusts because it signed it earlier and never rechecked.

No scanner finds these and no payload list contains them, which is why they dominate the harder end of CTF web categories. The only method Yaworski offers is the right one: understand what the application is trying to do, then ask which of its assumptions you can falsify. That is the same question Designing Secure Software puts to the designer, from the other side.

The configuration half is worth reading for CTF specifically. Debug endpoints, default credentials, permissive CORS, exposed administrative interfaces and stale subdomains are all in scope here, and all of them appear in competitions because they are easy to plant and realistic. Web recon and attack surface is where that hunt starts.

Where it stops

It has no method. Every chapter is examples and a short conclusion, and if you want a procedure to follow you want Bug Bounty Bootcamp instead. The technical depth per class is shallow by design.

The reports are from 2014 to 2018 and some of the specific bugs have been fixed at the framework level. It is also entirely bug-bounty framed - scope, payouts, disclosure - which is context you can ignore.

What to take into a challenge

Read the reports, not just the class. When you are stuck, the useful move is often to find how somebody else found this bug in the wild rather than to try another payload. The noticing is transferable in a way the payload is not.