Back to the top

Introduction

Security is an integral part of any Web-based application. Understanding ASP.NET security will help in building secure Web applications. This document provides a brief overview of security in ASP.NET. You can use the various resources and pointers provided in this document to study the topics in-depth.

Back to the top

Back to the top

Understanding the IIS security model

Before the requests reach ASP.NET, they must be authenticated by Microsoft Internet Information Services (IIS). Learning how IIS security works would be very helpful. See the following resources for helpful information.
INFO: How IIS Authenticates Browser Clients (http://support.microsoft.com/kb/264921/)
Untangling Web Security: Getting the Most from IIS Security (http://msdn2.microsoft.com/en-us/library/ms995343.aspx)
How Does It Work? (http://msdn2.microsoft.com/en-us/library/aa302376.aspx)
Security Model for ASP.NET Applications (http://msdn2.microsoft.com/en-us/library/aa302382.aspx)
Microsoft Internet Information Server Security Overview (http://msdn2.microsoft.com/en-us/library/ms951692.aspx)

Back to the top

Back to the top

Worker process identity information

On Microsoft Windows 2000 or on Microsoft Windows XP, ASP.NET runs under a special user called ASPNET. If you install the .NET Framework version 1.1 on a domain controller, the installation does not create the local ASPNET account. Instead, ASP.NET applications run under other identities.

On Windows 2000 domain controller servers, ASP.NET applications run under the IWAM_machinename identity. On Windows 2003 domain controller servers, ASP.NET applications run under the NETWORK SERVICE identity (regardless of the IIS isolation mode). Under some circumstances, running ASP.NET on a domain controller requires that you take extra steps to make the installation work properly. For more information about potential problems running ASP.NET 1.1 on a domain controller, click the following article number to view the article in the Microsoft Knowledge Base: For more information about running the .NET Framework version 1.0 on a domain controller, click the following article numbers to view the articles in the Microsoft Knowledge Base: Back to the top

Back to the top

Authentication in ASP.NET authorization

Authentication is the process of obtaining identification credentials such as name and password from a user and then validating those credentials against some authority. If the credentials are valid, the entity that submitted the credentials is considered an authenticated identity. After 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. ASP.NET supports Forms Authentication, Passport Authentication, and Windows authentication providers.

To enable an authentication provider for an ASP.NET application, you only have to create an entry for the application configuration file as follows:

// Web.config file     
<authentication mode= "[Windows|Forms|Passport|None]"/>

The mode is set to one of the authentication modes: Windows, Forms, Passport, or None. The default is Windows. If the mode is None, ASP.NET does not apply any additional authentication to the request. This can be useful when you want to implement a custom authentication scheme, or if you are solely using anonymous authentication and want the highest possible level of performance.

The authentication mode cannot be set at a level below the application root directory. As is the case with other ASP.NET modules, subdirectories in the URL space inherit authentication modules unless explicitly overridden. Back to the top

Forms-based authentication

Forms authentication is a system by which unauthenticated requests are redirected to an HTML form using HTTP client-side redirection. The user provides credentials and submits the form. If the application authenticates the request, the system issues a cookie that contains the credentials or a key for reacquiring the identity. Subsequent requests are issued with the cookie in the request headers. They are authenticated and authorized by an ASP.NET event handler using whatever validation method the application developer specifies.

Protecting static file types using forms authentication

By default, forms authentication protects only ASPX pages and any other .NET extensions. You can configure forms authentication to protect other static extensions such as .jpg, .gif, .html, .pdf, etc. To do this, map these extensions to aspnet_isapi.dll using IIS Manager as follows:

1.	Open IIS Manager. To do so, click Start, click Program Files, point to Administrative Tools, and then click Internet Information Services Manager.
2.	Find your application’s virtual folder, and right-click it (your application must be forms authentication-enabled).
3.	Click Properties.
4.	Click Configuration.
5.	On the Mappings tab, click Add.
6.	In the Executable box, click aspnet_isapi.dll, which will be located in the %windows folder%\Microsoft.NET\Framework\FrameworkVersion folder.
7.	In the Extension box, type your extension (for example, .jpg).
8.	Provide at-least “GET” verb.
9.	Click to clear the Check that File Exists check box.
10.	Click OK for rest of the dialog boxes.

Protecting classic ASP pages using forms authentication

Protecting classic ASP pages with forms authentication is not supported by design because ASP and ASP.NET use different handlers. However, you can make it work using the help of COM-Interop and Web services.

The following sample should work. This would have been pretty easy using simple COM Interop to call into the FormsAutentication utility functions. However, the functions require an HttpContext, which is only available in an ASP.NET application.

As a workaround, create an ASP.NET Web service that does the forms authentication ticket validation.

1.	Use the ASP.NET forms authentication sample from the following article as a place to start: 301240 (http://support.microsoft.com/kb/301240/) How to implement forms-based authentication in your ASP.NET application by using C#.NET
2.	Create a class that will manually validate a ticket that it is passed, return the forms authentication cookie name that is in use, and return the logon URL (all so that the code can be self-contained with minimum administration required): ////////////// start sample code ////////////// //this method validates a ticket passed from ASP public bool IsAuthenticated(string rawCookieData) { if(rawCookieData.Trim().Length <= 0) return false; FormsAuthenticationTicket decryptedTicket; try { decryptedTicket = FormsAuthentication.Decrypt(rawCookieData); } catch { //log reason for failure or whatever here if you like return false; } if (decryptedTicket.Expired) return false; // Optionally you could change the method signature to return // the decrypted ticket and then, you can call RenewTicketIfOld // and then implement code on the ASP side to update the cookie // with the newed ticket. This would only be necessary if the // ticket has a timeout set (this resets the timeout) // see the MSDN docs on FormsAuthentication.RenewTicketIfOld. return true; } // method merely returns the name of the cookie being used public string GetCookieName() { return FormsAuthentication.FormsCookieName.ToString(); } // method returns the login url used in the redirect // this is trickier since there is no FormsAuth utility function available to return this so we have to manually look at web.config private string GetLoginURL() { string sConfigPath = Server.MapPath(Request.ApplicationPath) + "\\web.config"; XmlDocument doc = new XmlDocument(); doc.Load(sConfigPath); try { XmlNode xmlNodeForms = doc.SelectSingleNode("configuration/system.web/authentication/forms"); return xmlNodeForms.Attributes.GetNamedItem("loginUrl").InnerText; } catch { throw new System.Exception("error in GetLoginURL()"); } } ////////////// end sample //////////////
3.	Create another .NET wrapper class that calls this Web service (or create and compile a webproxy class).
4.	Use Regasm.exe and Gacutil.exe to make this "wrapper" class callable from ASP via ComInterop.
5.	The ASP code would look something like this: Set oAuthClass = Server.CreateObject("ASPNETFormsAuth.WrapperClass") If Not oAuthClass.IsAuthenticated(Request.Cookies(oAuthClass.GetCookieName)) Then Response.Redirect("http://servername/ASPApplicationRoot/" & oAuthClass.GetLoginURL & "?RetrunURL=" & Requset.ServerVariables("URL")) End If

For more information on forms authentication, see the following resources:Back to the top

Passport-based authentication

Pass-port based authentication is a centralized authentication service provided by Microsoft that offers a single logon and core profile services for member sites. For more information, see the following Microsoft Web site:Back to the top

Windows-based authentication

ASP.NET uses Windows authentication in conjunction with Microsoft Internet Information Services (IIS) authentication. Authentication is performed by IIS in one of three ways: basic, digest, or integrated Windows authentication. When IIS authentication is complete, ASP.NET uses the authenticated identity to authorize access. For more information, see the following resources: Back to the top

Authorization

The purpose of authorization is to determine whether an identity should be granted the type of access that is requested by a resource. There are two fundamental ways to authorize access to a given resource:

•

File authorization File authorization is performed by the FileAuthorizationModule (http://msdn2.microsoft.com/en-us/library/system.web.security.fileauthorizationmodule(vs.71).aspx), and is active when you use Windows authentication. It does an access-control-list (ACL) check of the .aspx or .asmx handler file to determine if a user should have access. Applications can also use impersonation to get resource checks on resources that they are accessing. For more information about impersonation, see the following Microsoft Web site: ASP.NET Impersonation (http://msdn2.microsoft.com/en-us/library/xh507fc5(vs.71).aspx) .

•

URL authorization URL authorization is performed by the URLAuthorizationModule (http://msdn2.microsoft.com/en-us/library/system.web.security.urlauthorizationmodule(vs.71).aspx), which maps users and roles to pieces of the URL namespace. This module implements both positive and negative authorization assertions. That is, the module can be used to selectively allow or deny access to arbitrary parts of the URL namespace for certain sets, users, or roles.

For more information on authorization, see the following Microsoft Web sites:Back to the top

Back to the top

Impersonation

Impersonation occurs when ASP.NET runs code in the context of an authenticated and authorized client. By default, ASP.NET does not use impersonation and instead runs all code using the same user account as the ASP.NET process, which is typically the ASPNET account. This is contrary to the default behavior of ASP, which is to use impersonation. In IIS 6.0, the default identity is the NetworkService account.

Note Impersonation can significantly affect performance and scaling. It is generally more expensive to impersonate a client on a call than to make the call directly.

Using impersonation, ASP.NET applications can optionally execute the processing thread using the identity of the client on whose behalf they are operating. You usually use impersonation for resource access control. Delegation is a more powerful form of impersonation and makes it possible for the server process to access remote resources while acting as the client. For more information about impersonation in ASP.NET, see the following resources:Microsoft Windows 2000 Service Pack 4 (SP4) adds a couple of new local security policies that the impersonating account will need. For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base: Back to the top

Back to the top

Code access security in .NET

Code access security is a resource constraint model designed to restrict the types of system resources that code can access and the types of privileged operations that the code can perform. These restrictions are independent of the user who calls the code or the user account under which the code runs.

Code access security delivers three main benefits. By using code access security, you can:

•	Restrict what your code can do. For example, if you develop an assembly that performs file I/O, you can use code access security to restrict your code's access to specific files or directories. This reduces the opportunities for an attacker to coerce your code to access arbitrary files.
•	Restrict which code can call your code. For example, you may want only your assembly to be called by other code developed by your organization. One way to do this is to use the public key component of an assembly's strong name to apply this kind of restriction. This helps prevent malicious code from calling your code.
•	Identify code. To successfully administer code access security policy and restrict what code can do, the code must be identifiable. Code access security uses evidence such as an assembly's strong name or its URL, or its computed hash to identify code (assemblies).

For more information about Code Access Security, see the following Microsoft Web sites:Back to the top

Back to the top

Data Access Security

This following link contains recommendations and guidance that will help you develop a secure data access strategy. Topics covered include using Windows authentication from ASP.NET to the database, securing connection strings, storing credentials securely in a database, protecting against SQL injection attacks, and using database roles. This article also addresses issues with double-hop authentication.Back to the top

Back to the top

Storing Passwords and Connection Strings Securely

By default, storing the connection string or impersonated user identity in Web.Config, or storing the process identity in Machine.config, requires you to enter the user name and password in clear text. The following articles show you how to store them securely.
Back to the top

Back to the top

Samples and walkthroughs

Back to the top

Back to the top

Must-read articles

The following guides are developed to cover all the aspects of implementing ASP.NET security in the real world scenario and are an excellent way of understanding security in ASP.NET.Back to the top

Back to the top

Other useful links and KB articles

How-to articles

Applications may choose to store encrypted data, such as connection strings and account credentials, in the Windows registry. Learn how to store and retrieve encrypted strings in the registry.

How-to articles already mentioned elsewhere in this document

Back to the top

Back to the top

Top bug fixes and other security issues

Windows 2000 SP4 adds a couple of new local security policies that the impersonating account will need. For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base: Back to the top

Back to the top

Getting free support

Newsgroups are a great way to get free support for your questions. You can post your questions or search through the archives for answers. The following newsgroups are very active and you can leverage the collective knowledge of the MSDN and ASP.NET developer community.

ASP.NET Security Newsgroup (look under .NET Development)Security Forum at Home of ASP.NET Plenty of other security related information, including new KB articles, is available at the following Microsoft Web site: Back to the top

Back to the top

As always, feel free to submit ideas on topics you want addressed in future columns or in the Knowledge Base using the Ask For It (http://support.microsoft.com/common/survey.aspx?scid=sw;en;1176&p0=&p1=&p2=&p3=&p4=) form.

Back to the top