Title: Book review: Real World Bug Hunting Date: 2019-10-10 23:55 ![Real world bug hunting cover]({static}/images/bughunting.png) A couple of months ago, I got an email from someone at the marketing department of [No Starch Press](https://nostarch.com/): they read my [blog post]({filename}/crypto/book_review_serious_cryptography.md) about [Serious Cryptography](https://nostarch.com/seriouscrypto), 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](https://nostarch.com/bughunting) in my mailbox a couple of weeks ago. Its author is [Peter Yaworski](https://www.torontowebsitedeveloper.com/), self-taught PHP developer turned bug hunter, helped by [filedescriptor](https://blog.innerht.ml/) as technical reviewer. 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](https://www.youtube.com/watch?v=zPUe7O3ODHQ), in [French](https://www.youtube.com/watch?v=CCql9JInTBc), 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](https://bugs.php.net/bug.php?id=69545) in PHP (CVE-2015-4643) presented as a crash while it's trivially exploitable, a [heap-overflow](https://bugs.python.org/issue24481) in Python, only triggerable with malicious python code, and an OOB read in [libcurl](https://curl.haxx.se/docs/CVE-2014-3707.html) 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](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project) 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: #### Page 61, Cross-Site Scripting > 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](https://www.hackerone.com/resources/top-10-vulnerabilities) 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.". #### Page 72, 73, Template injection > With regard to AngularJS, versions earlier than 1.6 include a Sandbox that > limits access to some javascript functions and protects against XSS ([…]), but ethical hackers routinely found and released AngularJS Sandbox bypasses before the version 1.6 release. but later > 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](http://blog.angularjs.org/2016/09/angular-16-expression-sandbox-removal.html) a security boundary. #### Page 99, Server Side Request Forgery > 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 `"`), … #### Page 107, XML External Entity > 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. It's not [really](https://codepunk.io/a-brief-history-of-markup-and-xml/) [true](http://www.itwriting.com/xmlintro.php), but not really false either. #### Page 119, Remote Code Execution > 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. #### Page 137, Memory Vulnerabilities > 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. #### Page 139, Subdomain takeover: > Domains are the URLs that access websites, and they're mapped to IP addresses > by Domain Name Servers (DNS). This one doesn't make much sense: a [domain name](https://en.wikipedia.org/wiki/Domain_name) is usually part of an [URL](https://en.wikipedia.org/wiki/URL), via the [Domain Name System (DNS)](https://en.wikipedia.org/wiki/Domain_Name_System) protocol. #### Page 140, Subdomain takeover: > 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. #### Page 146, Subdomain takeover: > 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. Not really: An MX record specifies the mail server responsible for **accepting** email messages on behalf of a domain name. Email sending privileges are usually enforced via [SPF](https://en.wikipedia.org/wiki/Sender_Policy_Framework), [DKIM](https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail) and [DMARC](https://en.wikipedia.org/wiki/DMARC). ### Conclusion 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](https://nostarch.com/bughunter) - [Cure53 Browser Security White paper](https://github.com/cure53/browser-sec-whitepaper/) - [The Tangled Web](https://nostarch.com/tangledweb) - [The Web Application Hacker's Handbook, 2nd Edition](https://www.oreilly.com/library/view/the-web-application/9781118026472/) As well as [Securing the Tangled Web](https://ai.google/research/pubs/pub42934). Side-but-related-note, as highlighted by Kathie Moussouris during [her talk](https://gsec.hitb.org/materials/sg2019/D1%20COMMSEC%20-%20Security%20Should%20Be%20Smarter,%20Not%20Harder%20-%20Katie%20Moussouris.pdf) at [HITB GSEC](https://gsec.hitb.org/) 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!