Last month (.NETDJ, Vol. 1, issue 12) we demonstrated a simple technique that allows you to avoid storing passwords in clear text, making your .NET applications more secure and safer should they somehow be compromised. In this article, we want to step back a bit and look at the big picture: application security from end to end.

When it comes to security, we developers are in charge. Security is not something that can be pushed off onto the network administrator; it is an integral aspect of an application's overall architecture. A well-built application should be inherently secure. A poorly constructed program may be impossible to secure. More important, you cannot graft security onto your application in any cost-effective way after it has been written. If you want your application to be secure, you have to address the issue up front, not as an afterthought.

The purpose of this article is to give you an overview of where security enters the picture and help you understand the points at which you as a developer will need to coordinate with your network administration staff to make it all work. In our experience, very few people are expert at both development and network administration - and security touches both of these areas. As you determine your application's architecture, its impact on your network and its infrastructure has to be included in your vision. Successful deployment may require the assistance of your network staff.

Beyond world-class application design, you can also install add-on technology to help with security. While a discussion of this is beyond what we can cover here, we would encourage you to investigate Microsoft's ISA Server and/or third-party firewall tools.

Also, you should understand our overall perspective. No application can be made completely hacker proof at any reasonable cost (the news reminds us of this every month). If someone wants to get in badly enough, they will. Therefore a well-built application needs layers of security and protection. If someone gets past your first barrier, they just find another, and another, and then another.... The secret of success is to make it too expensive for someone to spend the time and trouble necessary to get at the heart of your system.

Our discussion centers on a "typical" .NET application - namely a browser-based system with a database back end. We'll start at the user's PC and continue through to the database.

The first thing to consider is what happens at the user's computer. If this is an intranet application, only available to client computers on your company's network, you may be able to use Windows integrated security to handle authentication. This has several advantages, not the least of which is that Microsoft has done all the work and we don't need to do much (beyond correctly configuring the Web server).

On the other hand, if this is an Internet or extranet application or one where employees may use their home or public PCs, then the task of securing our application starts here. If we don't do anything, the ID and password our users enter, along with any other data they may submit, is handled in clear text. This means that at a public terminal, or one with a spyware virus, this ID, and the rest of the data that may be entered, is available for others to capture and use. To avoid this, we want a secure connection over which to receive users' credentials.

Microsoft's IIS and other Web servers provide this facility for us via a secure HTTP (HTTPS) connection. To require a secure connection with authentication we have to take the following steps:

• Anonymous connections must be turned off at the Web server.
• A digital certificate must be installed (see the sidebar on digital certificates).
• The connection must be redirected to the port for secure applications (normally 443).

Once we have the users' secrets at the server, we must protect them here too. Last month we talked about how to store critical information securely, so we won't go into it here. Suffice it to say that we don't want to undo the benefit of a secure connection by handling confidential information in clear text at the client or the server.

Now that we've made it safely to the server, we need to look at how our server-side application runs. Our secure, authenticated channel gives us a private connection to known users, but it also treats all these users as equals. While this might be okay for some applications, many applications have classes of users. It is important to know that Microsoft's .NET provides us with a couple of alternatives that we should consider to further refine our application's security infrastructure.

The first of these is Forms-based security. Forms-based security relies on the authenticated user's credentials and is an extension to other methods of user- and role-based security. .NET allows us to attach security to either accounts set up in Windows or accounts held in our own database - and thereby control who can access each page of our application.

In essence, this is a classic implementation of role-based security, its model being that each of the functions of our application has as its entry point a form through which we can control access. By using Forms-based security we can, for example, make sure that ordinary users cannot get to the screens used by administrators and managers - simply by checking the roles assigned to the current user. This relieves us of the burden of having to write code that checks access rights using some homegrown process. The following code snippet shows a sample Web.Config authentication section with Forms authentication enabled.

<authentication mode="Forms">
<forms name="IntranetAuth"
loginUrl="login.aspx" protection="All" path="/" />
</authentication>

The .NET Framework also provides for code-based security. Within .NET we can set the permissions and limit the functions that specific pieces of our application can perform. This is new with .NET. For the first time we can apply a limit that relates to not only users, but also to system function. For example, a module can be restricted to have just read-only access to certain data. This means that regardless of the user's rights to the data, the module in question is allowed only to read, not to write. This is very powerful. We can use it to protect our application against user error and even (not that this would ever happen) coding errors.

Finally, we need to look at the connection between our application and its data. Once our user has been successfully authenticated, most Web-based applications use a proxy account for access to the application's database and other resources. The rights associated with this proxy account are commonly administered through Windows integrated security.

But what we see, more often than not, is one proxy account used for everything. This means the sole barrier in the system is user authentication. We can do better.

The majority of the interaction in any system is reading data. Why not use a proxy account whose access is limited to read-only to perform this function? In fact, we should. This not only protects the data from errors in our code (not that we would ever have any...), but also from any successful hacks of this part of our application.

In those few instances where our application needs to write or modify data, we can use a second proxy account with write permission. This gives us a much smaller part of the code over which we need to apply our most rigorous QA.

We can also control the character of the connection between the Web server and our database. The majority of today's hacks and hackers concentrate on the TCP/IP protocol and services. If you want to be ultra-secure, Windows still allows you to make a NetBEUI connection between your Web server and the database. This further eliminates opportunities for hacking. The majority of network hacks rely on characteristics of TCP/IP, which NetBEUI does not support. A fine point, to be sure, but security is like insurance; it is up to you to decide how much you want to buy and which risks you want to continue to live with.

Finally, there is security we can apply at the database. We'll save this discussion for a future issue.

Conclusion
Our hope is that you will take away the following from this article:

• Application security is a matter of good design. It is not something you lay on top once the application is already built.
• To do the job right, you need to include the network infrastructure.
• The .NET Framework includes features that make the old ways easier - as well as adding the new ability to apply restrictions to the code itself.

About Digital Certificates
A digital certificate is an element of the industry-standard Public Key Infrastructure (PKI). Basically, it is a string of bits that works in conjunction with a secure algorithm to provide the ability to sign or secure a digital object or a network connection.

There are organizations in the business of providing digital certificates and verifying their authenticity. For this they charge you a fee. You can also create your own digital certificates using Microsoft's or other development tools.

If you create your own certificate, since you are not a public authority for validating certificates your users will be notified that the certificate in your application cannot be validated, but it will work just the same and give you a secure connection to your users.