Secure ASP.NET
LANGUAGES: ALL
ASP.NET VERSIONS: 2.0
Defense in Depth
Why Not Write Partially Trusted Apps?
By Don Kiely
I recently spoke at Whidbey Blast, a one-day, Visual Studio 2005 conference hosted by the Northern Colorado .NET Users Group. I did the keynote and a session about MSBuild, then sat in on some of the other sessions that covered a variety of upcoming technologies.
One of the sessions was by Keith Brown, security guru and a fellow Visual Developer - Security MVP. He asked how many people develop or have developed partially trusted applications. Only one person out of perhaps the 50 people in the room shyly raised his hand, and Keith indicated that was pretty typical. He also mentioned that if you develop an Indigo-based application, the app has to run with full trust. This is because the Indigo team doesn t believe that enough people write partially trusted applications to make it worthwhile for them to do the work to make Indigo usable by partially trusted applications. In the car on the way to the airport, my host Kathleen Dollard said she doesn t write them because clients aren t willing to pay for them.
I was flabbergasted! Have I been living in twisted dream world?
If all this is true, it s going to mean that we are making the computing world no safer from attacks. Are we so focused on perimeter security (using firewalls and locking down IIS, for example) and post-infection eradication (spyware and virus scanning) that we are ignoring the fundamental ways that we can make our users systems more secure? No wonder so many developers still run every day with admin privileges and don t use the great (but not perfect) tools that Microsoft gives us in Visual Studio and the .NET Framework. Are developers just waiting for the operating system (Windows Vista and its as-yet-unnamed server version) to become more secure to solve all our security problems? It won t, because clever attackers will eventually find the inevitable chinks in the armor of any complex operating system. Have we learned nothing from all the clever attacks over the last few years? If we re waiting for them to solve our problems, no wonder Microsoft takes so much heat for security issues. Are we as developers not willing to admit our complicity in the problem?
This is no idle speculation. An important security principal for any kind of system, both for software and in everyday life, is defense in depth. Defense in depth is the reason that Microsoft is introducing data encryption in SQL Server 2005 and why medieval castles frequently had moats, thick tall walls, and inner defenses. Even if an attacker penetrates outer defenses, such as through cross-site scripting or by burning down the outer timber gate, the prize is not necessarily won. Defense in depth means layers of defenses. Sometimes the toughest defenses are on the outside the first level an attacker must breech and sometimes they are reserved for the defense of last resort, where penetration means the attacker has attained the prize, whatever it might be the virgin princess or millions of active credit cards.
By writing ASP.NET applications that require full trust to run, a developer is contributing to insecure systems in two ways. An application that requires full trust becomes an attack vector for outer-defense attacks, the initial place an attacker can get a toehold into a server. Consider cross-site scripting or SQL injection attacks. A full trust application that is susceptible to these kinds of attacks and the many others that have surfaced, as well as those that haven t even been thought up yet are more open to damage than those that are tightly written and minimally trusted. The other way that full trust applications contribute to insecure systems is by providing a poor inner defense. If your full trust application is installed on a server, attacks that make it through other defenses can conceivably make use of your fully trusted DLLs to perform some nastiness. Fully trusted applications are evil.
But let s be realistic. A fully trusted application circumvents all the safe, fuzzy protections built into the Common Language Runtime (CLR), which serves as .NET s protector. The CLR implements code access security, type safety, and other protections that can make code safer. But the code is still running in the security context of some Windows login that has some set of privileges in the operating system. Please, I beg you, don t let that security context be that of an administrator, either local or domain. All may not be lost if you restrict the privileges with which server applications run, but all too often apps run with system-level privileges. A fully trusted application running with that kind of security context is a sitting duck for attackers.
The moral: WRITE PARTIALLY TRUSTED APPLICATIONS!
I d love to hear your thoughts about this topic. Send me email at mailto:[email protected].
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/.
