Nowadays it's quite common for us to write server-based applications. These apps differ from desktop applications in many ways - one of the most important of which is how they handle security. For a desktop application, security is easy. The application runs in the security context of the user who loaded it. Whatever the user has rights to, the desktop app has rights to, and nothing more. Server-based applications, on the other hand, run all the time and have their own security context, in addition to others they may impersonate.

For many of the server-based applications we might write, there are few problems. IIS, for example, has built-in facilities that handle most of the security issues behind the scenes. However this magic is only available to standard ASP apps. Web services and non-IIS applications have to handle their security issues on their own. This means that you, the developer, have to design and code your app in a way that doesn't subvert Windows security or create opportunities for hackers.

Let's suppose, for example, we wanted to write a server-based application that monitored certain key system status values and reported the results to a common database. Our app would be configured by a desktop application that manipulates a central store, and the configuration would be shared by all servers running the app.

The naïve approach would be to create a single Windows service to handle the server-side processing of our app and a second desktop executable. Frankly, this is what most developers do; however, this approach is likely to create a serious hole in the network's security. Let's look at the issues.

Our server app has to communicate with other systems. This means it needs access to a service account that can authenticate across the domain. The built-in system account won't do. It also needs to execute privileged operations. Reading the Registry and accessing various PerfMon counters takes admin access on the machine in question. If we build this application as a single Windows service, then we've backed ourselves into requiring its service account to be a Domain Admin account. (It has to access multiple machines and be an admin on each system.) This means, for the most part, there is no limit to what our service can do - intentionally or unintentionally. Not good! Although this is what a lot of developers do nevertheless.

The problem with this single-service architecture is that it's very risky. By now we all know about buffer overruns, Trojans, etc. There are all sorts of ways to attack an application and cause it to do things that weren't intended, and that may cause damage. Our challenge as developers is to manage these risks and limit the damage that can be done. Let's look at an example of what not to do.

There are many commercial Windows applications that were built largely without regard for security. Your backup software may be one. Your system monitoring software or storage management software could be another. Most of these applications use only one service and need a highly privileged account with domain-wide access to function correctly. They can be configured to spawn other processes and these processes then run with elevated domain-wide privileges as well. It is common to find opportunities to use these applications to host Trojans or have them be the basis for other elevation of privilege attacks. (Security on a server's C: drive is one of the least-managed areas of most machines.)

A well-built server-based application can greatly reduce these risks. The solution is to use the right architecture, specifically: multiple Windows services. Let's look at how this work.

Our server app has the following requirements: to communicate with other systems, and to perform privileged functions on the local system. These tasks should be separated into two components: a worker service that acts locally, and a communication service that can reach other systems. The worker service can perform privileged acts on the local system using the built-in system account. This account has whatever permissions may be needed, but Windows will automatically restrict the scope of its actions to the local machine. By building our application this way, we use the built-in security of Windows as our ally to protect the network from any risks inherent in our application.

The second service, our communication service, can talk to other machines using an account that has permissions across the domain, but is severely restricted in the scope of what it can do. The communication service on the local machine can talk to the worker service on the same local machine using a restricted set of calls, which further limits the risk of damage being caused due to hacking or programming errors. (Not that there would ever be a bug in code that we might write...)

This gives us provable security. Windows automatically restricts the local system account to one machine. We know for sure (Windows is C2 certified) that our application hasn't created a hole in the network's security that can be exploited by others. This level of care also allows us to demonstrate the networks running our application can still meet the requirements for compliance with the laws governing data security and protection such as Sarbanes-Oxley, HIPAA, SEC 17-a4, etc.

While it may be a little bit more work to write secure server-based applications, today it is pretty much a requirement in law - and then we can all sleep better.

For more in-depth information on Windows Service account security, send an email to whitepapers@criticalsites.com. For help in managing your service accounts and server-based applications, take a look at Service Account Controller, available from e7software, by visiting www.e7software.com/products/sac.

• Source Code