Customer Reviews

How to Break Software Security

5 star:		(4)
4 star:		(1)
3 star:		(0)
2 star:		(2)
1 star:		(0)

 

 

The book categorizes software testing for security defects into attacks on software dependencies, user interfaces, design and implementation. The book focuses on 19 attacks (one being "overflow input buffers"), which form the core of the book. Parts 2 and 3 of the book explain when and how to apply each attack and what faults they find. Part 4 takes a more hands-on look at how to perform the testing.

In my opinion, the book is too dependent on the Holodeck 1.3 program provided on the CD. Rather than explaining security testing in a tool agnostic way, the book often simply explains how to use Holodeck to perform an attack. I use Linux and Holodeck is Windows only, so it was useless to me. Reviewer Yvonne Eu said the tool did not work in her test environment. Holodeck is currently maintained by Security Innovation who charge $1495 for a single user license, but they also offer a 30 day evaluation license. If the version on the CD does not work for you, these are your two options. The book is a lot less useful if Holodeck does not work for you, so bear this in mind.

The focus on Holodeck also limits the scope of the book. The use of other types of tools such as web proxies, port scanners and tools to exercise user interfaces is not adequately covered.

Finally, I was disappointed by chapter 6, which looks at security testing three applications: Windows Media Player 9.0, Mozilla 1.2.1 (for Windows), and OpenOffice 1.0.2 (for Linux). This is an ideal opportunity to dive down and show how security testing tools should be applied, common pitfalls, and hands-on techniques for finding security issues. Instead, the chapter only explains how attacks should be planned and goes no deeper.

If you are new to security testing and want an overview of some common types of tests that should be run, this book will be useful. If you are interested in using Holodeck for your testing, this book will also be useful. If you do not fall into these categories, there are other books which are a better fit. If you want more detail, I recommend trying one of the Hacking Exposed series.

I'm the type of person who won't buy a tech book unless it's worth reading and referring to, and it didn't take much skimming to realize this was going to be worth it. My opinion hasn't changed since finishing it. I had a specific need for information on non-web application penetration (security) testing and I was surprised to find exactly what I needed in this book, and in a short, easy-to-read package including a CD with two unique tools to help apply what it teaches.

If you're a software tester or in the software quality assurance field, especially if you're interested in security, you need to read this book as it will likely be an eye-opener. It's not full of shocking anecdotes to scare developers into writing better software, it's a handbook of what to look for when testing software after you think you've done all your testing, and at the same time gives developers and project managers good information on how to design, code, and state requirements better.

If you're a security person, especially the burgeoning field of application security, you might also find this book pretty enlightining. Everyone's heard of penetration testing and vulnerability assessment, but typically only in the context of attacking remotely over a network. This book shows you how to attack the (more traditional?) software on your local machine, but not to the level of detail or geekiness of "shellcoding."

While I feel the cover price is a bit steep for such a thin book, especially given the amount of "filler" like illustrations, blank pages, figures, etc., the content is superb and the writing style makes it easy to read. I also appreciate that the points made and examples used tend to get me thinking and I'm able to apply the concepts right away--maybe it's just my "tinkerer" mindset but this book seems to encourage the reader to think outside the box and experiment, which I like. I don't give many 5-star ratings but I think this book deserves it.

The whole book feels like a promotion for Holodeck tool. Some of the chapters are very straightforward: boot your AUT (Application Under Test) from Holodeck and see what happens. However, the version of the tool supplied with the book isn't supported by anybody and, sure enough, it doesn't work with my AUT. The supported one is above $1K for single user licence...
Though as much as I appreciate the general ideas about blackbox security testing Whittaker is voicing in this book, I feel it's just not enough there for its price. :(

`How to Break Software Security' is a most unique book.

There are a lot of security books.
There are a growing number of books about writing secure code.

But `How to Break Software Security' is the first on the topic of testing the software after the programmer has supposedly used secure programming techniques.

The problem is that even if a programmer reads all of the required texts on writing secure code, there are still a number of ways that the application can be broken. The book deals with 19 unique attacks that can be mounted against various software applications.

The book describes attacks that can come from all sides. From attacking the software dependencies, implementation, design, to bogus error messages, fake data sources and more.

Anyone involved with software application security testing should definitely read `How to Break Software Security'.

The software community has been awaiting for a book like this. It's a almost perfect intro to software security concepts. Again, Whittaker keeps it low in pages and words. In my opinion, the way books should be written (except ones purely theoretical).
Once again Whittaker approachs is hands-on examples. Even if some examples don't apply to modern software the idea behind you is to get you thinking. I've applied the techniques in this book with extremely great results.

James Whittaker has taken the approach and the tools he introduced in "How to Break Software: A Practical Guide to Testing" (ISBN 0201796198), and has teamed with coauthor Herbert Thompson to adapt them to security testing. In this book the software under test (or attack, since that is the underlying approach) is primarily in the Microsoft environment. That the principles can be applied to any operating system or environment is evident in one scenario where Linux-based OpenOffice is attacked. The the fault model provided early in the book can form the basis for any software test strategy with a goal to uncover and exploit vulnerabilities.

The approach itself is to create a plan, then systematically attack. The areas of vulnerability covered include unanticipated input scenarios (which, even after decades, is still an exposure in too many applications and operating systems), find and attack design flaws and implementation anomalies, and leave no potential vulnerability untested. Among these are the usual exposed ports and default names; however, there are exploits based on data, time stamping and other less common areas that are overlooked by testing professionals - and that is one of the main audiences of this book.

While the techniques and the approach in this book are sound, I would have liked the attacks presented as formal test cases, which would be more meaningful to the testing professionals who will benefit the most from this book. However, the authors do introduce the concept of security testing as an element of QA, adding to the small (but hopefully growing) body of knowledge to be used by QA. I recommend this book, as well as "Exploiting Software: How to Break Code" (ISBN 0201786958) as two books that should be read and used by software testing practitioners. The information combined in these books will-if put into practice-significantly improve the quality and security of software that is released into production.

How to Break Software Security is a good book. Handy. It is a little more than entry level on the topic and not much more than that, but at the same time if enough developers read it things should improve.