Secure ASP.NET
LANGUAGES: ALL
ASP.NET VERSIONS: 2.0
Vista Point
Looking Forward to 2.0
By Don Kiely
It s September 8, 2005, some 60 days and counting to the final release of Visual Studio 2005, SQL Server 2005, and version 2.0 of the .NET Framework and ASP.NET, all scheduled for release the week of November 7. Up to now in this column I ve stuck to writing about security issues in production versions of ASP.NET, meaning versions 1.0 and 1.1, so that we can all get real work done without being too distracted by the future. But since Microsoft has issued Go Live licenses for testing and partial deployment of Web sites using the new technologies, and since the final feature set has settled down, I think it is time to start looking forward to ASP.NET 2.0 and how we ll handle the new world of security therein. And it is a very different world, as Microsoft has finally taken security very seriously and is providing the tools we need to build secure sites that can withstand the latest attacks.
That last statement requires comment. Security is a moving target, and with the current state of our understanding of what security means on the Web, the best we can do is protect against the attacks we see today and the attacks we can envision might appear tomorrow. After all, Microsoft is powered by mere humans (comparisons to the Borg notwithstanding) and, although many of those humans are incredibly smart, they are using the same clouded crystal ball as the rest of us. So while the security enhancements in all the new 2005 and 2.0 tools are impressive, the best we can hope for is that they will repel today s attacks and provide some level of resilience to the next round of attacks that clever hackers will dream up. The moral of the story: Security is a moving target and you can t let your guard down, even for a moment. And patch, patch, patch!
On to ASP.NET 2.0 security enhancements, starting with the usual caveat: Until the final release of ASP.NET 2.0 and the other tools, things can change. I think that they are settling down into what they ll actually look like at release, but things could still change. I ll start covering the release version once it s out, of course, but for the next couple of months what I think and say is based on the latest beta, CTP, or RC versions.
I see the enhancements as falling into two broad categories: what I call application infrastructure and core security. The application infrastructure features are those that ASP.NET provides out of the box; what we used to have to implement for each application, common services such as membership management, role management, and forms authentication. For example, many sites need to control access to all or parts of the site based on a user s identity and assigned role, with supporting information typically stored in some kind of a data store such as SQL Server. ASP.NET 2.0 provides all the infrastructure you need to use and extend such membership management to secure your site against unauthorized users.
The other category of features forms core security. These are the lower-level enhancements that provide the security plumbing for all Web applications that keep them safe from clever attacks that try to overrun buffers, con highly privileged code into doing bad things, and get access to sensitive information. I include ASP.NET 2.0 s health monitoring features as part of core security, because they really aren t part of the application that the user cares about but protects the site by alerting you to problems as quickly as possible. I personally find the core security features more interesting, but core security and application infrastructure are deeply integrated and both are necessary for secure applications.
In the months to come, I ll talk about many features of both application infrastructure and core security. In this column, however, I d like to revisit a topic that I wrote a series of columns about in late 2004: partially trusted Web applications (see Security Alert, Play It Safe, Permission to Trust, and Comparable Consent). In those columns I argued three things:
- Never develop or deploy a fully trusted ASP.NET application;
- never use one of the pre-defined ASP.NET trust levels; and, most importantly,
- develop a custom trust level for each application you develop and deploy.
The Medium Trust Level was, is, and will be a reasonable starting place for developing your own custom trust level. Comparing the default web_mediumtrust.config file in .NET 1.1 and 2.0 shows that the medium trust level in 2.0 has a slightly different set of permissions that Code Access Security (CAS) in the Common Language Runtime (CLR) assigns to a medium trust application:
- An application now gets the SqlNotificationPermission, presumably because ASP.NET 2.0 features like caching now rely on SQL Server s Notification Services to know when to update the cache. It is an unrestricted permission.
- An application now gets the SmtpPermission. I guess Microsoft expects that most applications need to send e-mails. It is a restricted permission, granted Connect permission, which allows connection to an SMTP host on the default port.
These are pretty minor tweaks, mostly to acknowledge the realities of the environment of most ASP.NET applications. But it is still an inappropriate trust level for any particular ASP.NET application. Why? Because it grants permissions that are unnecessary for most applications, and most non-trivial applications will need an additional permission or two. For example, I haven t seen many applications that need the PrintingPermission, which controls access to printers. It is a restricted permission, set to the DefaultPrinting level, which allows the application to print to the default printer only and safe printing through a semi-restricted dialog box.
The good news is that creating a custom trust level in ASP.NET 2.0 is pretty much the same process as in ASP.NET 1.1. The bad news is that it is still going to require that you carefully think through the permissions your application requires and grant exactly those permissions, no more and no less.
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:[email protected] and read his blog at http://www.sqljunkies.com/weblog/donkiely/.
