Hunting Security Bugs (Developer Reference) (英語) ペーパーバック – 2006/9/27
Kindle 端末は必要ありません。無料 Kindle アプリのいずれかをダウンロードすると、スマートフォン、タブレットPCで Kindle 本をお読みいただけます。
Learn how to think like an attacker—and identify potential security issues in your software. In this essential guide, security testing experts offer practical, hands-on guidance and code samples to help you find, classify, and assess security bugs before your software is released.
Discover how to:
- Identify high-risk entry points and create test cases
- Test clients and servers for malicious request/response bugs
- Use black box and white box approaches to help reveal security vulnerabilities
- Uncover spoofing issues, including identity and user interface spoofing
- Detect bugs that can take advantage of your program’s logic, such as SQL injection
- Test for XML, SOAP, and Web services vulnerabilities
- Recognize information disclosure and weak permissions issues
- Identify where attackers can directly manipulate memory
- Test with alternate data representations to uncover canonicalization issues
- Expose COM and ActiveX repurposing attacks
PLUS—Get code samples and debugging tools on the Web
Bryan Jeffries is a software engineer responsible for driving security testing on Microsoft SharePoint Products and Technologies.
One of the challenges that faces any quality assurance engineer or Test engineer, or whatever our industry has chosen to call us this year is that we are constantly tasked with trying to "test in security" or "find the flaws in the product" after it has already been coded. While this is clearly a PART of our jobs, it is by no means the most important part. This book addresses what I consider to be a much higher priority for the Test Org generally, and Test Engineers specifically: helping reduce security vulnerabilities before they are coded into the product to begin with: as features are being spec'd and as code is being designed.
This book is not a simple check-list testers can use to say "Yes, my feature is secure, Ship It". Rather, it helps place Test into the frame of mind of a hacker, it gives test a set of tools to help find security issues, it outlines an approach to software Test that will cause fewer security issues to be coded at all, let alone have to be fixed post code-complete (or in a Service Pack). Used in conjunction with other test books like _How to Break Software Security_ by James A. Whittaker, this book will help ship more secure products.
Incidentally, I expect hackers will be reading this book in an effort to better understand the science of hunting security bugs, as well as the tools we use to do so - so if you're not using it, I'd expect your attackers will be thankful...
The authors proceeded to give a logical path for working toward looking at all the areas where an application might be open to an attack. The authors uses thread models to help flush out the design of an application and explains why they are valuable and how to use them. They then get into looking at entry points and point out areas where you might not realize that you have one. They continue with a discussion on how a malicious client and server could be use to comprise your security. Next they cover ways that someone could fool the user into giving up information such as with spoofing and information disclosure, They then get into discussions about techniques such as buffer overflows, stack and heap manipulation, format string attack and script attacks including XML issues. Along with this you'll find information on permissions, areas for denial of services as well as ActiveX attacks. Finally, you find a very good checklist for doing a systematic approach to checking your security. The topics are well written and provide plenty of examples as well as thoughts about how to deal with the topic.
Even if you don't read every chapter there is plenty of information for any particular area that you are interested in. It makes a great book to have on your shelve when you need to brush up or learn about a particular topic.
After reading the book, I contacted one of the authors and asked him to present to my team. Yes, I work at the same company but that didn't influence my decision to buy the book especially since it was my own money going to purchase the book. He consented to giving us a presentation and his talk has inspired my entire team to ask for a copy of his book. Being that I had already read about half of it, I knew what he was talking about so it reinforced my opinion of the book. I would say that is a pretty good indication of how good the book is when an entire team asked for a copy.
You won't be sorry if you purchase this book.