Co-Sponsored by: Latest Features  • Custom Criteria  • JSON and XML  • Build a Message Box the AJAX Way: Part II  • Global Events  • Convention Over Configuration Article Rating Rate this article on a scale from 0 to 5 5 Best 4   3   2   1   0 Worst Email Tell a friend about this article!

Secure ASP.NET

LANGUAGES: ALL

ASP.NET VERSIONS: 2.0

No Site Is Secure without Monitoring

Build Secure Apps — and Keep them Secure

By Don Kiely

Version 2.0 of the .NET Framework contains a slew of new security features. The new authentication and authorization features, such as membership management, get all the attention as sexy new features — and they deserve it, because they provide common infrastructure that we’ve had to implement over and over again in earlier Web development technologies.

It always amazes me to go into a client’s office and explore with them all the great features they’ve built into an application using these sexy features, only to discover they don’t do any auditing or monitoring of the application. They know that they built a rock-solid, secure app, so what’s to monitor?

What’s to monitor?!? Listen, I’ve been saying this for years to clients and students: If you’re not monitoring an app, IT IS NOT SECURE. Period.

Here’s the problem. Hackers are clever people, and they are constantly devoting their considerable talents to coming up with new ways to attack your app. No matter how bulletproof you build the app, unless you monitor it constantly you have no idea whether it is being probed for weaknesses, no idea that some junior developer changed one seemingly inconsequential web.config setting that opened a big security hole, no clue that your site is undergoing a brand new kind of attack (they almost always leave subtle traces that you can detect), no idea of any of the many early warning signs that almost always accompany a full-on attack.

Let me be very clear: Monitoring is crucial to the security of an application. You have to build it well and then watch it carefully to make sure that it stays secure. This usually means some combination of event logging and notifications. And, YOU HAVE TO LOOK AT THE LOGS! I’m sorry for all the shouting in this column, but I’ve also seen people set up elaborate logging to monitor an app (often way over-engineered), then never look at the logs, or have notification e-mails redirected automatically to an Outlook folder that they never read.

This is not a secure application.

Fortunately, ASP.NET 2.0 has a slew of new features that can help you monitor an application. They fall under the general category of “health monitoring” features. Essentially, ASP.NET health monitoring is a set of standard events and providers that can log or take other actions in response to an event. It also exposes the infrastructure so that you can create custom events and take some unique action in response to an event. Combined with log analysis tools (the subject of another column some day), this can provide you with some great information about the ongoing security of your application.

At the end of this column I’ve listed a few references where you can get all the nitty-gritty details of health monitoring. If you’re familiar with the Provider pattern and how events work in the .NET Framework, you’ll pick it up quickly. As described in the VS 2005 documentation, here is how the health monitoring events are generated and fired:

• When an application starts, ASP.NET builds a merged collection of configuration settings. If you have defined providers and events in the configuration files (mainly web.config), those events are included in the merged collection.
• Some kind of monitored event occurs, such as when it detects a brute force authentication attack.
• ASP.NET looks at what events you’ve configured (or those for which you have not changed the default).
• If the event is being listened for, ASP.NET builds an instance of the Web event class specified and raises it.
• Your defined event provider consumes the event and creates a log entry, sends an e-mail, or whatever the provider is supposed to do in response to the event.

ASP.NET 2.0 provides a lot of great tools to build secure apps and keep them secure. It takes a little work, but the rewards are so very worth it. Do It Today!

What Happened to the .NET Configuration Tool?

If you’ve used the .NET Configuration Tool to configure code-access security policy, you might be dismayed to find that in some installations of .NET the tool is nowhere to be found. That’s because you’re looking at a machine with only the .NET redistributable installed. Specifically, the .NET Framework SDK is not installed on that machine. For security reasons — keep non-essential security-related utilities that aren’t necessary for everyday operation off a machine — the tool has moved to the SDK. Shawn Farkas of Microsoft has the details on the .NET Security Blog at http://blogs.msdn.com/shawnfa/archive/2006/02/08/527663.aspx.

References

• How To: Instrument ASP.NET 2.0 Applications for Security (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/paght000016.asp)
• How To: Use Health Monitoring in ASP.NET 2.0 (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/paght000011.asp)
• ASP.NET Health Monitoring topic in the VS 2005 documentation (ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_aspnetcon/html/7efd3758-a1fe-4a2c-959a-88de931f6909.htm)

Don Kiely, MVP, MCSD, is a senior technology consultant, building custom applications as well as providing business and technology consulting services. His development work involves tools such as SQL Server, Visual Basic, C#, ASP.NET, and Microsoft Office. He writes regularly for several trade journals, and trains developers in database and .NET technologies. You can reach Don at mailto:donkiely@computer.org and read his blog at http://www.sqljunkies.com/weblog/donkiely/.