A couple of months ago, I got an email from someone at the marketing department of No Starch Press: they read my blog post about Serious Cryptography, and wanted to send me a book for free to review: this is how I got, amongst stickers, Real world bug hunting — A Field Guide to Web hacking in my mailbox a couple of weeks ago.
The book isn't really a "Field Guide to Web Hacking", more like a collection of real-world bug bounty reports, prefixed with a short explanation of a vulnerability so that everyone could grasp what the reports are about, organised in chapters. For each report, there is the estimated difficulty, the impacted URL, a link to the actual report, the date when the issue was reported, and the bounty paid.
Some of the examples are a bit weird: because they're basically commented bug bounty reports, there is often no way to understand what is going on server-side, and a couple of the examples are ending with an hand-waving-y "the security team investigated, didn't award the bounty, then found that there was indeed an problem, awarded some money, and fixed the issue". This is entirely fine in a bug bounty report, but in an educational book, it's like being told the Lion King without Timon and Pumba: you're missing the coolest part! (To be fair, I think that the coolest part of the Lion King is Scar's song, Be prepared, in French, because I can't help to imagine that he's voiced by Severus Snape in the English version).
The families of vulnerabilities are pretty classic: Open redirect, HPP, CSRF, HTML injection/content spoofing, Carriage return line feed injection, XSS, template injection, SQLI, SSRF, XXE, RCE, memory vulnerabilities, subdomain takeover, race conditions, IDOR, OAuth vulnerabilities, and finally, Application logic and configuration vulnerabilities.
The chapter about memory vulnerabilities is a bit off-topic in a book about web-security, as well as super-lightweight: OOB R/W, and the three examples are an integer overflow in PHP (CVE-2015-4643) presented as a crash while it's trivially exploitable, a heap-overflow in Python, only triggerable with malicious python code, and an OOB read in libcurl from 2014, that doesn't affect curl, contrarily to what is implied in the book. Although, to be fair, the book recommend to the reader to take a look at other sources if they're interested in this topic, because it's a subject that "can be complex".
Speaking of the reader, I'm not sure who the target is: The introduction states "This book introduce you to the vast world of ethical hacking, or the process of responsibly discovering security vulnerabilities and reporting them to the application owner.". Except that if you don't know anything about web security, this book won't teach you much: you could read the OWASP's TOP10 instead for the same result. Except that you'll also learn about defenses and mitigations in the same time. But maybe I just had higher expectations from this book, and its goal is simply to showcase various vulnerabilities, so that people can decide if they want to dig deeper of not.
While there are anecdotes/tips'n'tricks spread everywhere in the book, there are 3 chapters dedicated to how to behave while participating in a bug bounty: Bug bounty basics, Finding Your Own Bug Bounties, and Vulnerability Reports. This is a really nice touch, and as someone who has seen reports from the other side, I really appreciate the emphasis on being nice, detailed, polite, to not waste anybody's time, … both for the participants and organisers of the bug bounty. The tl;dr being "don't send shitty reports", and "if a bug bounty program is annoying, life is short, don't bother, go participate in other ones".
But, something that frustrated me a lot, is that a large chunk of the definitions in the book are either vague or over-approximations, which would be kinda ok in a casual conversation: I would understand what the other person is talking about, but in a printed book, it's a bit spotty. For example:
Despite the potential damage XSS can cause on a site, fixing XSS vulnerabilities is often easy, requiring only that software developers sanitize user input (just as with HTML injection) before rendering it
Except that it isn't that easy to fix XSS as scale, otherwise it wouldn't be the most common issue on HackerOne, with more than USD $8M bounties paid for this kind of vulnerability alone in 2018.
This part of the book really angered me: finding bugs is easy, fixing them at scale, for good, without performances impact, without adding horrible complexity, … is hard. Reading that it's just a matter of correctly handling user input is infuriating: "You just have to avoid making mistakes and introducing security issues in your codebase in the first place.".
As mentioned, older versions of AngularJS implemented a Sandbox, but the version Uber was using was vulnerable to a sandbox escape
All the AngularJS versions were vulnerable to sandbox escapes, this is precisely why it got deleted in AngularJS 1.6. Amusingly, the sandbox never was a security boundary.
In programming languages in which the programmer needs to manage memory manually, a null byte terminates a string
It's the case for C and C++, but not in FORTRAN, COBOL, Pascal (P-string are
length prefixed, although this is implementation-dependent), BASIC (it uses
XML is a metalanguage, meaning it's used to describe other languages. It was developed as a response to the shortcomings of HTML, which can define only how data is displayed. In contrast, XML defines how data is structured.
A remote code execution (RCE) vulnerability occurs when an application uses user-controlled input without sanitizing it. RCE is typically exploited in one of two ways […]
This is a broad definition, not specific to RCE, that does apply to a lot of other vulnerabilities types.
If you want to search for these types of exploits, I recommend […]
One can search for vulnerabilities, to write exploits for them, but you usually don't search for exploits in applications.
Domains are the URLs that access websites, and they're mapped to IP addresses by Domain Name Servers (DNS).
Only site administrators can create DNS records for a site ([…]).
Technically, the administrator of the DNS zone can change the record, not the site administrator.
An MX record is a type of DNS record that specifics a mail server responsible for sending and receiving email on behalf of a domain. Recipient email servers and services query DNS servers for these records to verify an email's authenticity and to prevent spam.
The book looks a bit like an advertisement in ~200 pages for bug bounties, which would be ok if it was clearly labelled as so, which it isn't. Instead of a 40USD volume, it could have been a really great blogpost in 20 sections, with links to the reports.
If you want to learn more about web security, I recommend to take a good look at the "Recommended reading" section at the end, and check the following a-bit-dated-but-still-amazing recommended resources:
- A bug hunter's diary
- Cure53 Browser Security White paper
- The Tangled Web
- The Web Application Hacker's Handbook, 2nd Edition
As well as Securing the Tangled Web.
Side-but-related-note, as highlighted by Kathie Moussouris during her talk at HITB GSEC this year: On HackerOne, 97.5% of the people never sold a bug, 0.3% made $5K or more, and 0.03% made $100K or more. 100% of the winners have tried their luck!