- Shopping Bag ( 0 items )
PART ONE: AN INTRODUCTION TO THE BOOK.
PART TWO: PLANNING THE TESTING EFFORT.
PART THREE: TEST DESIGN.
System Software Security.
Client-Side Application Security.
Server-Side Application Security.
Sneak Attacks: Guarding Against the Less-Thought-of Security Threats.
Intruder Confusion, Detection, and Response.
PART FOUR: TEST IMPLEMENTATION.
Assessment and Penetration Options.
PART FIVE: APPENDIXES.
Appendix A: An Overview of Network Protocols, Addresses, and Devices.
Appendix B: SANS Institute Top 20 Critical Internet Security Vulnerabilities.
Appendix C: Test-Deliverable Templates.
The following are some sobering statistics and stories that seek to illustrate the growing need to assess the security of Web sites and applications. The 2002 Computer Crime and Security Survey conducted by the Computer Security Institute (in conjunction with the San Francisco Federal Bureau of Investigation) reported the following statistics (available free of charge via gocsi.com):
* Ninety percent of respondents (primarily large corporations and government agencies) detected computer security breaches within the last 12 months. * Seventy-four percent of respondents cited their Internet connection as a frequent point of attack, and 40 percent detected system penetration from the outside. * Seventy-five percent of respondents estimated that disgruntled employees were the likely source of some of the attacks that they experienced.
The following lists the number of security-related incidents reported to the CERT Coordination Center (cert.org) for the previous 4 1/2 years:
* 2002 (Q1 and Q2)-43,136 * 2001-52,658 * 2000-21,756 * 1999-9,859 * 1998-3,734
In February 2002, Reuters (reuters.co.uk) reported that "hackers" forced CloudNine Communications-one of Britain's oldest Internet service providers (ISPs) -out of business. CloudNine came to the conclusion that the cost ofrecovering from the attack was too great for the company to bear, and instead elected to hand over their customers to a rival ISP.
In May 2002, CNN/Money (money.cnn.com) reported that the financing division of a large U.S. automobile manufacturer was warning 13,000 people to be aware of identity theft after the automaker discovered "hackers" had posed as their employees in order to gain access to consumer credit reports.
The Goals of This Book
The world of security, especially Web security, is a very complex and extensive knowledge domain to attempt to master-one where the consequences of failure can be extremely high. Practitioners can spend years studying this discipline only to realize that the more they know, the more they realize they need to know. In fact, the challenge may seem to be so daunting that many choose to shy away from the subject altogether and deny any responsibility for the security of the system they are working on. "We're not responsible for security-somebody else looks after that" is a common reason many members of the project team give for not testing a system's security. Of course, when asked who the somebody else is, all too often the reply is "I don't know," which probably means that the security testing is fragmented or, worse still, nonexistent.
A second hindrance to effective security testing is the naive belief held by many owners and senior managers that all they have to do to secure their internal network and its applications is purchase a firewall appliance and plug it into the socket that the organization uses to connect to the Internet. Although a firewall is, without doubt, an indispensable defense for a Web site, it should not be the only defense that an organization deploys to protect its Web assets. The protection afforded by the most sophisticated firewalls can be negated by a poorly designed Web application running on the Web site, an oversight in the firewall's configuration, or a disgruntled employee working from the inside.
This book has two goals. The first goal is to raise the awareness of those managers responsible for the security of a Web site, conveying that a firewall should be part of the security solution, but not the solution. This information can assist them in identifying and planning the activities needed to test all of the possible avenues that an intruder could use to compromise a Web site. The second goal is aimed at the growing number of individuals who are new to the area of security testing, but are still expected to evaluate the security of a Web site. Although no book can be a substitute for years of experience, this book provides descriptions and checklists for hundreds of tests that can be adapted and used as a set of candidate test cases. These tests can be included in a Web site's security test plan(s), making the testing effort more comprehensive than it would have been otherwise. Where applicable, each section also references tools that can be used to automate many of these tasks in order to speed up the testing process.
The Approach of This Book
Testing techniques can be categorized in many different ways; white box versus black box is one of the most common categorizations. Black-box testing (also known as behavioral testing) treats the system being tested as a black box into which testers can't see. As a result, all the testing must be conducted via the system's external interfaces (for example, via an application's Web pages), and tests need to be designed based on what the system is expected to do and in accordance with its explicit or implied requirements. White-box testing assumes that the tester has direct access to the source code and can look into the box and see the inner workings of the system. This is why white-box testing is sometimes referred to as clear-box, glass-box, translucent, or structural testing. Having access to the source code helps testers to understand how the system works, enabling them to design tests that will exercise specific program execution paths. Input data can be submitted via external or internal interfaces. Test results do not need to be based solely on external outputs; they can also be deduced from examining internal data stores (such as records in an application's database or entries in an operating system's registry).
In general, neither testing approach should be considered inherently more effective at finding defects than the other, but depending upon the specific context of an individual testing project (for example, the background of the people who will be doing the testing-developer oriented versus end-user oriented), one approach could be easier or more cost-effective to implement than the other. Beizer (1995), Craig et al. (2002), Jorgensen (2002), and Kaner et al. (1999) provide additional information on black-box and white-box testing techniques.
Gray-box testing techniques can be regarded as a hybrid approach. In other words, a tester still tests the system as a black box, but the tests are designed based on the knowledge gained by using white-box-like investigative techniques. Gray-box testers using the knowledge gained from examining the system's internal structure are able to design more accurate/focused tests, which yield higher defect detection rates than those achieved using a purely traditional black-box testing approach. At the same time, however, gray-box testers are also able to execute these tests without having to use resource-consuming white-box testing infrastructures.
Wherever possible, this book attempts to adopt a gray-box approach to security testing. By covering the technologies used to build and deploy the systems that will be tested and then explaining the potential pitfalls (or vulnerabilities) of each technology design or implementation strategy, the reader will be able to create more effective tests that can still be executed in a resource-friendly black-box manner.
This book stops short of describing platform- and threat-specific test execution details, such as how to check that a Web site's Windows 2000/IIS v5.0 servers have been protected from an attack by the Nimda worm (for detailed information on this specific threat, refer to CERT advisory CA-2001-26-cert.org). Rather than trying to describe in detail the specifics of the thousands of different security threats that exist today (in the first half of 2002 alone, the CERT Coordination Center recorded 2,148 reported vulnerabilities), this book describes generic tests that can be extrapolated and customized by the reader to accommodate individual and unique needs. In addition, this book does not expand on how a security vulnerability could be exploited (information that is likely to be more useful to a security abuser than a security tester) and endeavors to avoid making specific recommendations on how to fix a security vulnerability, since the most appropriate remedy will vary from organization to organization and such a decision (and subsequent implementation) would generally be considered to be the role of a security designer.
How This Book Is Organized
Although most readers will probably find it easier to read the chapters in sequential order, this book has been organized in a manner that permits readers to read any of the chapters in any order. Depending on the background and objectives of different readers, some may even choose to skip some of the chapters. For example, a test manager who is well versed in writing test plans used to test the functionality of a Web application may decide to skip the chapter on test planning and focus on the chapters that describe some of the new types of tests that could be included in his or her test plans. In the case of an application developer, he or she may not be concerned with the chapter on testing a Web site's physical security because someone else looks after that (just so long as someone actually does) and may be most interested in the chapters on application security.
To make it easier for readers to hone in on the chapters that are of most interest to them, this book has been divided into four parts. Part 1 is comprised of this chapter and provides an introduction and explanation of the framework used to construct this book.
Chapter 2, "Test Planning," provides the material for Part 2, "Planning the Testing Effort," and looks at the issues surrounding the planning of the testing effort.
Part 3, "Test Design," is the focus of this book and therefore forms the bulk of its content by itemizing the various candidate tests that the testing team should consider when evaluating what they are actually going to test as part of the security-testing effort of a Web site and its associated Web application(s). Because the testing is likely to require a variety of different skill sets, it's quite probable that different people will execute different groups of tests. With this consideration in mind, the tests have been grouped together based on the typical skill sets and backgrounds of the people who might be expected to execute them. This part includes the following chapters:
Chapter 3: Network Security Chapter 4: System Software Security Chapter 5: Client-Side Application Security Chapter 6: Server-Side Application Security Chapter 7: Sneak Attacks: Guarding against the Less-Thought-of Security Threats Chapter 8: Intruder Confusion, Detection, and Response
Having discussed what needs to be tested, Part 4, "Test Implementation," addresses the issue of how to best execute these tests in terms of who should actually do the work, what tools should be used, and what order the tests should be performed in (ranking test priority). This part includes the following chapters:
Chapter 9: Assessment and Penetration Options
Chapter 10: Risk Analysis
As a means of support for these 10 chapters, the appendix provides some additional background information, specifically: a brief introduction to the basics of computer networks as utilized by many Web sites (in case some of the readers of this book are unfamiliar with the components used to build Web sites), a summarized list of the top-20 critical Internet security vulnerabilities (as determined by the SANS Institute), and some sample test deliverable templates (which a security-testing team could use as a starting point for developing their own customized documentation).
Finally, the resources section not only serves as a bibliography of all the books and Web sites referenced in this book, but it also lists other reference books that readers interested in testing Web security may find useful in their quest for knowledge.
Terminology Used in This Book
The following two sections describe some of the terms used in this book to describe the individuals who might seek to exploit a security vulnerability on a Web site-and hence the people that a security tester is trying to inhibit-and the names given to some of the more common deliverables that a security tester is likely to produce.
Hackers, Crackers, Script Kiddies, and Disgruntled Insiders
The term computer hacker was originally used to describe someone who really knew how the internals of a computer (hardware and/or software) worked and could be relied on to come up with ingenious workarounds (hacks) to either fix a problem with the system or extend its original capabilities. Somewhere along the line, the popular press relabeled this term to describe someone who tries to acquire unauthorized access to a computer or network of computers.
The terminology has become further blurred by the effort of some practitioners to differentiate the skill levels of those seeking unauthorized access. The term cracker is typically used to label an attacker who is knowledgeable enough to create his or her own hacks, whereas the term script kiddie is used to describe a person who primarily relies on the hacks of others (often passed around as a script or executable). The situation becomes even less clear if you try to pigeonhole disgruntled employees who don't need to gain unauthorized access in order to accomplish their malicious goals because they are already authorized to access the system.
Not all attackers are viewed equally. Aside from their varying technical expertise, they also may be differentiated by their ethics. Crudely speaking, based on their actions and intentions, attackers are often be categorized into one of the following color-coded groups:
White-hat hackers. These are individuals who are authorized by the owner of a Web site or Web-accessible product to ascertain whether or not the site or product is adequately protected from known security loopholes and common generic exploits. They are also known as ethical hackers, or are part of a group known as a tiger team or red team.
Gray-hat hackers. Also sometimes known as wackers, gray-hat hackers attack a new product or technology on their own initiative to determine if the product has any new security loopholes, to further their own education, or to satisfy their own curiosity. Although their often-stated aim is to improve the quality of the new technology or their own knowledge without directly causing harm to anyone, their methods can at times be disruptive.
Excerpted from Testing Web Security by Steven Splaine Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Posted February 25, 2004
Before I read Steve¿s book, I thought that testing the security of a Web site required huge amounts of technical knowledge including how certain operating systems, web servers, etc., actually worked. Having read the book, I realise that someone needs to know ¿ but it needn¿t be me. As a tester, my job is to see if the security measures that have been put into place actually do what they are supposed to and in this context the book exceeds my requirements and expectations. In addition, one of the problems in testing security is trying to ensure that the site does not open itself up to any unauthorised activity ¿ accidental or not. How do you ensure `complete coverage¿ of the virtually infinite number of event combinations and therefore test cases? This problem is addressed in the Test Planning and Risk Analysis sections and placed properly and pragmatically into context. Then we get into the meat of test design. I like the way we start with scoping. What are we trying to secure and from what or whom? To answer the latter part of the question, the book delves into types of attacks ¿ which then helps us to think about what and how to test. I particularly like the checklists (OK, I¿m a checklist fan) and the lists of software tools which are available to carry out things like IP address sweeps, port scans, etc. This part of the book has separate chapters for networks, system software, client and server-side application software. Each chapter is virtually stand-alone which makes it a good reference as well as a good read. I also like the fact that Steve has not left out the social engineering aspect of security. Finally, Test Implementation addresses the usual practical problems associated with test execution but with all the emphasis on security. Steve Splaine has distilled into one book enough information to give testers and test managers confidence in the planning, design and execution of Web security testing. An excellent read and reference.Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.
Posted September 25, 2003
I agree with the author that having a super-powered firewall doesn¿t excuse the organization from conducting tests or exploring additional avenues to supplement the firewall. The author also provides flexible descriptions and checklists for creating test cases and conducting tests. Each chapter has a checklist covering the various aspects of the test process from planning to intrusion detection. Organizations with a process model in place will find the material supportive of such efforts and maybe even making it easier because of the lists of example tools and software products for managing reporting and schedules. You don't have to read the book front-to-back because each chapter stands alone with or without previous chapters. The first two chapters address vocabulary, test plans and planning, and general project management activities. The meat is in Part 3, Test Design, beginning with chapter 3, which addresses scoping and conducting a network assessment. Chapter 4 focuses on system software and related tools. The next two chapters look at client-side and server-side applications to ensure the system is designed to function correctly for its users while guarding its castle to prevent the evil ones from breaking in. Mother Nature might pay a visit or another big blackout could happen and those guards need to be prepared to react, hence Chapter 7 prepares a team for such events as well as various ways the bad guys might do a sneak attack. Mysterious intruders and audit trails sounds like a case for Sherlock Holmes as Chapter 8 directions on detecting unauthorized intruders, responding to an attack, and assessing the damage. Those who haven¿t formed a team might want to leap into Chapter 9, which provides staffing options for in-house and outsourcing. It also discusses the process of selecting tools. In the last chapter, get the lowdown on doing a risk analysis to be prepared in for the likelihood of changed plans (which we know happens often). Doing such an analysis is a step toward to having a well-planned test schedule ensure the areas that pose the greatest risks are done early in the process while the lesser important items are done near the end of the test period. The appendices provide an overview of network protocols, addresses, and devices; a list of the most critical Internet security vulnerabilities; and example templates for testing documentation. Those who need more in-depth information can reference the resources for further reading via books and Web sites. Don't expect programming references because that's not the point of this particular book. If the thought of security is daunting, this book is a good introduction to the topic. It¿s appropriate for organizations creating a new testing team; teams responsible for conducting testing assessments; and testing managers, project managers, and test teams that are new to testing security. Directors, executives, and other top level managers who are responsible for Web site security will also benefit. Any technical terms that pop up are clearly defined without the dull writing that makes eyes glaze over when reading a technical book. The use of sidebars, checklists, headers, examples, and figures provide a nice balance in presenting the material without losing the reader. The book is practical for anyone who needs a general reference on Web security and wants to know how it works.Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.