TIP: Least Privilege and ASP.NET Debugging

  • Article

A best practice for developer security (and end-user security, for that matter) is to develop and run software using the least privilege necessary to get the job done, and no more (see Writing Secure Code, 2nd Edition for more information on Least Privilege). This includes how you log into your workstation. Too many developers and users use an account with administrative privileges on a day-to-day basis, leading to increased exposure to security problems, as well as potentially difficult to track bugs in their programs.

A better solution is to run using a non-admin account for day-to-day use. This approach is more secure, but brings with it some additional challenges. One such challenge is debugging ASP.NET applications. If you’re logged in as an Administrator, this is easy…it just works. To debug ASP.NET applications using a low-privileged account, you need to do a little setup work. The steps provided here are detailed in an article in the MSDN Library (https://msdn.microsoft.com/library/en-us/vsdebug/html/vxgrfaspnetdebuggingsystemrequirements.asp).

In order to debug ASP.NET applications under Visual Studio 2003, you need to either be a member of the Administrators group (not a best practice) or be a member of the Debugger Users group, and have the ASP.NET worker process running under your user credentials.

Note that on Windows 2000 and Windows XP, running the ASP.NET worker process (aspnet_wp.exe) under your own account requires that you put your user credentials in the machine.config file for the machine where you’re debugging. As such, you should consider the security implications carefully and decide if they are appropriate for your environment. You could, for example, create an account whose sole purpose is developing and debugging your applications to prevent anyone who has access to machine.config from accessing your main user account. On Windows Server 2003 with IIS 6, you can use the IIS Manager to change the identity of the ASP.NET worker process (in this case, w3wp.exe), so you are not required to store the credentials for the desired account in a clear-text file.

To run the ASP.NET worker process under a user account on Windows 2000 or Windows XP:

  1. Open the machine.config file, located on your machine in the CONFIG folder under the path where you installed the runtime.
  2. Find the <processModel> section and change the user and password attributes to the name and password of the user account you want aspnet_wp.exe to run under.
  3. Save the machine.config file.
  4. Find the Temporary ASP.NET Files folder, which should be in the same path as the CONFIG folder. Right-click the Temporary ASP.NET Files folder and choose Properties from the shortcut menu.
  5. In the Temporary ASP.NET Files Properties dialog box, choose the Security tab (if you don’t see the Security tab, you may need to turn off simple file sharing in Explorer).
  6. Click the Advanced button.
  7. In the Access Control Settings for Temporary ASP.Net Files dialog box, click the Add button.
  8. Enter the user name in the Name box, and then click OK.
  9. In the Permission Entry for Temporary ASP.NET Files dialog box, give the user full permissions, and then click OK to close the Temporary ASP.NET Files Properties dialog box.

In order to run the ASP.NET worker process under a user account in Windows Server 2003, you simply change the identity associated with the AppPool for that application, which you can find on the Identity tab of the Properties dialog for the desired AppPool in IIS Manager. Note that the account to be configured must be a member of the IIS_WPG group in order for the worker process to run, and must also be configured with the “Adjust memory quotas for a process” and “Replace a process level token” rights.

Of course, you can avoid all of this configuration by moving to Visual Studio 2005, which allows you to debug local ASP.NET applications as a non-admin without any need for configuration, thanks to its built-in lightweight web server. And best of all, if you’re an MSDN subscriber, you can download the beta now, and get the final version as soon as it’s available.