Despite improvements over previous standards, ASP.NET still has its fair share of vulnerabilities. Use these tips from to help secure your ASP.NET applications

From a security standpoint, ASP.NET represents a big improvement over previous incarnations of ASP. With the new platform, developers have easy methods to programmatically validate user input and access to built-in features that lock down an application. Additionally, the .NET runtime’s support of garbage collection and safe strings largely negates the success of traditional attacks. A properly secured .NET application is not only hardened against an attack, but it also limits the amount of damage that an occasional breech can create.

But despite these significant gains, ASP.NET is certainly no security panacea. Security analyst H.D. Moore, who presented three fairly major security holes in ASP.NET at the CanSecWest conference in April, says all these wonderful new features don’t amount to a hill of beans unless developers use them. Moore recommends the following simple security tips for bulletproofing your ASP.NET applications.

Exercise a little configuration control
As a general rule, never place anything in the Web root that you aren’t absolutely comfortable letting a hacker see. The exception here is any file extension that’s mapped to an ISAPI handler, which restricts access to files with extensions like .aspx, .cs, and .vb. On the other hand, files ending in .txt, .csv, and .xml are not automatically protected and can be accessed by anyone browsing the site.

Before placing any new application in production, be sure to disable tracing and debugging support, and make sure the customErrors tag in the web.config file is not set to “off.” These safeguards will help to prevent possible leaks of information such as filenames and paths, and possibly even source code, to the outside world when an error occurs in the application.

Also, clean up your project directories before putting an application in production. When deploying a new application, make sure you remove all of the Visual Studio project and temporary files in the application directory. The .sln and .slo files are not mapped to the ISAPI access filter and can consequently be accessed from the Internet if someone can guess the name of your project, which is usually a trivial task.

Avoid cookieless session management
One of the glaring problems that Moore uncovered during his evaluation of ASP.NET involved a “hijack” vulnerability in applications using the “cookie-less session management” scheme. This scheme embeds a session identifier into every URL to let the server identify a particular client. The trouble is that when a server using this feature receives a previously unknown but otherwise valid session identifier, it creates a new session to go along with it. A clever attacker can take advantage of this by “feeding” a legitimate user a URL containing a known, valid session identifier, which the attacker can use to access the system after it authenticates the duped user.

This is an insidious attack, says Moore, because the URL fed to the user would never look suspicious because only the session ID would be bogus. He recommends that developers simply avoid using cookieless session management until Microsoft removes this vulnerability.

Stay in the sandbox
While the .NET runtime’s managed environment would seem to make traditional attacks like a buffer overrun impossible to pull off, Moore points to the overflow problem he found in the StateServer class as an example of the impossible becoming possible. It appears that there’s a call to unmanaged code somewhere in StateServer with input that isn’t being correctly bounds-checked.

Moore says that developers should stick with .NET’s managed “sandbox” API whenever possible, since any call to unmanaged code could carry similar risks. However, sometimes you need that native code functionality, which brings us to our next tip.

Validate, validate, validate
Despite all the fancy new plumbing, the same old rules regarding validation of user input still apply. Developers should take full advantage of the powerful Validator controls, created by extending the System.Web.UI.Validator interface, to sanitise user input before using it internally. If you’ve never heard of .NET’s validators, you owe it to yourself to read up on them.

Use a cast
When using numeric fields in a database-driven application, make sure you actually cast those variables to an appropriate numeric type before using them. Doing so will prevent SQL insertion attacks by throwing an exception if a user places something nonnumeric into that field. With a little more work, the error handler could be configured to fire off an alert, or write to a log file, almost like a mini application-level intrusion detection system.

Less than trustworthy?
If you must install a Web application on your system that may not be entirely trustworthy, take advantage of the settings available in web.config to run that application under a different user account and then restrict what that account can access. Additionally, you can use the Internet Services Manager to configure the trust level for an application to provide a bit more security. Selecting Low Trust will run an application in its own process space, so that it theoretically will not be able to adversely affect the rest of the system or other Web apps if it is compromised or were to crash for some reason.

After a few years of trying to fill Bill Gates’ shoes as Microsoft’s chief software architect, Ray Ozzie is starting to hit his stride. In a remarkable strategy memo to employees (embedded below), Ozzie essentially shifts Microsoft’s mission from one of creating software for the PC and stand-alone servers to creating an interconnecting mesh between devices and people. He is not abandoning Windows or Office, but he is saying that the value of Microsoft’s software will increasingly depend less on what it can do on its own than what it can do with others. It is not about software anymore so much as it is about Web-based services. Ray, welcome to the club.

Excerpt:

Central to this strategy is our embrace of both a world of the web and a world of devices. Over the past ten years, the PC era has given way to an era in which the web is at the center of our experiences – experiences delivered not just through the browser but also through many different devices including PCs, phones, media players, game consoles, set-top boxes and televisions, cars, and more.

Guiding Principles

There are three overarching principles guiding our services strategy – principles informing the design and development of products being implemented across all parts of Microsoft, for both individuals and business.

    1. The Web is the Hub of our social mesh and our device mesh.

    The web is first and foremost a mesh of people. . . . All applications will grow to recognize and utilize the inherent group-forming aspects of their connection to the web, in ways that will become fundamental to our experiences. In scenarios ranging from productivity to media and entertainment, social mesh notions of linking, sharing, ranking and tagging will become as familiar as File, Edit and View. . . . To individuals, the concept of “My Computer” will give way to the concept of a personal mesh of devices – a means by which all of your devices are brought together, managed through the web, as a seamless whole.

    2. The Power of “Choice” as business moves to embrace the cloud.

    Most major enterprises are in the early stages of a significant infrastructural transition – from the use of dedicated and sometimes very expensive application servers, to the use of virtualization and commodity hardware to consolidate those enterprise applications on computing and storage grids constructed within their data center. . . . Driven in large part by the high-scale requirements of consumer services, the value of this utility computing model is most clearly evident in cloud-based internet services.

    Software built explicitly to provide a significant level of server/service symmetry will afford choice and flexibility in developing, operating, migrating and managing such systems in highly varied enterprise deployment environments that are distributed and federated between the enterprise data center and the internet cloud.

    3.Small Pieces Loosely Joined for developers, within the cloud and across a world of devices.

    Application design patterns at both the front- and back-end are transitioning toward being compositions and in some cases loose federations of cooperating systems, where standards and interoperability are essential. . . . At a higher level, myriad options exist for delivering applications to the user: The web browser, unique in its ubiquity; the PC, unique in how it brings together interactivity/experience, mobility and storage; the phone, unique in its extreme mobility. Developers will need to build applications that can be delivered seamlessly across a loosely coupled device mesh by utilizing a common set of tools, languages, runtimes and frameworks – a common toolset that spans from the service in the cloud to enterprise server, and from the PC to the browser to the phone.