Professional ASP.NET Security - Jeff Ferguson

Accessing Out-of-Process COM servers: If an ASP.NET application needs to access out-of-process COM servers while running in the ASPNET account context, then we should specifically grant launch permissions using DCOM Configuration utility (DCOMCNFG. exe).

Debugging Issues: By default, debugging an XML Web Service call from a client application will not work. To enable debugging for XML Web Services, we should add the ASPNET account in to the Debugger Users group.

Using ASP.NET on PDC or BDC: Running the ASP.NET application on a PDC (Primary Domain Controller) or BDC (Backup Domain Controller) will fail. This is because in a PDC or BDC, all the accounts are domain accounts, not local accounts. Since the ASP.NET process (Aspnet_wp.exe) is looking for the local account localmachine\ASPNET, it will not be able to find it, so the process fails. This problem can be fixed by running the ASP.NET process using the system account, as discussed in the next section. For more information about this problem, read the Microsoft Support Article PRB: ASP.NET Does Not Work with a Non-Administrator Domain Account on a Domain Controller (Q315158) at: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q315158&GSSNB=1

Reading IIS Metabase: The ASPNET account does not have the permission to read IIS metabase information. The .disco files rely on IIS metabase to provide discovery services. If an application needs access to metabase settings, we can selectively add read access to metabase nodes using the Metaacl utility for the ASPNET account. The Metaacl utility may be

downloaded from:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q267904. Also, more information about it may be accessed at this URL.

Using IIS6 & Windows .NET Server: On IIS 6 and Windows .NET Server, the ASPNET account is used only for IIS 5 Isolation mode. If Worker Process Isolation mode is used, all ASP.NET applications will run inside an IIS w3wp. exe worker process. In this case, the default identity is NetworkService, which is configurable at the application-pool level. NetworkService is similar to the ASPNET account with respect to permissions.

Running under the System Account

We can configure ASP.NET applications to run under the System account, if our application needs more privileges, such as those enjoyed by the inetinf o . exe process (which runs under the System account). When configured to run under the System account, the ASP.NET worker process will have the right to access nearly all resources on the local machine. In Windows 2000, Windows XP, and Windows .NET Server family systems, the System account also has network credentials and can access the same network resources as the machine account.

We can use the <processModel> section of the userName and password attributes in the machine configuration file (the Machine, config file in the \config subdirectory of the installation root). The default values for the userName and password attributes are Machine and AutoGenerate respectively, and these values tell ASP.NET to use the built-in ASPNET account, and to use a cryptographically strong random password stored in the Local Security Authority for that account. To configure the process to run as System, use the following in the machine . config file:

<processModel userName="System" password="AutoGenerate" .../>

410

ASP.NET Security Configuration

Configuring Impersonation

Impersonation is a process that enables code to run under a different identity from that of the current logged in user. By default, all the ASP.NET applications run under the ASPNET identity, even if the users are logging in as anonymous users, or with valid Windows usernames.

So why do you want to impersonate? Well, if we want the operating system to perform access checks for us, for instance, when we attempt to access a resources, we will need to impersonate. For example, suppose we have certain restrictions on the file system, registry, and network resources. If we impersonate the users directly in the ASP.NET application, the operating system will check to make sure the current user has enough privileges to access a particular resource, such as a file or network resource.

Sometimes, we may not want to impersonate users, in which case we'll use an application-level authentication mechanism, which will authenticate and authorize the users. When the users want to perform some action, such as reading a file, or writing to a network resource, our application will do it for them behind the scenes. In this kind of scenario, our application logic makes the decision.

If you need to make your ASP.NET application run under a different Windows user account, you can use the <identity> tag in the Machine . Conf ig or Web.Conf ig file.

Impersonation can be configured in two ways. The first option is by using IIS to impersonate the user. For example, if an ASP.NET application uses IIS anonymous access, then the ASP.NET application will run under the security context of the ASPNET account. If you want the ASP.NET application to impersonate the current logged in user's account, then you can turn on the impersonate flag in the following way:

<identity impersonate="True" />

Impersonation Through IIS

In this way, the ASP.NET process may run under the iusr_machinename account. Let's see an example of this. Let's create a web. conf ig file in the following way, which enables impersonation:

<?xml version="l.0" encoding="utf-8" ?> <configuration>

<system.web>

<identity impersonate="true" /> </systern.web>

</configuration>

Then we'll display the current logged in user information in the ASP.NET page:

ocript language="C#" runat=" server "> void

Page_Load(Object sender, EventArgs e) {

//Get a new WindowsPrincipal Object.

WindowsPrincipal objWinPrn = new WindowsPrincipal(Windowsldentity.GetCurrent());

IblUserl.Text = objWinPrn.Identity.Name; } </script>

411

The Windowsldentity .GetCurrent () method fetches the security token of the current thread, builds a Windowsldentity object, and returns it. In the Page_Load event, we pass the Windowsldentity object to the WindowsPrincipal object, and read the Windows user account used by the current ASP.NET thread.

The ASP.NET is a multithreaded process (aspnet_wp.exe) and a ThreadPool handles all the threads spun by the ASP.NET process. By default, each and every thread inside the ASP.NET ThreadPool gets the same identity of the ThreadPool, which is the ASPNET account.

When we impersonate an ASP.NET application, it affects a set of threads that are related to the particular application, rather than the whole ASP.NET process. For example, let's say we're running App A and App B inside the ASP.NET process, that App B is impersonating, and App A is running with its default identity. This is how the ThreadPool inside the ASP.NET application would look like:

As we can see, the threads running App B are running with under Impersonated Users Identity, and the other application threads and the ideal threads are running with the default ASPNET application identity. It is very important to understand that impersonation is specific to a given thread, not to the whole ASP.NET process.

Windows User Name: SRUTHIMUSR SRUTHI

When we set impersonate=" true" in the <identity> tag, the ASP.NET application runs under the security context of the iusr_machinename account. We can change the user account of the anonymous user account in which IIS executes all the anonymous users.

412

As we saw in previous chapters, if we use User. Identity. Name, we'll get the name of the user who has logged in.

Impersonating Through a Specific User Account

If we want to impersonate the ASP.NET process with a specific username account, then we can customize the username and password tags.

<identity impersonate="true" userName="accountname" password="password" />

However, this process involves more than simply specifying the username and password in the <identity> tag. The ASP.NET process should run under the System account. In the previous section, we saw how to run ASP.NET applications under the system identity using the <processModel> tag:

<processModel userName="System" password="AutoGenerate" ... />

In addition, if a user account needs to impersonate, it needs special privileges. We can assign the Act as part of the operating system privilege by using the Local Security Settings tool that can be found in the Start I Programs I Administrative Tools menu.

: ....................................

In the Local Security Settings tool, navigate to the User Rights Assignment leaf of the Local Policies folder and double-click on the Act as part of the operating system item. Now click the Add... button and add the ASPNET account to the list, as shown:

414

ASP.NET Security Configuration

Act as part of the opefatirig system

El

El

SRUTHIWdministrator

SRUTHIWSPNET

If domain-level policy settings are defined, they override bcal policy settings.

OK Cancel

Click OK and save the changes. After this, restart IIS. This will assign the Act as part of the operating system privilege to the ASPNET account, which will ensure that it has the necessary privileges in order to impersonate.

Making these changes makes the impersonating account more powerful, so use this option with caution.

Now let's run the impersonation code that we've used previously, and we'll see the ASP.NET application runs under the new impersonating user, regardless of what kind of authentication the ASP.NET application uses, and who has logged into the application.

File Edit View

http:/Vlocalhost/T.H12/lmp

Impersonation

Windows User Name: SRUTHI\SecureWebUser

When we're impersonating the ASP.NET application with a specific user name, the username should have read and write access to the following folders:

415

<Drive>:<WindowsHome>\Assembly

<Drive>:<WindowsHome>\Microsoft.NET\Framework\<Version>\Temporary ASP.NET Files\

Impersonating in Part of the Code

Sometimes, we may want to run a specific section of our code with a different user account, since some operations, such as executing a COM component, or writing to the network drive, need special permissions. This kind of impersonation can also be implemented programmatically.

To implement this kind of impersonation, we have to use a particular unmanaged function. The LogonUser function in the advapi32 . dll can be used in impersonating users. This function takes parameters such as username, domain name, password, and type of login, and returns the security token for the impersonated user. Then we can pass the security token to the Windowsldentity object, and impersonate the user.

Let's define a simple C# class with a static method. We'll use the DLLImport attribute to specify the name of the DLL where this function resides:

//Decalre a class public class Win32API {

//Import the win32API into the class and make it as a static method [Dlllmport ("advapi32.dll")]public static externbool LogonUser (String IpszUsername, String

IpszDomain, String IpszPassword, int dwLogonType, int dwLogonProvider , out int phToken) ;

Let's also create an ASP.NET page with three label controls to display the user accounts used by the ASP.NET application. In the Page_Load event, we display the current username used by the current ASP.NET thread. Then we call the LogonUser static method in the Win32 class, and pass the login parameters.

void Page_Load( Object sender, EventArgs e) {

int token;

//Get a new WindowsPrincipal Object WindowsPrincipal objWinPrn = new

WindowsPrincipal (Windowsldentity. GetCurrent () ) ; IblUserl.Text = objWinPrn. Identity .Name;

//Impersonate the call bool loggedon =

Win3 2 API. LogonUser ( "SecureWebUser" , "SRUTHI" , "EasyToBreak" , 3, 0, out token) ;

If the login was unsuccessful, then we display the error number returned by the DLL in the second textbox.

416

rtOr".INC:i OCOUIILy WVJI ll Igui

if ( ! loggedon)

{

//Show the error number returned by DLL

Ibl0ser2 .Text = Marshal .GetLastWin32Error () .ToString ();

}

If the login was successful, we create an IntPtr object by passing the security token returned by the LogonUser method. Then we pass the new security token to the Impersonate method of the Windowsldentity object to create a new WindowsImpersonationContext object. This will enable the current thread to impersonate an account using the given username and password.

We then get the username information from the current ASP. NET thread and display it in the second label control. Finally, we call the Undo method of the WindowsImpersonationContext object to cancel the impersonation. This will change the current thread's identity to the default account.

else

IntPtr tokenPtr = new IntPtr (token) ; WindowsImpersonationContext ctx =

Windowsldentity. Impersonate (tokenPtr) ; WindowsPrincipal objWinPrnl = new

WindowsPrincipal (Windowsldentity .GetCurrent 0 ) lblUser2 .Text = objWinPrnl . Identity .Name; ctx. Undo ( ) ;

After this, we again read the identity of the current thread and display it in the third label control:

//Get a new WindowsPrincipal Object. WindowsPrincipal objWinPrn2 = new

WindowsPrincipal(Windowsldentity.GetCurrent()); lblUser3.Text = objWinPrn2.Identity.Name;

When we run this, we should be able to check that everything has worked as intended:

417

If we want to use on-the-fly impersonation within the code, we need to grant the Act as part of the operating system privilege to the ASPNET account.

Summary

We've looked at how to configure Windows OS Security using the Security Configuration Tool Set, how to use the Microsoft Network Security Hotfix Checker (HFNetChk) to check for the latest security patches, the ASPNET account, and its limitations, and how to run ASP.NET applications under the System identity, or with a different user account, using impersonation.

Useful information about Microsoft security may be found at the following URLs:

Q Microsoft security tools may be found at: http://www.microsoft.com/technet/security/tools/tools.asp

Q The Microsoft Security Tool Kit can be found at: http://www.microsoft.com/technet/security/tools/stkintro.asp

Q Microsoft TechNet Security Web Site is at: http://www.microsoft.com/technet/security/default.asp

Q You can subscribe to Microsoft Security bulletins by sending an e-mail to securrem@microsoft.com. For more information visit: http://www.microsoft.com/technet/security/bulletin/notify.asp

Q The HotFix & Security Bulletin Search Site is at: http://www.microsoft.com/technet/security/current.asp

Q The Microsoft Personal Security Advisor may be found at: http://www.microsoft.com/technet/mpsa/start.asp

Q Antivirus information can be found at: http://www.microsoft.com/technet/security/virus/virus.asp

Q The Symantec AntiVirus Enterprise Edition 8.0 can be found at: http://enterprisesecurity.Symantec.com/products/products.cfm?ProductlD=64&PI 0=10562313

418