ASP.NET security overview

Article translations Article translations
Article ID: 891028 - View products that this article applies to.
ASP .NET Support Voice Column: ASP.NET security overview
To customize this column to your needs, we want to invite you to submit your ideas about topics that interest you and issues that you want to see addressed in future Knowledge Base articles and Support Voice columns. You can submit your ideas and feedback using the Ask For It form. There's also a link to the form at the bottom of this column.
Expand all | Collapse all

On This Page

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

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
Untangling Web Security: Getting the Most from IIS Security
How Does It Work?
Security Model for ASP.NET Applications
Microsoft Internet Information Server Security Overview

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:
824308 IWAM account is not granted the impersonate privilege for ASP.NET 1.1 on Windows 2000 Domain Controller with SP4
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:
315158 FIX: ASP.NET does not work with the default ASPNET account on domain controller
317012 Process and request identity in ASP.NET
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 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:
Forms Authentication Provider:
306238 How to implement role-based security with forms-based authentication in your ASP.NET application by using Visual Basic.NET
311495 How to implement role-based security with forms-based authentication in your ASP.NET application by using Visual C#.NET
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:
Passport Authentication Provider.
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:
Windows Authentication Provider
323176 How to implement Windows authentication and authorization in ASP.NET
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, 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
    .
  • URL authorization

    URL authorization is performed by the URLAuthorizationModule, 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:
ASP.NET Authorization
<authorization> Element
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:
Impersonation in ASP.NET (Designing Distributed Applications with Visual Studio .NET)
Impersonation in ASP.NET (.NET Framework Developer's Guide)
Using IIS Authentication With ASP.NET Impersonation
ASP.NET Data Flow
ASP.NET Delegation
306158 How to implement impersonation in an ASP.NET application
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:
824308 BUG: IWAM account is not granted the impersonate privilege for ASP.NET 1.1 on a Windows 2000 domain controller with SP4
821546 Overview of the "impersonate a client after authentication" and the "create global objects" security settings
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:
Code Access Security in Practice
Using Code Access Security with ASP .NET
How To: Use Code Access Security Policy to Constrain an Assembly
Code Access Security for Developers
Code Access Security
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.
Data Access Security
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.
329290 How to use the ASP.NET utility to encrypt credentials and session state connection strings
329250 FIX: Stronger credentials for processModel, identity, and sessionState
821616 Usage of strong credentials to store connection strings in the sessionState element
Back to the top

Samples and walkthroughs


ASP.NET Security Samples
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.
Building Secure ASP.NET Applications
Improving Web Application Security: Threats and Countermeasures
Authentication in ASP.NET: .NET Security Guidance
Back to the top

Other useful links and KB articles


ASP.NET Security Home on MSDN
306590 ASP.NET security overview
ASP.NET Web Application Security
324964 Support WebCast: Microsoft ASP.NET security
Security Considerations for ASP.NET Web Applications
310588 Security toolkit breaks ASP.NET debugging in Visual Studio.NET
An Introductory Guide to Building and Deploying More Secure Sites with ASP.NET and IIS

How-to articles

810572 How to configure an ASP.NET application for a delegation scenario
315736 How to secure an ASP.NET application by using Windows security
323176 How to implement Windows authentication and authorization in ASP.NET
306238 How to implement role-based security with forms-based authentication in your ASP.NET application by using Visual Basic.NET
311495 How to implement role-based security with forms-based authentication in your ASP.NET application by using Visual C#.NET
306158 How to implement impersonation in an ASP.NET application
815145 How to lock down an ASP.NET Web application or Web service
815153 How to configure NTFS file permissions for security of ASP.NET applications
How to Store an Encrypted Connection String in the Registry
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

329290 How to use the ASP.NET utility to encrypt credentials and session state connection strings
329250 FIX: Stronger credentials for processModel, identity, and sessionState
821616 Usage of strong credentials to store connection strings in the sessionState element
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:
824308 BUG: IWAM account is not granted the impersonate privilege for ASP.NET 1.1 on a Windows 2000 domain controller with SP4
821546 Overview of the "impersonate a client after authentication" and the "create global objects" security settings
315158 FIX: ASP.NET does not work with the default ASPNET account on a domain controller
811320 "Aspnet_wp.exe could not be started" error message when you view an ASP.NET page
810204 Per request impersonation does not work on Windows 2000 with ASP.NET
827559 "Catastrophic failure" error message when you try to debut an ASP.NET application on Windows 2000 domain controller
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.

Security Forum at Home of ASP.NET
http://forums.asp.net/25.aspx
Plenty of other security related information, including new KB articles, is available at the following Microsoft Web site:
http://support.microsoft.com
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 form.

Properties

Article ID: 891028 - Last Review: October 17, 2012 - Revision: 3.0
Applies to
  • Microsoft ASP.NET 1.0
  • Microsoft ASP.NET 1.1
Keywords: 
kbpubtypekc kbhowto KB891028

Give Feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com