Bug Bounty Bootcamp

Eleven of the twenty-seven modules cite this book, more than any other, and the reason is structural rather than a matter of taste. Every vulnerability chapter has the same four parts: how the bug works, how to prevent it, a numbered procedure for hunting it, and how to escalate what you find. That last section is the one nobody else writes, and it is the one that turns a finding into a flag.

It is written for bug bounty rather than competition, which shows in the framing - programme selection, report writing, the sustainability chapter about not burning out - but the middle four hundred pages are bug mechanics and they transfer directly. Where a CTF differs is that you already know a bug is there, so the hunting procedures become confirmation checklists rather than searches.

Why it is on this shelf

Because the web category in a CTF is not one skill, it is fifteen, and this is the only book here that covers most of them at the same depth in one voice. If you read one web book end to end before a competition, read this one, and treat the escalation sections as the part you are actually being tested on.

Chapter 5, Web Hacking Reconnaissance

Opens with the sentence that should govern the first twenty minutes of any web challenge: if an application does not use PHP, there is no reason to test it for PHP vulnerabilities. Recon is not a warm-up, it is the thing that decides which of the fifteen skills you are about to need.

The chapter covers manual walkthrough first - sign up at every privilege level, click everything, including the features you never use - and only then moves to dorking, subdomain enumeration, directory brute-forcing and technology fingerprinting. In a competition the manual pass is often the whole of it: the endpoint nobody linked to is usually in a comment, a JavaScript bundle or a sitemap rather than behind a wordlist. Our attack-surface lesson follows the same order, and the directory scanner is the tool for the part that does need a wordlist.

Chapter 6, Cross-Site Scripting

The three-way split - stored, reflected, DOM-based - done properly, with the DOM case given the space it deserves rather than a paragraph. The distinction that matters for a challenge is where the sink is: a payload that never touches the server cannot be found by grepping the server's responses, which is why a DOM XSS challenge feels unsolvable until you start reading the client's own JavaScript.

Her escalation section is the useful half. An alert box scores nothing; the question is always what the injected script can reach - the session cookie, an admin-only page fetched with the victim's credentials, a CSRF token that lets you complete a state-changing request. That is the shape of nearly every XSS challenge with a bot in it, and it is what XSS in CTF works through.

Chapter 11, SQL Injection

Classic, blind boolean, blind time-based and out-of-band, with the detection payloads for each and the reason each one is needed. The material on second-order injection is the part worth your time: input stored safely and then concatenated later, on a different page, by different code that assumed the database was trusted.

For competition purposes, pair the detection ladder here with SQL injection in CTF, which spends longer on the extraction step - the union that has to match column count and type before it returns anything - and less on the reporting.

Chapter 13, Server-Side Request Forgery

The clearest short account of SSRF anywhere: a public server with a proxy endpoint, an internal admin panel, and the observation that the firewall protecting the panel from the internet does not exist between two machines on the trusted network. That is the whole vulnerability in three sentences.

The chapter separates regular from blind SSRF and takes blind seriously rather than treating it as a lesser finding: no response body still gives you timing, error differentials and port scanning. Its bypass catalogue - alternative IP encodings, redirects, DNS rebinding, the URL parser disagreements - is the section to have open while you are stuck, and it lines up with reaching the internal network here.

Chapter 14, Insecure Deserialization

Covers PHP and Java, which are the two that come up, and gets the framing right: the bug is not that the format is unsafe, it is that deserialising reconstructs objects and reconstruction runs code. Magic methods in PHP, readObject in Java, and then the gadget chain - a sequence of classes already on the classpath that, wired together, does something the author never intended.

What she does not do is generate chains for you, and in a challenge that is usually the work. Deserialization and gadget chains picks up there, including the Python pickle case this chapter leaves out.

Chapter 15, XML External Entity

Short and complete. Entity declarations, the external entity that reads a local file, the parameter entity trick for exfiltration when the parser refuses to inline the result, and the blind case where your only channel is a request out to a host you control. She also covers the file formats that are XML without announcing it - office documents, SVG, SOAP, RSS - which is how most XXE challenges are packaged.

Read it alongside XXE and the XML parser, and note the general lesson: an upload field that accepts one XML-backed format accepts all of them.

Chapter 16, Template Injection

Server-side template injection as a distinct class from XSS, which is the confusion this chapter exists to clear up. The detection is arithmetic - if the page renders seven for a payload of seven multiplied by one, the template engine is evaluating you - and the exploitation is engine-specific, which is why identifying the engine comes before anything else.

The Jinja2 material is the part CTFs use most, and template injection and Python jails carries it further into the sandbox-escape territory the book does not go to.

Chapter 19, Same-Origin Policy Vulnerabilities

The best short explanation of why the browser's trust model is a security control at all, and then four ways it gets relaxed: CORS misconfiguration, postMessage handlers that do not check origin, JSONP, and using an XSS to sidestep the policy entirely. Her step-by-step hunt starts by asking which relaxation technique the target uses, which is the right first question.

The CORS section is the one to read twice. An Access-Control-Allow-Origin that reflects the request's Origin, combined with credentials, is a full read of the victim's authenticated responses - and it is easy to miss because nothing in the page looks wrong. Cookies, CORS and CSRF is the local version, and the security header analyzer is where to check a response quickly.

Chapter 20, Single-Sign-On Security Issues

Three mechanisms - shared cookies, SAML and OAuth - and the failure modes of each. The SAML procedure is a genuine four-step method: find the response, read the fields, bypass the signature, re-encode. Signature bypasses in SAML are the XML equivalent of the JWT none-algorithm trick, and they fail for the same reason: a parser that reads the assertion and a verifier that checks the signature disagreeing about which bytes are the message.

The OAuth half covers redirect_uri validation, the implicit-flow token leak and state-parameter CSRF. For token-shaped challenges generally, JWT attacks and the JWT decoder are the faster route; use this chapter when the flow rather than the token is the target.

Chapter 23, Hacking Android Apps

Practical rather than deep: proxy setup, certificate pinning bypass, the anatomy of an APK, and the tool list - adb, apktool, Frida, MobSF. For a mobile challenge that is often all you need, because the flag is usually a string, a key or an endpoint sitting in resources or smali rather than anything requiring dynamic instrumentation.

Start with the APK and IPA analyzer and the teardown lesson; come back here for the pinning bypass when the app refuses to talk through your proxy.

Chapter 25, Automatic Vulnerability Discovery Using Fuzzers

Web fuzzing, not memory fuzzing: injection points, payload lists, and the step everybody skips, which is deciding in advance what a hit looks like. Her monitoring section is the honest one - a fuzzer that returns four thousand 200s has told you nothing, and the work is in the response-length and status differentials that separate the interesting one.

Her pitfalls section is worth more than the tooling walkthrough: fuzzing finds the bugs whose signature you already knew how to describe. For the other kind, and for binary targets, coverage-guided fuzzing and From Day Zero to Zero Day are the ones to read.

Where it stops

It is a breadth book. Every chapter is the right length to start hunting and too short to finish - the deserialization chapter will not build you a gadget chain, the SSRF chapter will not get you through a parser-differential filter, and the crypto content is essentially absent. It also assumes a live target with a scope and a report at the end, so the risk advice and the escalation ceilings do not apply in a competition.

The tooling is of its moment: Burp, wfuzz, the 2021 recon suite. The methods outlive the tool names, but do not take the command lines as current.

What to take into a challenge

The four-part chapter shape, applied to yourself. When you are stuck on a web challenge, you are almost always stuck in one of those four places, and naming which one tells you what to do next. If you cannot say how the bug works, you are guessing at payloads. If you can exploit it but have nothing to show, you are missing the escalation step - and in a CTF the flag is always at the end of the escalation, never at the proof of concept.