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 Active Directory® 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
Note
Several scenarios described in this chapter change the password of the default ASPNET account to allow duplicated accounts to be created on remote computers for network authentication purposes. This requires an update to the <processModel> element of Machine.config. <processModel> credentials should not be stored in plain text in machine.config. Instead use the aspnet_setreg.exe utility to store encrypted credentials in the registry. For more information, see Chapter 8, and article Q329290, "HOWTO: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings" in the Microsoft Knowledge Base.
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.
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.
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
Category | Detail |
|---|---|
Authentication |
|
Authorization |
|
Secure Communication |
|
Figure 7.2 shows the recommended security configuration for this scenario.
Before you begin, you’ll want to see the following:
Creating custom ASP.NET accounts (see "Appendix " in the Reference section of this book)
Creating a least privileged database account (see Chapter 12)
Configuring SSL on a Web server (see "Appendix " in the Reference section of this book)
Configuring IPSec (see "Appendix " in the Reference section of this book)
Configure IIS | |
|---|---|
Step | More Information |
Enable Anonymous access for your Web application’s virtual root directory | To work with IIS authentication settings, use the IIS MMC snap-in. Right-click your application’s virtual directory, and then click Properties. Click the Directory Security tab, and then click Edit within the Anonymous access and authentication control group. |
Step | More information |
|---|---|
Reset the password of the ASPNET account (used to run ASP.NET) to a known strong password | This allows you to create a duplicate local account (with the same user name and password) on the database server. This is required to allow the ASPNET account to respond to network authentication challenges from the database server when it connects using Windows authentication. |
An alternative here is to use a least privileged domain account (if Windows authentication is permitted through the firewall). For more information, see "Process Identity for ASP.NET" in Chapter 8. | |
Edit Machine.config located in %windir%Microsoft.NETFrameworkv1.0.3705CONFIG | |
Set your custom account user name and password attributes on the <processModel> element | |
Default | |
<!-- userName="machine" password="AutoGenerate" --> | |
Becomes | |
<!-- userName="machine"
password="YourStrongPassword" --> | |
Configure your ASP.NET Web application to use Forms authentication (with SSL) | Edit Web.config in your application’s virtual directory root Set the <authentication> element to: <authentication mode="Forms" >
<forms name="MyAppFormsAuth"
loginUrl="login.aspx"
protection="All"
timeout="20"
path="/" >
</forms>
</authentication> |
For more information about using Forms authentication against a SQL Server database, see "Appendix " in the Reference section of this book. | |
More Information | |
|---|---|
Create a Windows account on your SQL Server computer that matches the ASP.NET process account | The user name and password must match your custom ASP.NET application account or must be ASPNET if you are using the default account. |
Configure SQL Server for Windows authentication | |
Create a SQL Server Login for your custom ASP.NET application account | This grants access to SQL Server. |
Create a new database user and map the login name to the database user | This grants access to the specified database. |
Create a new user-defined database role within the database and place the database user into the role | |
Establish database permissions for the database role | Grant minimum permissions. For more information, see Chapter 12. |
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 pages in order to protect the ticket, or alternatively you can encrypt the Forms authentication ticket by configuring the protection attribute of the <forms> element (to All or Encrypt) and use 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);
For more information about Forms authentication and ticket encryption, see Chapter 8.
ASP.NET runs as the least privileged local ASPNET 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 account 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.
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.
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 keys, for example those used to encrypt the Forms authentication ticket (and specified by the <machineKey> element in Machine.config), are consistent across all servers in the farm. See Chapter 8, for further details about using ASP.NET in a Web farm scenario.
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.
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.
For more information, see "Appendix " in the Reference section of this book.
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.
For more information about creating GenericPrincipal objects that contain role lists, see "How To: Use Forms Authentication with GenericPrincipal Objects" in the Reference section of this book.
For more information about PrincipalPermission demands and programmatic role checks, see Chapter 8.
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.
For more information regarding this approach, see "Using the Anonymous Internet User Account" within Chapter 8.
Before implementing this scenario, see article Q259353, "Must Enter Password Manually After You Set Password Synchronization" in the Microsoft Knowledge Base.
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.
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.
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
Category | Detail |
|---|---|
Authentication |
|
Authorization |
|
Secure Communication |
|
Figure 7.4 shows the recommended security configuration for this scenario.
Before you begin, you’ll want to see the following:
Creating a least privileged database account (see Chapter 12)
Configuring SSL on a Web server (see "Appendix " in the Reference section of this book)
Configuring IPSec (see "Appendix " in the Reference section of this book)
Configuring Enterprise Services security (see "Appendix " in the Reference section of this book)
Step | More Information |
|---|---|
Enable Anonymous access for your Web-based application’s virtual root directory | |
Configure ASP.NET | |
|---|---|
Step | More Information |
Reset the password of the ASPNET account (used to run ASP.NET) to a known strong password | This allows you to create a duplicate local account (with the same user name and password) on the application server. This is required to enable the ASPNET account to respond to network authentication challenges from the application server. |
An alternative is to use a least privileged domain account (if Windows authentication is permitted through the firewall). | |
For more information, see "Process Identity for ASP.NET" in Chapter 8. | |
Edit Machine.config located in %windir%Microsoft.NETFrameworkv1.0.3705CONFIG | |
Set your custom account username and password attributes on the <processModel> element. | |
Default | |
<!-- userName="machine" password="AutoGenerate" --> | |
Becomes | |
<!-- userName="machine"
password="YourStrongPassword" --> | |
Configure your Web-based application to use Forms authentication (with SSL) | Edit Web.config in your application’s virtual directory root Set the <authentication> element to: |
<authentication mode="Forms">
<forms name="MyAppFormsAuth"
loginUrl="login.aspx"
protection="All"
timeout="20"
path="/" >
</forms>
</authentication> | |
For more information about using Forms authentication against a SQL Server database, see "Appendix " in the Reference section of this book. | |
Configure IIS | |
|---|---|
Step | More Information |
Disable anonymous access | |
Configure Integrated Windows authentication | IIS authenticates the ASP.NET process identity from the Web-based application on the Web server. |
Configure ASP.NET | |
|---|---|
Step | More Information |
Use Windows authentication | Edit Web.config in your Web service’s virtual directory root. Set the <authentication> element to: |
<authentication mode="Windows" /> | |
Configure Enterprise Services | |
|---|---|
Step | More Information |
Create a least privileged custom account for running the Enterprise Services server application | Note: If you use a local account, you must also create a duplicate account on the database server computer. |
Configure the Enterprise Services application to use the custom account | Refer to "Configuring Security" within Chapter 9. |
Enable role-based access checking | Refer to "Configuring Security" within Chapter 9. |
Add a single Enterprise Services (COM+) role to the application called (for example Trusted Web Service) | Full end-user authorization is performed by the Web-based application. The Web service (and serviced components) only allows access to members of the Trusted Web Service role. |
Add the local ASPNET account to the Trusted Web Service role | Refer to "Configuring Security" within Chapter 9. |
Step | More Information |
|---|---|
Create a Windows account on your SQL Server computer that matches the Enterprise Services application account | The user name and password must match your custom Enterprise Services account. |
Configure SQL Server for Windows authentication | |
Create a SQL Server Login for your custom Enterprise Services account | This grants access to the SQL Server. |
Create a new database user and map the login name to the database user | This grants access to the specified database. |
Create a new user-defined database role and add the database user to the role | |
Establish database permissions for the database role | Grant minimum permissions For details, see Chapter 12. |
Step | More Information |
|---|---|
Configure the Web site for SSL | See "Appendix " in the Reference section of this book. |
Configure SSL between the Web server and application server. | See "Appendix " in the Reference section of this book. |
Configure IPSec between application server and database server | See "Appendix " in the Reference section of this book. |
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 ASPNET 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 ASPNET account 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.
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; ASPNET).
proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
For more information, see "Passing Credentials for Authentication to Web Services" in Chapter 10.
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 ASPNET account (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.
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.
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.
For more information, see "Appendix " in the Reference section of this book.
Windows 2000 (SP3 or SP2 with QFE 18.1) or Windows .NET Server 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.
For more information, see Chapter 9.
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).
For more information about .NET Remoting security, see Chapter 11.