Book Review - Web Hackers Handbook

Introduction

Over the summer, I decided to further my learning by picking up a book on web application testing. I had a few holidays coming up, so it felt like the perfect opportunity to do some “light” reading while away. The book I ended up choosing was the 800-page behemoth that is The Web Application Hacker’s Handbook (WAHH).

It ended up taking me two weeks to read from cover to cover over two separate holidays. Given its reputation in the industry, I wanted to put together a brief overview of how applicable this book actually is for a modern web application security tester in the current landscape.

General Overview

The first thing to address is that the book is clearly outdated, having been published back in 2011. However, I found that the core topics and the thinking process you gain from reading it are still very much applicable today. While the specific technologies might have shifted, the underlying logic of how to pull an application apart remains solid.

Content and Methodology

The book covers all the major pillars of web application testing, ranging from initial reconnaissance and mapping an application to exploiting the most common vulnerabilities. It goes into incredible detail on every topic and offers deep knowledge in areas that are often glossed over in shorter guides.

The Good

I was impressed by how well the core sections have aged. Areas such as injection techniques, authentication, and authorisation are covered in great depth. For me, it served as a brilliant recap of techniques I already knew, but it also pushed me to think about them more structurally.

I also picked up some new applicable skills that I hadn’t used before. One standout was an XSS exploit I like to call “framelocking,” where you can effectively lock a user inside a full-sized iframe using XSS. More importantly, the methodology and approach taught in the book are still spot on. It provides a clear framework for how to conduct an assessment and the specific order in which you should complete your tests to get the best results.

The Bad

Of course, the book does show its age in several places. There is a large section dedicated to browser extensions, but these aren’t the Chrome extensions we use today. Instead, it focuses on legacy technologies like Java Applets, Flash Objects, and Silverlight. If you find one of these in the wild in 2026, you’ve either found a time machine or a very neglected legacy system.

Furthermore, a lot of modern technologies are understandably missing. You won’t find mention of recent developments in client-side attacks, modern cloud-native environments, or the nuances of testing single-page applications (SPAs) that we see every day now.

Overall Verdict

I really enjoyed reading this book, but would I recommend it to someone just starting out in the industry? Probably not as their very first resource. I would suggest something like Bug Bounty Bootcamp first, as it is much more up-to-date and covers the majority of modern technologies.

However, The Web Application Hacker’s Handbook is a classic for a reason. It covers a vast amount of content and, perhaps most importantly, it really helps you develop that essential “hacker’s mindset.”

My Technical Notes

While reading through the 800 pages, I noted down all the areas I found particularly interesting or that were new to me.

1. Fundamentals

DOM and Ajax (Page 62):
The DOM is an abstract representation of HTML that can be manipulated through its API, allowing client-side scripts to access HTML elements. I touched on Ajax at university but had largely forgotten it: it is basically a way for JavaScript to send requests without a page reload, which I can use in my XSS payloads.

Input Locations (Page 98):
I need to make sure I am checking every possible location during an assessment, including every URL string up to the query string, every parameter in the query string or POST body, every cookie, every header that may be processed, and even out-of-band channels from external sources.

ViewState (Page 125):
I found the section on ViewState interesting. It is a hidden AspNET value used to improve server performance and preserve UI elements, containing serialised data stored in base64.

2. Authentication and Logic

Credentials over HTTPS (Page 170):
Even with HTTPS, credentials can be at risk if they are sent as GET requests, included in query strings during redirects, or stored in cookies.

Remember Me (Page 176):
Some “Remember Me” functions are remarkably insecure. I’ll be adding checks to my methodology for insecure cookies that simply use a username or ID.

Impersonation (Page 178):
Some banking apps have impersonation features for performing actions on behalf of users. I’ll be looking for hidden URL functionality, specific cookies, or backdoor passwords that allow admin users to be impersonated.

Stripped Passwords (Page 180):
Some sites truncate passwords to the first n characters or strip unusual characters during sanitisation, which inadvertently makes the passwords much more guessable.

Login Logic Flaws (Page 186):
I’m going to add a few things to my methodology for bypassing logins, such as submitting empty strings, removing the value pair altogether, submitting very long or short values, using strings in number fields, or submitting the same value multiple times.

3. Injection Deep Dives

Base64 Decoding (Page 214):
If base64 decoding gives me gibberish, it might be binary data. Rendering it as hexadecimal might reveal a proper output.

Cookie Scope (Page 245):
I need to check that cookies are only scoped to what is needed. If they are scoped to other domains, they could be captured.

Injecting into INSERT Statements (Page 295):
SQLi isn’t just for reading data. Injecting into an INSERT statement allows you to write your own data if it matches the allowed format.

SQL Wildcards (Page 299):
The % payload is a great way to return a massive number of results since it acts as a wildcard.

Injecting into Numbers (Page 300):
If I can’t inject strings, I can use 51-ASCII(1) to see if it processes it as “2”. Also, I need to remember to URL encode characters like &, =, and + so they aren’t misinterpreted.

Advanced SQL (Page 314):
In number-only fields, you can use ASCII(SUBSTR('Admin',1,1)) to exfiltrate letters by converting them into numbers (e.g., this returns 65).

Hashing for Time Delays (Page 323):
If standard time delays aren’t available, I can try to trigger a hash operation to cause a delay if a specific condition is met.

XPath Injection (Page 344):
XML Path Language is used to navigate XML documents. A payload like ' or 'a' = 'a can be used to bypass logic, or //address/email/text() to retrieve all emails.

LDAP Injection (Page 352):
This is a big one for internal apps using Active Directory. Payloads like *)) can view users outside your permissions, while ))))))) can be used to break the system and check for errors.

4. Advanced Attacks

Parameter Pollution (Page 393-396):
By URL encoding a &, I can try to inject or overwrite backend parameters, like adding isAdmin=true.

SMTP Injection (Page 400):
It might be possible to inject commands into email forms, potentially turning a mail service into an open relay.

XSS through Unicode (Page 463):
Some interpreters might translate URL-encoded Unicode characters into actual HTML tags after they’ve been processed.

XSS Multiple Fields (Page 472):
If there is a length limit, I can split my payload across multiple fields and use /* */ comments to join them.

XSS Reflected to DOM (Page 473):
I can use <script>eval(location.hash.slice(1))</script> to pull a huge payload from the URL hash, bypassing server-side length limits.

XSS to Frame (Page 474):
If a user logs the entire app inside a frame on an insignificant page, it might be possible to log all the traffic passing through that frame.