Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication

Introduction

J.D. Meier, Alex Mackman, Michael Dunner and Srinath Vasireddy
Microsoft Corporation

Published: November 2002

Last Revised: January 2006

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 Building Secure ASP.NET Applications.

Summary: This chapter defines the scope and organization of the guide and highlights its goals. It also introduces key terminology and presents a set of core principles that apply to the guidance presented in later chapters. (7 printed pages)

Contents

The Connected Landscape
Scope
What Are the Goals of this Guide?
How You Should Read This Guide
Organization of the Guide
Key Terminology
Principles
Summary

Building secure distributed Web applications is challenging. Your application is only as secure as its weakest link. With distributed applications, you have a lot of moving parts and making those parts work together in a secure fashion requires a working knowledge that spans products and technologies.

You already have a lot to consider; integrating various technologies, staying current with technology and keeping a step ahead of the competition. If you don't already know how to build secure applications, can you afford the time and effort to learn? More to the point, can you afford not to?

The Connected Landscape

If you already know how to build secure applications, are you able to apply what you know when you build .NET Web applications? Are you able to apply your knowledge in today's landscape of Web-based distributed applications, where Web services connect businesses to other business and business to customers and where applications offer various degrees of exposure; for example, to users on intranets, extranets and the Internet?

Consider some of the fundamental characteristics of this connected landscape:

• Web services use standards such as SOAP, Extensible Markup Language (XML) and Hypertext Transport Protocol (HTTP), but fundamentally they pass potentially sensitive information using plain text.
• Internet business-to-consumer applications pass sensitive data over the Web.
• Extranet business-to-business applications blur the lines of trust and allow applications to be called by other applications in partner companies.
• Intranet applications are not without their risks considering the sensitive nature of payroll and Human Resource (HR) applications. Such applications are particularly vulnerable to rogue administrators and disgruntled employees.

Scope

This guide focuses on:

• Authentication (to identify the clients of your application)
• Authorization (to provide access controls for those clients)
• Secure communication (to ensure that messages remain private and are not altered by unauthorized parties)

Why authentication, authorization and secure communication?

Security is a broad topic. Research has shown that early design of authentication and authorization eliminates a high percentage of application vulnerabilities. Secure communication is an integral part of securing your distributed application to protect sensitive data, including credentials, passed to and from your application and between application tiers.

What Are the Goals of This Guide?

This guide is not an introduction to security. It is not a security reference for the Microsoft .NET Framework —for that you have the .NET Framework Software Development Kit (SDK) available from MSDN; see the "References" section of this guide for details. This guide picks up where the documentation leaves off and presents a scenario-based approach to sharing recommendations and proven techniques, as gleaned from the field, customer experience and insight from the product teams at Microsoft.

The information in this guide is designed to show you how to:

• Raise the security bar for your application.
• Identify where and how you need to perform authentication.
• Identify where and how you need to perform authorization.
• Identify where and how you need to secure communication both to your application (from your end users) and between application tiers.
• Identify common pitfalls and how to avoid them.
• Identify top risks and their mitigation related to authentication and authorization.
• Avoid opening up security just to make things work.
• Identify not only how, but also when to use various security features.
• Eliminate FUD (fear, uncertainty and doubt).
• Promote best practices and predictable results.

How You Should Read This Guide

The guide has been developed to be modular. This allows you to pick and choose which chapters to read. For example, if you are interested in learning about the in-depth security features provided by a specific technology, you can jump straight to Part III of the guide (Chapters 8 through 12), which contains in-depth material covering ASP.NET, Enterprise Services, Web Services, .NET Remoting, and data access.

However, you are encouraged to read the early chapters (Chapters 1 through 4) in Part I of the guide first, because these will help you understand the security model and identify the core technologies and security services at your disposal. Application architects should make sure they read Chapter 3, which provides some key insights into designing an authentication and authorization strategy that spans the tiers of your Web application. Part I will provide you with the foundation materials that will allow you to extract maximum benefit from the remainder of the guide.

The intranet, extranet and Internet chapters (Chapters 5 through 7) in Part II of the guide will show you how to secure specific application scenarios. If you know the architecture and deployment pattern that is or will be adopted by your application, use this part of the guide to understand the security issues involved and the basic configuration steps required to secure specific scenarios.

Finally, additional information and reference material in Part IV of the guide will help further your understanding of specific technology areas. It also contains a library of How Tos that enable you to develop working security solutions in the shortest possible time.

Organization of the Guide

The guide is divided into four parts. The aim is to provide a logical partitioning, which will help you to more easily digest the content.

Part I, Security Models

Part 1 of the guide provides a foundation for the rest of the guide. Familiarity with the concepts, principles and technologies introduced in Part 1 will enable you to extract maximum value from the remainder of the guide. Part 1 contains the following chapters.

• Chapter 1, "Introduction"
• Chapter 2, "Security Model for ASP.NET Applications "
• Chapter 3, "Authentication and Authorization"
• Chapter 4, "Secure Communication"

Part II, Application Scenarios

Most applications can be categorized as intranet, extranet or Internet applications. This part of the guide presents a set of common application scenarios, each of which falls into one of the aforementioned categories. The key characteristics of each scenario are described and the potential security threats analyzed.

You are then shown how to configure and implement the most appropriate authentication, authorization and secure communication strategy for each application scenario. Each scenario also contains sections that include a detailed analysis, common pitfalls to watch out for and frequently asked questions (FAQ). Part II contains the following chapters:

• Chapter 5, "Intranet Security"
• Chapter 6, "Extranet Security"
• Chapter 7, "Internet Security"

Part III, Securing the Tiers

This part of the guide contains detailed information that relates to the individual tiers and technologies associated with secure .NET-connected Web applications. Part III contains the following chapters:

• Chapter 8, "ASP.NET Security"
• Chapter 9, "Enterprise Services Security"
• Chapter 10, "Web Services Security"
• Chapter 11, ".NET Remoting Security"
• Chapter 12, "Data Access Security"

Within each chapter, a brief overview of the security architecture as it applies to the particular technology in question is presented. Authentication and authorization strategies are discussed for each technology along with configurable security options, programmatic security options and actionable recommendations of when to use the particular strategy.

Each chapter offers guidance and insight that will allow you to choose and implement the most appropriate authentication, authorization and secure communication option for each technology. In addition, each chapter presents additional information specific to the particular technology. Finally, each chapter concludes with a concise recommendation summary.

Part IV, Reference

This reference part of the guide contains supplementary information to help further your understanding of the techniques, strategies, and security solutions presented in earlier chapters. Detailed How Tos provide step-by-step procedures that enable you to implement specific security solutions. It contains the following information:

• Chapter 13, "Troubleshooting Security"
• How Tos
• "Base Configuration"
• "Configuration Stores and Tools"
• "How Does It Work?"
• "ASP.NET Identity Matrix"
• "Cryptography and Certificates"
• "ASP.NET Security Model"
• "Reference Hub"
• "Glossary"

Key Terminology

This section introduces some key security terminology used throughout the guide. Although a full glossary of terminology is provided within the "Reference" section of this guide, make sure you are very familiar with the following terms:

• Authentication. Positively identifying the clients of your application; clients might include end-users, services, processes or computers.
• Authorization. Defining what authenticated clients are allowed to see and do within the application.
• Secure Communications. Ensuring that messages remain private and unaltered as they cross networks.
• Impersonation. This is the technique used by a server application to access resources on behalf of a client. The client's security context is used for access checks performed by the server.
• Delegation. An extended form of impersonation that allows a server process that is performing work on behalf of a client, to access resources on a remote computer. This capability is natively provided by Kerberos on Microsoft® Windows® 2000 and later operating systems. Conventional impersonation (for example, that provided by NTLM) allows only a single network hop. When NTLM impersonation is used, the one hop is used between the client and server computers, restricting the server to local resource access while impersonating.
• Security Context. Security context is a generic term used to refer to the collection of security settings that affect the security-related behavior of a process or thread. The attributes from a process' logon session and access token combine to form the security context of the process.
• Identity. Identity refers to a characteristic of a user or service that can uniquely identify it. For example, this is often a display name, which often takes the form authority/user name.

Principles

There are a number of overarching principles that apply to the guidance presented in later chapters. The following summarizes these principles:

• Adopt the principle of least privilege. Processes that run script or execute code should run under a least privileged account to limit the potential damage that can be done if the process is compromised. If a malicious user manages to inject code into a server process, the privileges granted to that process determine to a large degree the types of operations the user is able to perform. Code that requires additional trust (and raised privileges) should be isolated within separate processes.

  The ASP.NET team made a conscious decision to run the ASP.NET account with least privileges.

• Use defense in depth. Place check points within each of the layers and subsystems within your application. The check points are the gatekeepers that ensure that only authenticated and authorized users are able to access the next downstream layer.

• Don't trust user input. Applications should thoroughly validate all user input before performing operations with that input. The validation may include filtering out special characters. This preventive measure protects the application against accidental misuse or deliberate attacks by people who are attempting to inject malicious commands into the system. Common examples include SQL injection attacks, cross-site scripting attacks, and buffer overflow.

• Use secure defaults. A common practice among developers is to use reduced security settings, simply to make an application work. If your application demands features that force you to reduce or change default security settings, test the effects and understand the implications before making the change.

• Don't rely on security by obscurity. Trying to hide secrets by using misleading variable names or storing them in odd file locations does not provide security. In a game of hide-and-seek, it's better to use platform features or proven techniques for securing your data.

• Check at the gate. You don't always need to flow a user's security context to the back end for authorization checks. Often, in a distributed system, this is not the best choice. Checking the client at the gate refers to authorizing the user at the first point of authentication (for example, within the Web application on the Web server), and determining which resources and operations (potentially provided by downstream services) the user should be allowed to access.

  If you design solid authentication and authorization strategies at the gate, you can circumvent the need to delegate the original caller's security context all the way through to your application's data tier.

• Assume external systems are insecure. If you don't own it, don't assume security is taken care of for you.

• Reduce surface area. Avoid exposing information that is not required. By doing so, you are potentially opening doors that can lead to additional vulnerabilities. Also, handle errors gracefully; don't expose any more information than is required when returning an error message to the end user.

• Fail to a secure mode. If your application fails, make sure it does not leave sensitive data unprotected. Also, do not provide too much detail in error messages; meaning don't include details that could help an attacker exploit a vulnerability in your application. Write detailed error information to the Windows event log.

• Remember you are only as secure as your weakest link. Security is a concern across all of your application tiers.

• If you don't use it, disable it. You can remove potential points of attack by disabling modules and components that your application does not require. For example, if your application doesn't use output caching, then you should disable the ASP.NET output cache module. If a future security vulnerability is found in the module, your application is not threatened.

Summary

This chapter has provided some foundation material to prepare you for the rest of the guide. It has described the goals of the guide and presented its overall structure. Make sure you are familiar with the key terminology and principles introduced in this chapter, because these are used and referenced extensively throughout the forthcoming chapters.

© Microsoft Corporation. All rights reserved.