| Securing ASP.NET Web Sites |
| Security is a very important aspect of ASP.NET Web applications. The topics in this section provide background information about security issues that occur in Web applications. The topics include information about how to mitigate common security threats, how to protect resources in a Web application, and about how to authenticate and authorize individual users. |
| The Contents in this section provide guidance on how to improve the security of your application through user authentication, authorization, data encryption, and more. |
| Please fill up the form below and we will submit a proposal for your project. Alternatively, you can send email to contact@optionm.net with the project requirements. |
|
|
|
|
|
 |
| ASP.NET Web Application Security |
|
|
| ASP.NET, in conjunction with Microsoft Internet Information Services (IIS), can authenticate user credentials such as names and passwords using any of the following authentication methods: |
|
| Windows: Basic, digest, or Integrated Windows Authentication (NTLM or Kerberos). |
| Forms authentication, in which you create a login page and manage authentication in your application. |
| Microsoft Passport authentication |
| Client Certificate authentication |
|
|
| ASP.NET controls access to site information by comparing authenticated credentials, or representations of them, to NTFS file system permissions or to an XML file that lists authorized users, authorized roles (groups), or authorized HTTP verbs. |
|
| This section contains topic that describe the specifics of ASP.NET security. |
|
| How ASP.NET Security Works |
| Securing Web sites is a critical, complex issue for Web developers. Protecting a site requires careful planning, and Web site administrators and programmers must have a clear understanding of the options for securing their site. |
|
| ASP.NET works in concert with the Microsoft .NET Framework and Microsoft Internet Information Services (IIS) to help provide Web application security. To help protect your ASP.NET application, you should perform the two fundamental functions described in the following table. |
|
| Security function |
Description |
| Authentication |
Helps to verify that the user is, in fact, who the user claims to be. The application obtains credentials (various forms of identification, such as name and password) from a user and validates those credentials against some authority. If the credentials are valid, the entity that submitted the credentials is considered an authenticated identity. |
| Authorization |
Limits access rights by granting or denying specific permissions to an authenticated identity. |
|
|
|
| IIS can also grant or deny access based on a user's host name or IP address. Any further access authorization is performed by NTFS file access permission's URL authorization. |
|
| It is helpful to understand how all the various security subsystems interact. Since ASP.NET is built on the Microsoft .NET Framework, the ASP.NET application developer also has access to all the built-in security features of the .NET Framework, such as code access security and role-based user-access security. |
|
|
|
| Click here to submit your project requirements to Option Matrix, India. |
| Back to top |
 |
| ASP.NET Security Architecture |
|
|
| This section provides an overview of the ASP.NET security infrastructure. The following illustration shows the relationships among the security systems in ASP.NET. |
|
| ASP.NET architecture |
|
 |
|
| As the illustration shows, all Web clients communicate with ASP.NET applications through Microsoft Internet Information Services (IIS). IIS authenticates the request if required and then locates the requested resource (such as an ASP.NET application). If the client is authorized, the resource is made available. |
|
| When an ASP.NET application is running, it can use built-in ASP.NET security features. In addition, an ASP.NET application can use the security features of the .NET Framework. |
|
 |
Integrating ASP.NET Authentication with IIS |
|
| In addition to relying on the authentication capabilities of IIS, you can perform authentication in ASP.NET. When considering ASP.NET authentication, you should understand the interaction with IIS authentication services. |
|
| IIS assumes that a set of credentials maps to a Microsoft Windows NT account and that it should use those credentials to authenticate a user. There are three different kinds of authentication available in IIS 5.0 and IIS 6.0: basic, digest, and Windows Integrated Security (NTLM or Kerberos). You can select the type of authentication to use in IIS administrative services. For more information on IIS authentication, see the IIS documentation. |
|
| If users request a URL that maps to an ASP.NET application, the request and authentication information are handed off to the application. ASP.NET provides forms authentication. Forms authentication is a system by which unauthenticated requests are redirected to an ASP.NET Web page that you create. The user provides credentials and submits the page. If your application authenticates the request, the system issues an authentication ticket in a cookie that contains the credentials or a key for reacquiring the identity. Subsequent requests include an authentication ticket with the request. |
 |
Note: |
| ASP.NET membership and ASP.NET login controls implicitly work with forms authentication. |
|
|
| ASP.NET Configuration File Security Settings |
|
| ASP.NET security settings are configured in the Machine.config and Web.config files. As with other configuration information, base settings and default settings are established in the Machine.config file in the Config subdirectory of the current .NET Framework installation. You can establish site-specific and application-specific settings (including overriding settings from the Machine.config file) in Web.config files in the Web site root and application root directories. Subdirectories inherit a directory's settings unless overridden by a Web.config file in the subdirectory. To see an example of the way in which the hierarchical configuration system works for security |
|
| There are three major subsections to a Web.config file: the authentication, authorization, and identity sections. The values for each security element are usually set in the Machine.config file and overridden as required in the application-level Web.config file. All subdirectories automatically inherit those settings. However, subdirectories can have their own configuration files that override inherited settings. |
|
|
Note: |
| ASP.NET configuration applies only to ASP.NET resources, namely those registered to be handled in IIS by the Aspnet_isapi.dll extension. ASP.NET configuration cannot provide authorization for resources not processed by ASP.NET. Therefore, .txt, .htm, .html, .gif, .jpg, .jpeg, .asp, and other types of files are accessible by all users (subject to IIS permissions). For example, even though the ASP.NET resources in a directory might be restricted by a Web.config file, all users can still view the files located in that directory if directory browsing is turned on and no other restrictions are in place. You can put these types of files under ASP.NET security by explicitly mapping such file name extensions to the Aspnet_isapi.dll extension using the IIS administration tool. However, processing these types of files through ASP.NET can affect the performance of the Web site. |
|
|
| You can use the location configuration element to specify a particular file or directory to which settings should apply. |
|
|
|
| Click here to submit your project requirements to Option Matrix, India. |
| Back to top |
 |
| ASP.NET Security Data Flow |
|
|
| You can design security into ASP.NET applications in a number of ways. This topic describes the security data flow for two common scenarios: impersonation and forms authentication using cookies. |
|
|
Scenario 1: Impersonation |
|
| The impersonation scenario relies on Microsoft Internet Information Services (IIS) authentication and Microsoft Windows file access security to minimize security programming in the ASP.NET application itself. The data flow is shown in the following illustration. |
|
| Impersonation |
|
 |
|
| The illustration shows the following sequence of events: |
|
| 1. A request from a network client comes to IIS. |
| 2. IIS authenticates the client using basic, digest, or Windows integrated security (NTLM or Kerberos). |
| 3. If the client is authenticated, IIS passes the authenticated request to ASP.NET. |
| 4. The ASP.NET application impersonates the requesting client using the access token passed from IIS, and it relies on NTFS file permissions for granting access to resources. The ASP.NET application needs only to verify that impersonation is set to true in the ASP.NET configuration file; no ASP.NET security code is required. |
|
| If impersonation is not enabled, the application runs with the ASP.NET process identity. For Microsoft Windows 2000 Server and Windows XP Professional, the default identity is a local account named ASPNET that is created automatically when ASP.NET is installed. For Microsoft Windows Server 2003, the default identity is the identity of the application pool for the IIS application (by default, the NETWORK SERVICE account.) |
|
Note: |
| In a postback request, if the page contains validator controls, check the IsValid property of the Page and of individual validation controls before performing any processing. |
|
| 5. If access is granted, the ASP.NET application returns the requested resource through IIS. |
|
|
|
Scenario 2 - Forms Authentication |
|
|
| In the forms authentication scenario, an application collects credentials such as name and password directly from the user and makes its own determination about their authenticity. IIS authentication is not used by the application, but IIS authentication settings can affect forms authentication. As a rule, when you use forms authentication, you enable anonymous access in IIS. Otherwise, if users do not pass IIS authentication, they do not reach your application in order to provide a user name and password to forms authentication. |
|
| The data flow in this scenario is shown in the following illustration: |
| Forms authentication |
 |
| This illustration shows the following sequence of events: |
|
| 1. A user generates a request for a protected resource. |
|
| 2. IIS receives the request, and because IIS anonymous access is enabled, IIS does not perform any user authentication and the request is passed to the ASP.NET application. |
|
| 3. Because the ASP.NET authentication mode is set to forms, the ASP.NET application examines the request for a forms authentication ticket (a specific cookie). If there is no authentication ticket attached to the request, ASP.NET redirects the request to the logon page specified in the application's configuration file. |
|
| 4. On the logon page, the user enters the required credentials, usually a name and password. The application code checks the credentials to confirm their authenticity. If the credentials are authenticated, the application code attaches an authentication ticket to the response that represents the user credentials. (The password is not included). If authentication fails, the response is returned with an access denied message or the logon form is presented again. |
|
| The authentication ticket that is issued is included with subsequent requests to the ASP.NET application. ASP.NET checks the ticket for validity using a message authentication check (MAC). |
|
| 5. If the user is authenticated, ASP.NET checks authorization and can either allow access to the originally requested resource, redirect the request to some other page, or redirect the request to a custom authorization module where the credentials are tested for authorization to access the protected resource. If authorization fails, ASP.NET redirects the user to the logon page. |
|
| If the user is authorized, access is granted to the protected resource; or the application might require an additional test of the credentials before authorizing access to the protected resource, depending on the design of the application. |
|
|
|
|
| Click here to submit your project requirements to Option Matrix, India. |
| Back to top |
 |
| ASP.NET Authentication |
|
|
| Authentication is the process of obtaining identification credentials such as name and password from a user and validating those credentials against some authority. If the credentials are valid, the entity that submitted the credentials is considered an authenticated identity. Once an identity has been authenticated, the authorization process determines whether that identity has access to a given resource. |
|
| ASP.NET implements authentication through authentication providers, the code modules that contain the code necessary to authenticate the requestor's credentials. The topics in this section describe the authentication providers built into ASP.NET. |
|
|
In This Section |
|
|
| Term |
Definition |
| Windows Authentication Provider |
Provides information on how to use Windows authentication in conjunction with Microsoft Internet Information Services (IIS) authentication to secure ASP.NET applications. |
| Forms Authentication Provider |
Provides information on how to create an application-specific login form and perform authentication using your own code. A convenient way to work with forms authentication is to use ASP.NET membership and ASP.NET login controls, which together provide a way to collect user credentials, authenticate them, and manage them, using little or no code. |
|
|
|
| You might also consider using Windows Live ID for user authentication. |
|
| Authorization determines whether an identity should be granted access to a specific resource. In ASP.NET, there are two ways to authorize access to a given resource: |
|
| File authorization File authorization is performed by the FileAuthorizationModule. It checks the access control list (ACL) of the .aspx or .asmx handler file to determine whether a user should have access to the file. ACL permissions are verified for the user's Windows identity (if Windows authentication is enabled) or for the Windows identity of the ASP.NET process. |
| authorization URL authorization is performed by the UrlAuthorizationModule, which maps users and roles to URLs in ASP.NET applications. This module can be used to selectively allow or deny access to arbitrary parts of an application (typically directories) for specific users or roles. |
|
|
|
|
| Click here to submit your project requirements to Option Matrix, India. |
| Back to top |
 |
| Using URL Authorization |
|
|
| With URL authorization, you explicitly allow or deny access to a particular directory by user name or role. To do so, you create an authorization section in the configuration file for that directory. To enable URL authorization, you specify a list of users or roles in the allow or deny elements of the authorization section of a configuration file. The permissions established for a directory also apply to its subdirectories, unless configuration files in a subdirectory override them. |
|
| The following shows the syntax for the authorization section: |
|
 |
Copy Code |
|
<authorization>
<[allow|deny] users roles verbs />
</authorization> |
|
| The allow or deny element is required. You must specify either the users or the roles attribute. Both can be included, but both are not required. The verbs attribute is optional. |
|
| The allow and deny elements grant and revoke access, respectively. Each element supports the attributes shown in the following table: |
|
| Attribute |
Description |
| users |
Identifies the targeted identities (user accounts) for this element.
Anonymous users are identified using a question mark (?). You can specify all authenticated users using an asterisk (*). |
| roles |
Identifies a role (a RolePrincipal object) for the current request that is allowed or denied access to the resource. For more information, see Managing Authorization Using Roles. |
| verbs |
Defines the HTTP verbs to which the action applies, such as GET, HEAD, and POST. The default is "*", which specifies all verbs. |
|
|
|
|
|
| Click here to submit your project requirements to Option Matrix, India. |
| Back to top |
 |
| ASP.NET Impersonation |
|
|
| When using impersonation, ASP.NET applications can execute with the Windows identity (user account) of the user making the request. Impersonation is commonly used in applications that rely on Microsoft Internet Information Services (IIS) to authenticate the user. |
|
| ASP.NET impersonation is disabled by default. If impersonation is enabled for an ASP.NET application, that application runs in the context of the identity whose access token IIS passes to ASP.NET. That token can be either an authenticated user token, such as a token for a logged-in Windows user, or the token that IIS provides for anonymous users (typically, the IUSR_MACHINENAME identity). |
|
| When impersonation is enabled, only your application code runs under the context of the impersonated user. Applications are compiled and configuration information is loaded using the identity of the ASP.NET process. The compiled application is put in the Temporary ASP.NET files directory. The application identity that is being impersonated needs to have read/write access to this directory. The impersonated application identity also requires at least read access to the files in your application directory and subdirectories. |
|
|
Note: |
| Because ASP.NET uses the Windows identity of the ASP.NET process when compiling applications and loading configuration information, you must keep application code and configuration information private between applications on a server that hosts multiple applications. On Windows Server 2003 you can create multiple application pools and specify a unique identity for each application pool. You can then restrict access to application files using access control lists (ACLs) (if file system is formatted using NTFS) and these identities. For example, consider two applications, App1 and App2, where the information in each application must be kept private. You can put App1 in the ApplicationPool1 application pool which has an identity of ID_ApplicationPool1. You can put App2 in the ApplicationPool2 application pool which has an identity of ID_ApplicationPool2. The ID_ApplicationPool1 account is given access to the files in App1, but denied access to the files in App2. ID_ApplicationPool2 is given access to the files in App2, but denied access to the files in App1. Note that you cannot make this separation on Windows 2000 or Windows XP Professional, because on those operating systems, the process identity for all ASP.NET applications is a single identity. |
|
|
| You control impersonation using the identity configuration element. As with other configuration directives, this directive applies hierarchically. |
|
|
Note: |
| In the preceding example, the user name and password are stored in clear text in the configuration file. To improve the security of your application, it is recommended that you restrict the access to your Web.config file using an Access Control List (ACL) and that you encrypt the identityconfiguration element in your Web.config file using protected configuration. |
|
|
| The configuration illustrated in the example enables the entire application to run using the contoso\Jane identity, regardless of the identity of the request. This type of impersonation can be delegated to another computer. That is, if you specify the user name and password for the impersonated user, you can connect to another computer on the network and request resources, such as files or access to SQL Server, using integrated security. If you enable impersonation and do not specify a domain account as the identity, you will not be able to connect to another computer on the network unless your IIS application is configured to use Basic authentication. |
|
|
|
