In all, I was significantly disappointed. First off, the book is pretty short for the price. 158 pages of content. I read it cover-to-cover in one sitting. The chapters of material are weak, especially as the book wears on. By the time they get to the very end (Web Services) they have dropped the whole attack format altogether. In fact, when they introduce cross-site tracing, they completely punt. They tell you the simplest basics about the problem, and then refer the reader to the original whitepaper for more information. I haven’t found cross-site tracing to be a particularly viable attack, myself, so it’s not a terrible loss.
Appendix A is a republished history lesson that Whittaker wrote for IEEE in 2003. It is an oblique bit of value. Not completely off-topic, but not squarely on-topic, either. To me it feels like filler. Appendix B is a list of bugs in their demo app. That’s handy. Appendix C is high value, but short. It’s a list of web hacking tools and brief descriptions of how to use them. This is the only section that gives you hope that you can do what they talk about in the book. The descriptions are brief, unfortunately, and don’t do the tools justice.
Everything they describe is totally Windows-focused. When they talk about, for example, protecting against sample code left by default installations, they have only one useful piece of advice: IISLockdown. That overlooks the fact that the majority of web servers (accoding to www.netcraft.com) do not run IIS, and that the sample code we’re worried about didn’t come from IIS in the first place. Vulnerable sample code comes from WebSphere, WebLogic, JBoss, .NET, or some other middleware. In further irony, they don’t talk about how to secure PHP against attacks on its defaults, even though their demo application is written in PHP. When they talk about SQL injection, most of the examples they give are Microsoft SQL Server specific, and do not work generally on many databases. The Microsoft focus isn’t just a technical criticism. One of the only security experts they refer to is Mike Howard at Microsoft who, although a bona fide security expert, is not the only source of decent security information in the world.
If you use a Mac, or Linux, or test any sort of system that is based on something other than Windows and IIS, this book has less value for you. Most of the tools on the CD are Windows-only and closed-source. It’s up to you to adapt their advice to fit your needs. For example, you have to know to get the LiveHTTPHeaders extension for Firefox. They only recommend the IELiveHeaders tool for IE.
There’s too much pining away for the old days and comparing to older programming paradigms. These authors have been around a long time, and their security pedigrees are good. Unfortunately, saying “the web is different” is not actually important or useful. For most people writing insecure web applications today, “the web” is all they’ve known in their programming career. It’s not “different” because they don’t know anything else.
The “How to Protect” discussion at the end of most attacks is usually useless. For example they have a whopping 2 sentences on p.35 about how important it is to protect against bad input. Duh. If only it were so simple that all we had to do was say “input *must* be validated” and leave it at that. The fact is, this book is about how to “break” software, not “do it right.” A text on “doing it right” is much larger (c.f., Viega & McGraw’s Building Secure Software or Hoglund and McGraw’s Software Security: Build Security In). These little snippets should have been omitted. They’re too short to be useful, and they just push up the page count needlessly.
The book has some pretty naive advice that is either clumsy, unrealistic, or just plain ignorant of what usually goes on in industry. When talking about bypassing JavaScript checking, they overlook the ability of Paros (a proxy they mention in other places) to "trap" requests and modify values. Instead, they suggest saving the HTML as a file and editing the JavaScript out by hand, or disabling JavaScript altogether. The former is cumbersome and the latter usually renders a page unusable. They also suggest that it's better to write software with only one programming language, to avoid cross-language bugs (like NULL character interpretation). They immediately admit that this advice isn't very practical, so why bother saying it in the first place? It's kinda like saying "only hire left-handed programmers" or something else equally improbable. Either provide useful advice, or don't bother.Occasionally they make absolutely absurd statements. They say that the buffer overflow attack is the easiest of all the attacks to execute. I suppose that’s true if you have no interest in actually ‘succeeding’ with it. It’s far more difficult (compared to, say cross-site scripting, SQL injection, and cookie poisoning) to actually exploit. Furthermore, when you’re a black-box tester (i.e. without access to server logs and insider information), determining that the attack string you sent caused a buffer overflow, instead of some other server side error, is not at all obvious in most apps. It’s not like it comes back displaying a web page saying “segmentation violation.” In the handful of places they acknowledge the existance of Unix, they give dumb examples of unix things to do, like looking at the /etc/passwd file (which hasn’t had passwords in it on modern UNIX for nearly 10 years), and running the “finger” command. I mean, really, come on.
My final criticism is that a software tester whose job is testing web software won’t get much out of this book unless she is starting at absolute zero. If you have never tested a web app for security before, this book will introduce a few new concepts. The attack descriptions, though, are brief and impractical. A software tester who has a job to do will want to take the lessons in this book and make regression tests, interactive security tests, and self-contained scripts that can be used to repeatedly demonstrate the performance of a web application. All the advice in this book is for interactive testing in a very ad hoc, one-off sort of way. Systematizing it is an exercise left entirely up to the reader.
Recognize my bias as a reviewer: I am a security consultant who does this stuff for a living, and I am also an author. My standards are high. I also, however, work with and train developers and testers who are not security specialists. The information in this book is beneath any security specialist, but is not sufficiently specific and practical for a software professional. I can’t really see a good audience for this book. For my money, the “Hacking Exposed” book by Scambray, Schema, and Sima is a better value. I have no relationship to them. I just bought both books, read them and like the “Hacking Exposed” book better.