Fast Track How to Implement the Guidance
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
Improving Web Application Security: Threats and Countermeasures
J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan
Published: June 2003
See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.
See the Landing Page for the starting point and a complete overview of Improving Web Application Security: Threats and Countermeasures.
Summary: This fast track has highlighted the basic approach taken by the guide to help you design, and develop.
Goal and Scope
The Holistic Approach
Securing Your Network
Securing Your Host
Securing Your Application
Applying the Guidance to Your Product Life Cycle
Implementing the Guidance
Who Does What?
This guide helps you to design, build, and configure hack-resilient Web applications. These applications reduce the likelihood of successful attacks and mitigate the extent of damage should an attack occur. Figure 1 shows the scope of the guide and its three-layered approach: securing the network, securing the host, and securing the application.
The scope of the guide
The guide addresses security across the three physical tiers shown in Figure 1. It covers the Web server, remote application server, and database server. At each tier, security is addressed at the network layer, host layer, and application layer. Figure 1 also shows the configuration categories that the guide uses to organize the various security configuration settings that apply to the host and network, and the application vulnerability categories, which are used to structure application security considerations.
Web application security must be addressed across application tiers and at multiple layers. An attacker can exploit weaknesses at any layer. For this reason, the guide takes a holistic approach to application security and applies it at all three layers. This holistic approach to security is shown in Figure 2.
A holistic approach to security
Figure 2 shows the multiple layers covered by the guide, including the network, host, and application. The host layer covers the operating system, platform services and components, and run-time services and components. Platform services and components include Microsoft® SQL Server® 2000 and Enterprise Services. Run-time services and components include ASP.NET and .NET code access security among others.
The three core elements of a secure network are the router, firewall, and switch. The guide covers all three elements. Table 1 provides a brief description of each element.
Table 1 Network Security Elements
|Router||Routers are your outermost network ring. They direct packets to the ports and protocols that you have prepared your applications to work with. Insecure TCP/IP protocols are blocked at this ring.|
|Firewall||The firewall blocks those protocols and ports that the application does not use. Additionally, firewalls enforce secure network traffic by providing application-specific filtering to block malicious communications.|
|Switch||Switches are used to separate network segments. They are frequently overlooked or over trusted.|
The host includes the operating system and .NET Framework, together with associated services and components. Whether the host is a Web server running IIS, an application server running Enterprise Services, or a database server running SQL Server, the guide adheres to a general security methodology that is common across the various server roles and types.
The guide organizes the precautions you must take and the settings you must configure into categories. By using these configuration categories, you can systematically walk through the securing process from top to bottom or pick a particular category and complete specific steps.
Figure 3 shows the configuration categories used throughout Part IV of this guide, "Securing Your Network, Host, and Application."
Host security categories
The guide defines a set of application vulnerability categories to help you design and build secure Web applications and evaluate the security of existing applications. These are common categories that span multiple technologies and components in a layered architecture. These categories are the focus for discussion through the designing, building, and security assessment chapters in this guide.
Table 2 Application Vulnerability Categories
|Input Validation||How do you know that the input your application receives is valid and safe? Input validation refers to how your application filters, scrubs, or rejects input before additional processing.|
|Authentication||Who are you? Authentication is the process that an entity uses to identify another entity, typically through credentials such as a user name and password.|
|Authorization||What can you do? Authorization is the process that an application uses to control access to resources and operations.|
|Configuration Management||Who does your application run as? Which databases does it connect to? How is your application administered? How are these settings secured? Configuration management refers to how your application handles these operational issues.|
|Sensitive Data||Sensitive data is information that must be protected either in memory, over the wire, or in persistent stores. Your application must have a process for handling sensitive data.|
|Session Management||A session refers to a series of related interactions between a user and your Web application. Session management refers to how your application handles and protects these interactions.|
|Cryptography||How are you protecting secret information (confidentiality)? How are you tamperproofing your data or libraries (integrity)? How are you providing seeds for random values that must be cryptographically strong? Cryptography refers to how your application enforces confidentiality and integrity.|
|Parameter Manipulation||Form fields, query string arguments, and cookie values are frequently used as parameters for your application. Parameter manipulation refers to both how your application safeguards tampering of these values and how your application processes input parameters.|
|Exception Management||When a method call in your application fails, what does your application do? How much does it reveal about the failure condition? Do you return friendly error information to end users? Do you pass valuable exception information back to the caller? Does your application fail gracefully?|
|Auditing and Logging||Who did what and when? Auditing and logging refer to how your application records security-related events.|
You need to know your threats before you can successfully apply security measures. Threats can be external, such as from an attacker on the Internet, or internal for example, from a disgruntled employee or administrator. This guide helps you to identify threats in two ways:
- It lists the top threats that affect Web applications at the network, host, and application layers.
- It presents a threat modeling process to help you identify which threats are relevant to your application.
An outline of the threat modeling process covered in the guide is shown in Figure 4.
The Threat Modeling Process
The steps shown in Figure 4 are described below:
- Identify assets.
Identify the assets of value that your systems must protect.
- Create an architecture overview.
Use simple diagrams and tables to document the architecture of your application, including subsystems, trust boundaries, and data flow.
- Decompose the application.
Decompose the architecture of your application, including the underlying network and host infrastructure design, to create a security profile for the application. The aim of the security profile is to uncover vulnerabilities in the design, implementation, or deployment configuration of your application.
- Identify the threats.
Keeping an attacker's goals in mind, and with knowledge of your application's architecture and potential vulnerabilities, you identify the threats that could impact the application.
- Document the threats.
Document each threat using a common threat template that defines a core set of attributes that you should capture for each threat.
- Rate the threats.
Rate the threats to prioritize and address the most significant threats first. These threats are the ones that present the biggest risk. The rating process weighs the probability of the threat against the damage that could result should an attack occur. It might turn out that certain threats do not warrant any action when you compare the risk posed by the threat with the resulting mitigation costs.
Different parts of the guide apply to the different phases of the product development life cycle. The sequence of chapters in the guide mirrors the typical phases of the life cycle. The chapter-to-role relationship is shown in Figure 5.
Relationship of chapter to product life cycle
Note Threat modeling and security assessment (specifically the code review and deployment review chapters) apply when you build new Web applications or when you review existing applications.
The guidance throughout the guide is task-based and modular, and each chapter relates to the various stages of the product development life cycle and the various roles involved. These roles include architects, developers, system administrators, and security professionals. You can pick specific chapters to perform a particular task or use a series of chapters for a phase of the product development life cycle.
The checklist shown in Table 3 highlights the areas covered by this guide that are required to secure your network, host, and application.
Table 3 Implementation Checklist
|Educate your teams about the threats that affect the network, host, and application layers. Identify common vulnerabilities and attacks, and learn countermeasures. For more information, see Chapter 2, "Threats and Countermeasures."|
|Create threat models for your Web applications. For more information, see Chapter 3, "Threat Modeling."|
|Review and implement your company's security policies. If you do not have security policies in place, create them. For more information about creating security policies, see "Security Policy Issues" at the SANS Info Sec Reading Room at http://www.sans.org/rr/catindex.php?cat_id=50.|
|Review your network security. For more information, see Chapter 15, "Securing Your Network."|
|Patch and update your servers. Review your server security settings and compare them with the snapshot of a secure server. For more information, see "Snapshot of a Secure Web Server" in Chapter 16, "Securing Your Web Server."|
|Educate your architects and developers about Web application security design guidelines and principles. For more information, see Chapter 4, "Design Guidelines for Secure Web Applications."|
|Educate your architects and developers about writing secure managed code. For more information, see Chapter 7, "Building Secure Assemblies" and Chapter 8, "Code Access Security in Practice."|
|Secure your developer workstations. For more information, see "How To: Secure Your Developer Workstation" in the "How To" section of this guide.|
|Review the designs of new Web applications and of existing applications. For more information, see Chapter 5, "Architecture and Design Review."|
|Educate developers about how to perform code reviews. Perform code reviews for applications in development. For more information, see Chapter 21, "Code Review."|
|Perform deployment reviews of your applications to identify potential security vulnerabilities. For more information, see Chapter 22, "Deployment Review."|
Designing and building secure applications is a collaborative effort involving multiple roles. This guide is structured to address each role and the relevant security factors to be considered by each role. The categorization and the issues addressed are outlined below.
RACI stands for:
- Responsible (the role responsible for performing the task)
- Accountable (the role with overall responsibility for the task)
- Consulted (people who provide input to help perform the task)
- Keep Informed (people with a vested interest who should be kept informed)
You can use a RACI chart at the beginning of your project to identify the key security related tasks together with the roles that should execute each task.
Table 4 illustrates a simple RACI chart for this guide. (The heading row lists the roles; the first column lists tasks, and the remaining columns delineate levels of accountability for each task according to role.)
Table 4 RACI Chart
|Security Design Principles||A||I||I||C|
|Architecture and Design Review||R||A|
|Technology Specific Threats||A||R|
This fast track has highlighted the basic approach taken by the guide to help you design and develop hack-resilient Web applications, and to evaluate the security of existing applications. It has also shown you how to apply the guidance depending on your specific role in the project life cycle.