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

Internet Security

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

Published: November 2002

Last Revised: January 2006

Applies to:

• ASP.NET 1.1
• .NET Framework 1.1

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 describes how to secure common Internet application scenarios. It presents the characteristics of each scenario and describes the steps necessary to secure the scenario. Analysis sections are also included to provide further information. (17 printed pages)

Contents

ASP.NET to SQL Server
ASP.NET to Remote Enterprise Services to SQL Server
Summary

Internet applications have large audiences, many potential uses, and varied security requirements. They range from portal applications that require no user authentication, through Web applications that provide content for registered users, to large-scale e-commerce applications that require full authentication, authorization, credit card validation and secure communication of sensitive data over public and internal networks.

As Internet application developers, you face a challenge to ensure that your application uses appropriate defense mechanisms and is designed to be scalable, high performance, and secure. Some of the challenges you face include:

• Choosing an appropriate user credential store, for example, a custom database or Microsoft® Active Directory® service
• Making your application work through firewalls
• Flowing security credentials across the multiple tiers of your application
• Performing authorization
• Ensuring the integrity and privacy of data as it flows across public and internal networks
• Securing your application's state with a database
• Ensuring the integrity of your application's data
• Implementing a solution that can scale to potentially huge numbers of users

The two common Internet application scenarios presented in this chapter, which are used to illustrate recommended authentication, authorization and secure communication techniques are:

• ASP.NET to SQL Server
• ASP.NET to Remote Enterprise Services to SQL Server

ASP.NET to SQL Server

In this scenario with two physical tiers, registered users securely log in to the Web-based application using a Web browser. The ASP.NET-based Web application makes secure connections to a Microsoft® SQL Server™ database to manage predominantly data retrieval tasks. An example is a portal application that provides news content to registered subscribers. This is shown in Figure 7.1.

Figure 7.1. An ASP.NET Web application to SQL Server Internet scenario

Characteristics

This scenario has the following characteristics:

• Users have a number of different browser types.
• Anonymous users can browse the application's unrestricted pages.
• Users must register or log on (through an HTML form) before being allowed to view restricted pages.
• User credentials are validated against a SQL Server database.
• All user input (such as user credentials) that is used in database queries is validated to mitigate the threat of SQL injection attacks.
• The front-end Web application is located within a perimeter network (also known as DMZ, demilitarized zone, and screened subnet), with firewalls separating it from the Internet and the internal corporate network (and the SQL Server database).
• The application requires strong security, high levels of scalability, and detailed auditing.
• The database trusts the application to authenticate users properly (that is, the application makes calls to the database on behalf of the users).
• The Web application connects to the database by using the ASP.NET process account.
• A single user-defined database role is used within SQL Server for database authorization.

Secure the Scenario

In this scenario, the Web application presents a logon page to accept credentials. Successfully validated users are allowed to proceed, all others are denied access. The database authenticates against the ASP.NET default process identity, which is a least privileged account (that is, the database trusts the ASP.NET application).

Table 7.1. Security summary

The Result

Figure 7.2 shows the recommended security configuration for this scenario.

Figure 7.2. The recommended security configuration for the ASP.NET to SQL Server Internet scenario

Security Configuration Steps

Before you begin, you'll want to see the following:

• Creating custom ASP.NET accounts (see How To: Create a Custom Account to Run ASP.NET 1.1 in the Reference section of this guide)

  For ASP.NET 2.0, see "How To: Create a Service Account for an ASP.NET 2.0 Application."

• Creating a least privileged database account (see Chapter 12, Data Access Security)

• Configuring SSL on a Web server (see How To: Set Up SSL on a Web Server in the Reference section of this guide)

• Configuring IPSec (see How To: Use IPSec to Provide Secure Communication Between Two Servers in the Reference section of this guide)

Configure the Web server

<!-- userName="machine" password="AutoGenerate" 
  --  >

<!-- userName="machine" 
     password="YourStrongPassword" --  >

<authentication mode="Forms" >
  <forms name="MyAppFormsAuth" 
         loginUrl="login.aspx" 
         protection="All"
         timeout="20" 
         path="/" >
  </forms>
</authentication>

Configuring SQL Server

Configuring Secure Communication

Analysis

• Forms authentication is ideal in this scenario because the users do not have Windows accounts. The Forms login page is used to acquire user credentials. Credential validation must be performed by application code. Any data store can be used. A SQL Server database is the most common solution, although Active Directory provides an alternate credential store.

• With Forms authentication, you must protect the initial logon credentials with SSL. The Forms authentication ticket (passed as a cookie on subsequent Web requests from the authenticated client) must also be protected. You could use SSL for all secured pages in order to protect the ticket. You can also encrypt the Forms authentication ticket by configuring the protection attribute of the <forms> element (to All or Encrypt), and by using the Encrypt method of the FormsAuthentication class to encrypt the ticket.

  The protection="All" attribute specifies that when the application calls FormsAuthentication.Encrypt, the ticket should be validated (integrity checked) and encrypted. Call this method when you create the authentication ticket, typically within the application's Login button event handler.

  string encryptedTicket = FormsAuthentication.Encrypt(authTicket);
  

  Note   If you are running ASP.NET 2.0, it is recommended that you use the Membership feature which simplifies Forms Authentication implementation. For more information, see "How To: Use Membership in ASP.NET 2.0."

  For more information about Forms authentication and ticket encryption, see Chapter 8, ASP.NET Security.

  Note   If you are running ASP.NET 2.0, see How To: Use Forms Authentication with Active Directory in ASP.NET 2.0, How To: Use Forms Authentication with Active Directory in Multiple Domains in ASP.NET 2.0, and How To: Use Forms Authentication with SQL Server in ASP.NET 2.0.

• ASP.NET runs as the least privileged local account, so potential damage from compromise is mitigated.

• URL authorization on the Web server allows unauthenticated users to browse unrestricted Web pages and forces authentication for restricted pages.

• Because impersonation is not enabled, any local or remote resource access performed by the Web-based application is performed using the ASPNET process identity's security context. Windows ACLs on secure resources should be set accordingly.

• User credentials are validated against a custom SQL Server database. Password hashes (with salt) are stored within the database. For more information, see Authenticating Users against a Database in Chapter 12, "Data Access Security."

• By using Windows authentication to SQL Server, you avoid storing credentials in files on the Web server and also passing them over the network.

• If your application currently uses SQL authentication, you must securely store the database connection string as it contains user names and passwords. Consider using DPAPI. For more details, see Storing Database Connection Strings Securely, in Chapter 12, "Data Access Security."

• The use of a duplicated Windows account on the database server (one that matches the ASP.NET process account) results in increased administration. If a password is changed on one computer, it must be synchronized and updated on all computers. In some scenarios, you may be able to use a least-privileged domain account for easier administration.

• IPSec between the Web server and database server ensures the privacy of the data sent to and from the database.

• SSL between browser and Web server protects credentials and any other security sensitive data such as credit card numbers.

• If you use a Web farm, ensure that the encryption and validation keys —for example, those used to encrypt and validate the Forms authentication ticket (and specified by the <machineKey> element in Machine.config) —are consistent across all servers in the farm. See Chapter 8, ASP.NET Security, for further details about using ASP.NET in a Web farm scenario.

Pitfalls

The application must flow the original caller's identity to the database to support auditing requirements. Caller identity may be passed using stored procedure parameters.

Related Scenarios

Forms authentication against Active Directory

The user credentials that are accepted from the Forms login page can be authenticated against various stores. Active Directory is an alternate to using a SQL Server database.

More information

For more information, see How To: Use Forms Authentication with Active Directory in ASP.NET 1.1 in the Reference section of this guide.

For more information on using Forms authentication with ASP.NET 2.0, see How To: Use Forms Authentication with Active Directory in ASP.NET 2.0.

.NET roles for authorization

The preceding scenario doesn't take into consideration the different types of users accessing the application. For example, a portal server could have different subscription levels such as Standard, Premier, and Enterprise.

If role information is maintained in the user store (SQL Server database), the application can create a GenericPrincipal object in which role and identity information can be stored. After the GenericPrincipal is created and added to the Web request context (using HttpContext.User), you can add programmatic role checks to method code or you can decorate methods and pages with PrincipalPermission attributes to demand role membership.

Note   For ASP.NET 2.0, you can use the Role Manager feature to check the role membership using Roles APIs. For more information, see "How To: Use Role Manager in ASP.NET 2.0."

More information

• For more information about creating GenericPrincipal objects that contain role lists, see How To: Create GenericPrincipal Objects with Forms Authentication in ASP.NET 1.1 in the Reference section of this guide.
• For more information about PrincipalPermission demands and programmatic role checks, see Chapter 8, ASP.NET Security.
• For more information on using the Role Manager feature in ASP.NET 2.0, see How To: Use Role Manager in ASP.NET 2.0.

Using a domain anonymous account at the Web server

In this scenario variation, the default anonymous Internet user account (a local account called IUSR_MACHINE) is replaced by a domain account. The domain account is configured with the minimum privileges necessary to run the application (you can start with no privilege and incrementally add privileges). If you have multiple Web-based applications, you can use different domain accounts (one for each Web-based application or virtual directory).

In order to flow the security context of the anonymous domain account from IIS to ASP.NET, turn on impersonation for the Web-based application by using the following web.config file setting:

<identity impersonate="true" />

If the Web-based application communicates with a remote resource such as a database, the domain account must be granted the necessary permissions to the resource. For example, if the application accesses a remote file system, ACLs must be configured appropriately to give (at minimum) read access to the domain account. If the application accesses a SQL Server database, the domain account must be mapped using a SQL login to a database login.

As the security context that flows through the application is that of the anonymous account, the original caller's identity (captured through Forms authentication) must be passed at the application level from tier to tier; for example, through method and stored procedure parameters.

More information

• For more information regarding this approach, see Using the Anonymous Internet User Account within Chapter 8, "ASP.NET Security."
• Before implementing this scenario, see article Q259353, Must Enter Password Manually After You Set Password Synchronization in the Microsoft Knowledge Base.

ASP.NET to Remote Enterprise Services to SQL Server

In this scenario, a Web server running ASP.NET pages makes secure connections to serviced components, located on a remote application server that in turn connects to a SQL Server database. In common with many Internet application infrastructures, the Web server and application server are separated by a firewall (and the Web server is located within a perimeter network). Serviced components make secure connections to SQL Server.

As an example, consider an Internet banking application that provides sensitive data, (for example, private financial details) to users. All banking transactions from the client to the database must be secured and data integrity is critical. Not only does the traffic to and from the user need to be secured but the traffic to and from the database needs to be secured as well. This is shown in Figure 7.3.

Figure 7.3. An ASP.NET to remote Enterprise Services to SQL Server Internet scenario

Characteristics

• Users have a number of different browser types.
• Anonymous users can browse the application's unrestricted pages.
• Users must register or log on (through an HTML form) before being allowed to view restricted pages.
• The front-end Web-based application is located within a perimeter network, with firewalls separating it from the Internet and the internal corporate network (and the application server).
• The application requires strong security, high levels of scalability, and detailed auditing.
• The Web-based application uses SOAP to connect to a Web services layer, which provides an interface to the serviced components that run within an Enterprise Services application on the application server. SOAP is preferred to DCOM due to firewall restrictions.
• SQL Server is using a single user-defined database role for authorization.
• Data is security sensitive and integrity and privacy must be secured over the network and in all persistent data stores.
• Enterprise Services (COM+) transactions are used to enforce data integrity.

Secure the Scenario

In this scenario, the Web service accepts credentials from a Forms login page and then authenticates the caller against a SQL Server database. The login page uses SSL to protect the user's credentials passed over the Internet.

The Web-based application communicates with a Web service, which provides an interface to the business services implemented within serviced components. The Web service trusts the Web-based application (inside the perimeter network) and authenticates the ASP.NET process identity. The user's identity is passed through all tiers at the application level using method and stored procedure parameters. This information is used for auditing the users' actions across the tiers.

Table 7.2. Security measures

The Result

Figure 7.4 shows the recommended security configuration for this scenario.

Figure 7.4. The recommended security configuration for the ASP.NET to remote Enterprise Services to SQL Server Internet scenario

Security Configuration Steps

Before you begin, you'll want to see the following:

• Creating a least privileged database account (see Chapter 12, Data Access Security)
• Configuring SSL on a Web server (see How To: Set Up SSL on a Web Server in the Reference section of this guide)
• Configuring IPSec (see How To: Use IPSec to Provide Secure Communication Between Two Servers in the Reference section of this guide)
• Configuring Enterprise Services security (see How To: Use Role-based Security with Enterprise Services in .NET 1.1 in the Reference section of this guide)

Configure the Web server

<!-- userName="machine" password="AutoGenerate" 
  --  >

<!-- userName="machine" 
     password="YourStrongPassword" -- >

<authentication mode="Forms" >
  <forms name="MyAppFormsAuth" 
         loginUrl="login.aspx" 
         protection="All"
         timeout="20" 
         path="/" >
  </forms>
</authentication>

Configure the application server

<authentication mode="Windows" />

Configuring SQL Server

Configuring secure communication

Analysis

• Forms authentication is ideal in this scenario because the users do not have Windows accounts. The Forms login page is used to acquire user credentials. Credential validation must be performed by application code. Any data store can be used. A SQL Server database is the most common solution, although Active Directory provides an alternate credential store.

• The Web-based application is running as the least privileged local account, so potential damage from compromise is mitigated.

• URL authorization on the Web server allows unauthenticated users to browse unrestricted Web pages and forces authentication for restricted pages.

• Because impersonation is not enabled, any local or remote resource access performed by the Web-based application does so using the ASP.NET process identity's security context. ACLs should be configured accordingly.

• User credentials are validated against a custom SQL Server database. Password hashes (with salt) are stored within the database. For more information, see Authenticating Users against a Database in Chapter 12, "Data Access Security."

• Windows authentication to SQL Server means you avoid storing credentials in files on the application server and avoid passing them across the network.

• The use of a duplicated Windows account on the database server (one that matches the Enterprise Services process account) results in increased administration. If a password is changed on one computer, it must be synchronized and updated on all computers. In some scenarios, you may be able to use a least-privileged domain account for easier administration.

• When the Web application calls the Web service, it must configure the Web service proxy using DefaultCredentials (that is, the ASP.NET process account).

  proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
  

  For more information, see Passing Credentials For Authentication to Web Services in Chapter 10, "Web Services Security."

• SSL between the Web server and Web service layer (that fronts the serviced components on the application server) ensures the privacy of the data sent between the two servers.

• The Enterprise Services application is configured for application-level role-based security. The configuration permits only the local ASP.NET process identity (used to run the Web service) to access the serviced components.

• IPSec between the application server and database server ensures the privacy of the data sent to and from the database.

• SSL between browser and Web server protects credentials and bank account details.

Pitfalls

The application must flow the original caller's identity to the database to support auditing requirements. Caller identity may be passed using stored procedure parameters.

Related Scenarios

Forms authentication against Active Directory

The user credentials that are accepted from the Forms login page can be authenticated against various stores. Active Directory is an alternate to using a SQL Server database.

More information

For more information, see How To: Use Forms Authentication with Active Directory in ASP.NET 1.1 in the Reference section of this guide.

For ASP.NET 2.0, see How To: Use Forms Authentication with Active Directory in ASP.NET 2.0.

Using DCOM

Windows 2000 (SP3 or SP2 with QFE 18.1) or Windows Server 2003 allows you to configure Enterprise Services applications to use a static endpoint. If a firewall separates the client from the server, this means that you need to open only two ports in the firewall. Specifically, you must open port 135 for RPC and a port for your Enterprise Services application.

This enhancement to DCOM makes it a valid choice of communication protocol between Web server and application server and removes the requirement to have a Web services layer.

Important   If your application requires distributed transactions to flow between the two servers, DCOM must be used. Transactions cannot flow over SOAP. In the SOAP scenario, transactions must be initiated by the serviced components on the application server.

More information

For more information, see Chapter 9, Enterprise Services Security.

Using .NET Remoting

Remoting can be a valid choice when you don't need services provided by Enterprise Services such as transactions, queued components, object pooling, and so on. .NET Remoting solutions also support network load balancing at the middle tier. Note the following when you use .NET Remoting:

• For ultimate performance, use the TCP channel and host in a Windows service. Note that this channel provides no authentication and authorization mechanism by default. The TCP channel is designed for trusted subsystem scenarios. You can use an IPSec policy to establish a secure channel and to ensure that only the Web server communicates with the application server.
• If you need authentication and authorization checks using IPrincipal objects, you should host the remote objects in ASP.NET and use the HTTP channel. This allows you use the IIS and ASP.NET security features.
• The remote object can connect to the database using Windows authentication and can use the host process identity (either ASP.NET or a Windows service identity).

More information

For more information about .NET Remoting security, see Chapter 11, .NET Remoting Security.

Summary

This chapter has described how to secure a set of common Internet application scenarios.

For Intranet and extranet application scenarios, see Chapter 5, "Intranet Security," and Chapter 6, Extranet Security.

© Microsoft Corporation. All rights reserved.