Template Sample: Web Application Threat Model

Threat Modeling Web Applications

J.D. Meier, Alex Mackman, Blaine Wastell

Microsoft Corporation

May 2005

See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.

Home Page for Threat Modeling Web Applications

Summary: This provides a sample of a threat model template that shows you the type of data that you should gather. The threat model can be used as input for deriving security test plans or test cases.

Contents

Application Name and Description
Owners, Authors, and Stakeholders
Revision History
1. Security Objectives
2. Application Overview
3. Application Decomposition
4. Threats
5. Vulnerabilities

Application Name and Description

The application is an Internet-facing Web application with a SQL Server back end.

Owners, Authors, and Stakeholders

Revision History

1. Security Objectives

The security objectives are:

• Protect customer account details and customer credit history.
• Ensure that the application is available 99.99 percent of the time.
• Prevent unauthorized users from modifying product catalog information, especially prices.

2. Application Overview

The application is an Internet-facing Web application with a SQL Server back end. The Web server is located in a perimeter network. Business and data access logic resides on the Web server. The application enables Internet users to browse and purchase products from the company's product catalog.

End-to-End Deployment Scenario

Error! Unknown switch argument.

Roles

Application roles are:

• Internet users
• Catalog administrators

Key Scenarios

Important application scenarios are:

• Anonymous user browses the product catalog to view product details.
• Anonymous user searches to locate a specific product.
• Anonymous user adds an item to the shopping cart.
• Anonymous user logs in to authenticate prior to placing an order.
• Anonymous user creates a new account prior to placing an order.
• Authenticated user places an order.

Technologies

The application uses the following technologies:

• Web Server: Microsoft Internet Information Server (IIS)
• Presentation logic: ASP.NET (C#)
• Business logic: C# Class Libraries
• Data access logic: ADO.NET, T-SQL Stored Procedures
• Database Server: Microsoft SQL Server 2000

Application Security Mechanisms

• The most important application security mechanisms known at this time are:
• Users are authenticated with Forms authentication.
• Application is authenticated at the database by using Windows authentication.
• Roles are used to authorize access to business logic.
• Administration can be performed only by physically logging on to the server computer. No remote administration access is provided.

3. Application Decomposition

This section describes the trust boundaries, entry points, exit points, and data flows.

Trust Boundaries

Identified trust boundaries are:

• The perimeter firewall.
• The database server trusts calls from the Web application's identity.
• The data access components trust the business components to pass fully validated data.
• An entry point to catalog administration business component.

Data Flows

Data flows are:

• An anonymous user browses the product catalog. The catalog page calls the catalog business component, which calls the catalog data access component to request a catalog listing. The first page of product details are retrieved from the database and returned to the catalog business component. The data is bound to a data grid control and displayed on the catalog page.
• An anonymous user submits a search string. The home page accepts the search string and validates it by using a regular expression. The search string must be less than 50 characters in length and may include any combination of letters or numbers. The search string is passed to the data access component. The data access component calls a stored procedure and passes the search string as a single parameter.
• The user logs on. The user submits a name and password through the logon form. The user name and password are handled by the logon page and passed to the membership business logic component. This component passes the data to the data access component, which verifies the credentials with the database to determine their validity.
• A catalog administrator logs on and accesses the restricted catalog administration page. The catalog administration component checks the user role at the business layer. If the user is authorized, the business component interacts with the catalog data access component to view and amend product details.

Entry Points

Entry points are:

• Port 80 for Web requests.
• Port 443 for SSL.
• All other ports are restricted by the firewall.
• The logon page, which is accessible to all Internet users. Logon is validated by using client-side and server-side validation controls, together with a common validation library.
• The amend customer details page, which is accessible to authenticated users only. Users are validated by using client-side and server-side validation controls, together with a common validation library. This page invokes functionality that can update customer details.
• The GetCustomerDetails stored procedure, which can be called only by the application's trusted service account. The upstream caller (trusted Web application business logic) performs data validation. The invoked functionality retrieves customer details.
• The catalog administration page.

Exit Points

Exit points are:

• The search page, which writes the client's search string and the corresponding results.
• The catalog page, which displays product details.

4. Threats

The following threats could affect the application:

• Brute force attacks occur against the dictionary store.
• Network eavesdropping occurs between the browser and Web server to capture client credentials.
• An attacker captures an authentication cookie to spoof identity.
• SQL injection occurs, enabling an attacker to exploit an input validation vulnerability to execute commands in the database and thereby access and/or modify data.
• Cross-site scripting occurs when an attacker succeeds in injecting script code.
• Cookie replay or capture occurs, allowing an attacker to spoof identity and access the application as another user.
• Information is disclosed and sensitive exception details are revealed to the client.
• An attacker manages to take control of the Web server, gain unauthorized access to the database, and run commands against the database.
• An attacker obtains the encryption keys used to encrypt sensitive data (including client credit card numbers) in the database.
• An attacker or client obtains unauthorized access to Web server resources and static files.

5. Vulnerabilities

The application vulnerabilities are:

• User password storage.
• Lack of password complexity enforcement.
• Lack of password retry logic.
• Missing or weak input validation at the server.
• Failure to validate cookie input.
• Failure to sanitize data read from a shared database.
• Failure to encode output leading to potential cross-site scripting issues.
• Exposing an administration function through the customer-facing Web application.
• Exposing exception details to the client.

Start | Previous