Testing Web Security-Assessing the Security of Web Sites and Applications Steven Splaine Wiley Publishing, Inc. Publisher: Robert Ipsen Editor: Carol Long Developmental Editor: Scott Amerman Managing Editor: John Atkins New Media Editor: Brian Snapp Text Design & Composition: Wiley Composition Services Designations used by companies to distinguish their products are often claimed as trademarks. In all instances where Wiley Publishing, Inc., is aware of a claim, the product names appear in initial capital or ALL CAPITAL LETTERS. Readers, however, should contact the appropriate companies for more complete information regarding trademarks and registration. This book is printed on acid-free paper. Copyright © 2002 by Steven Splaine. ISBN:0471232815 All rights reserved. Published by Wiley Publishing, Inc., Indianapolis, Indiana Published simultaneously in Canada No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4470. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspointe Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4447, Email: <permcoordinator@wiley.com>. Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages. For general information on our other products and services, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002. Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. Library of Congress Cataloging-in-Publication Data: 0-471-23281-5 Printed in the United States of America 10 9 8 7 6 5 4 3 2 1 To my wife Darlene and our sons, Jack and Sam, who every day remind me of just how fortunate I am. To the victims and heroes of September 11, 2001, lest we forget that freedom must always be vigilant. Acknowledgments The topic of Web security is so large and the content is so frequently changing that it is impossible for a single person to understand every aspect of security testing. For this reason alone, this book would not have been possible without the help of the many security consultants, testers, webmasters, project managers, developers, DBAs, LAN administrators, firewall engineers, technical writers, academics, and tool vendors who were kind enough to offer their suggestions and constructive criticisms, which made this book more comprehensive, accurate, and easier to digest. Many thanks to the following team of friends and colleagues who willingly spent many hours of what should have been their free time reviewing this book and/or advising me on how best to proceed with this project. James Bach Joey Maier Rex Black Brian McCaughey Ross Collard Wayne Middleton Rick Craig Claudette Moore Dan Crawford David Parks Yves de Montcheuil Eric Patel Mickey Epperson Roger Rivest Danny Faught Martin Ryan Paul Gerrard John Smentowski Stefan Jaskiel John Splaine Jeff Jones Herbert Thompson Philip Joung Michael Waldmann A special thank-you goes to my wife Darlene and our sons Jack and Sam, for their love and continued support while I was writing this book. I would especially like to thank Jack for understanding why Daddy couldn't go play ball on so many evenings. Professional Acknowledgment I would like to thank everyone who helped me create and then extend Software Quality Engineering's Web Security Testing course (www.sqe.com), the source that provided much of the structure and content for this book. Specifically, many of SQE's staff, students, and clients provided me with numerous suggestions for improving the training course, many of which were subsequently incorporated into this book. STEVEN SPLAINE is a chartered software engineer with more than twenty years of experience in project management, software testing and product development. He is a regular speaker at software testing conferences and lead author of The Web Testing Handbook. Foreword As more and more organizations move to Internet-based and intranet-based applications, they find themselves exposed to new or increased risks to system quality, especially in the areas of performance and security. Steven Splaine's last book, The Web Testing Handbook, provided the reader with tips and techniques for testing performance along with many other important considerations for Web testing, such as functionality. Now Steve takes on the critical issue of testing Web security. Too many users and even testers of Web applications believe that solving their security problems merely entails buying a firewall and connecting the various cables. In this book, Steve identifies this belief as the firewall myth, and I have seen victims of this myth in my own testing, consulting, and training work. This book not only helps dispel this myth, but it also provides practical steps you can take that really will allow you to find and resolve security problems throughout the network. Client-side, server-side, Internet, intranet, outside hackers and inside jobs, software, hardware, networks, and social engineering, it's all covered here. How should you run a penetration test? How can you assess the level of risk inherent in each potential security vulnerability, and test appropriately? When confronted with an existing system or building a new one, how do you keep track of everything that's out there that could conceivably become an entryway for trouble? In a readable way, Steve will show you the ins and outs of Web security testing. This book will be an important resource for me on my next Web testing project. If you are responsible for the testing or security of a Web system, I bet it will be helpful to you, too. Rex Black Rex Black Consulting Bulverde, Texas Preface As the Internet continues to evolve, more and more organizations are replacing their placeholder or brochureware Web sites with mission-critical Web applications designed to generate revenue and integrate with their existing systems. One of the toughest challenges facing those charged with implementing these corporate goals is ensuring that these new storefronts are safe from attack and misuse. Currently, the number of Web sites and Web applications that need to be tested for security vulnerabilities far exceeds the number of security professionals who are sufficiently experienced to carry out such an assessment. Unfortunately, this means that many Web sites and applications are either inadequately tested or simply not tested at all. These organizations are, in effect, playing a game of hacker roulette, just hoping to stay lucky. A significant reason that not enough professionals are able to test the security of a Web site or application is the lack of introductory-level educational material. Much of the educational material available today is either high-level/strategic in nature and aimed at senior management and chief architects who are designing the high-level functionality of the system, or low-level/extremely technical in nature and aimed at experienced developers and network engineers charged with implementing these designs. Testing Web Security is an attempt to fill the need for a straightforward, easy-to-follow book that can be used by anyone who is new to the security-testing field. Readers of my first book that I coauthored with Stefan Jaskiel will find I have retained in this book the checklist format that we found to be so popular with The Web Testing Handbook (Splaine and Jaskiel, 2001) and will thereby hopefully make it easier for security testers to ensure that the developers and network engineers have implemented a system that meets the explicit (and implied) security objectives envisioned by the system's architects and owners. Steven Splaine Tampa, Florida Table of Contents Testing Web Security—Assessing the Security of Web Sites and Applications Foreword Preface Part I - An Introduction to the Book Chapter 1 - Introduction Part II - Planning the Testing Effort Chapter 2 - Test Planning Part III - Test Design 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 Part IV - Test Implementation Chapter 9 - Assessment and Penetration Options Chapter 10 - Risk Analysis Epilogue Part V - 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 Additional Resources Index List of Figures List of Tables List of Sidebars 1 Part I: An Introduction to the Book Chapter List Chapter 1: Introduction 2 Chapter 1: Introduction Overview 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 www.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 (www.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 (www.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 of recovering 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 (www.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 3 poorly designed Web application running on the Web site, an oversight in the firewall's configuration, or a disgruntled employee working from the inside. THE FIREWALL MYTH The firewall myth is alive and well, as the following two true conversations illustrate. Anthony is a director at a European software-testing consultancy, and Kevin is the owner of a mass-marketing firm based in Florida. Anthony: We just paid for someone to come in and install three top-of-the-line firewalls, so we're all safe now. Security tester: Has anybody tested them to make sure they are configured correctly? Anthony: No, why should we? Kevin: We're installing a new wireless network for the entire company. Security tester: Are you encrypting the data transmissions? Kevin: I don't know; what difference does it make? No one would want to hack us, and even if they did, our firewall will protect us. 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), [...]... testing objectives (or goals) was explicitly defined in the test plan's introduction, this section can be used to restate those objectives in much more detail For example, the introduction may have stated that security testing will be performed on the wiley. com Web site, whereas in this section, the specific hardware and software items that make up the wiley. com Web site may be listed For smaller Web. .. that must pass before more expensive, thorough testing is performed One consideration that will have a huge impact on the effectiveness of any internally staffed security -testing effort is the choice of who will actually do the testing The dilemma that many organizations face is that their security -testing needs are sporadic Often extensive security- oriented testing is not needed for several months and... and security officers of a Web site who are ultimately responsible for the security of their site Because these people might not have a strong technical background and, consequently, not be aware of all the types of threats that their site faces, this book seeks to make these critical decision makers aware of what security testing entails and thereby enable them to delegate (and fund) a security -testing. .. detailed as a book on how to build a Web site 8 Summary With the heightened awareness for the need to securely protect an organization's electronic assets, the supply of available career security veterans is quickly becoming tapped out, which has resulted in an influx of new people into the field of security testing This book seeks to provide an introduction to Web security testing for those people with relatively... even contradictory is not a trivial task, but even with clearly defined requirements, a securitytesting team faces an additional challenge Security testing is primarily concerned with testing that a system does not do something (negative testing) -as opposed to confirming that the system can do something (positive testing) Unfortunately, the list of things that a system (or someone) should not do is... 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... Features to Be Tested A system's security is only as strong as its weakest link Although this may be an obvious statement, it's surprising how frequently a security -testing effort is directed to only test some and not all of the following features of a Web site: Network security (covered in Chapter 3) System software security (covered in Chapter 4) Client-side application security (covered in Chapter 5)... feature of security testing, the security -testing team should take a reality check Just how likely is it that they have the sufficient time and funding to test everything? Most likely the security -testing team will not have all the resources they would like, in which case choices must be made to decide which areas of the system will be drilled and which areas will receive comparatively light testing Ideally,... 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. .. of the security -testing effort in order to provide better project control, the members of a security -testing CCB should bear in mind that unlike the typical end user, an attacker is not bound by a project's scope or the decisions of a CCB This requires them to perhaps be a little more flexible than they would normally be when faced with a nonsecurity orientation change request After all, the testing . ins and outs of Web security testing. This book will be an important resource for me on my next Web testing project. If you are responsible for the testing or security of a Web system, I bet. considerations for Web testing, such as functionality. Now Steve takes on the critical issue of testing Web security. Too many users and even testers of Web applications believe that solving their security. Testing Web Security- Assessing the Security of Web Sites and Applications Steven Splaine Wiley Publishing, Inc. Publisher: Robert Ipsen Editor: