ASP.NET Partial Trust Applications, 2002-2012, R.I.P.
Microsoft says that partial trust applications are now obsolete
December 5, 2013
![ASP.NET Partial Trust Applications, 2002-2012, R.I.P. ASP.NET Partial Trust Applications, 2002-2012, R.I.P.](https://eu-images.contentstack.com/v3/assets/blt07f68461ccd75245/blt5d6e928245a93cf7/66192e344485aed92d92cb36/securitylock_0_4.jpg?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
Related: "New Visual Studio 2013 Security Feature: ASP.NET Identity"
I've written a lot over the years here on Dev Pro about the trust levels of ASP.NET applications, particularly when my column focused on ASP.NET security. And I've helped an awful lot of developers navigate the minefields of partially trusted applications, making those applications more secure in an unsecure world. Or so I thought, up until the latter part of the last decade when the shiny façade of partial trust began to tarnish.
So I'm chagrined to admit that I missed a major change, a tectonic shift in ASP.NET security, a fall-off-the-barstool slap in the head type of change, back in June 2012. That was when Microsoft published the article, "ASP.NET Partial Trust does not guarantee application isolation," where the company essentially admitted that partial trust is obsolete. The fact that partial trust is obsolete wasn't a big surprise given the problems festering within it for a while now. However, the fact that Microsoft made the statement as an official policy change was a surprise.
Levi Broderick, who works on the ASP.NET team at Microsoft with a focus on the ASP.NET core runtime and web security, made it clear just how dead partial trust is in a response to a Stack Overflow question in June of this year. The most important points in his short reply include:
"The official position of the ASP.NET team is that Medium Trust is obsolete. This means a few things:
We are automatically resolving all Medium Trust-related bugs reported to us as "won't fix".
We have provided guidance to hosters that they should migrate away from Medium Trust and use proper OS-level isolation instead.
We are removing Medium Trust support from the frameworks we develop (MVC, WebAPI, SignalR, and so on). Going forward, applications built on these frameworks will require Full Trust."
More concisely, yes, partial trust is a lost cause. If you're interested in the reasons for the shift, the article "ASP.NET Security and the Importance of KB2698981 in Cloud Environments Threat Brief" has some interesting information. But there's surprisingly little discussion about the problem and what brought on the change.
Related: "OWASP Top 10 Project: Security Vulnerabilities for ASP.NET"
That's not to say that partial trust is no longer a viable part of code access security in the .NET Framework or even in some ASP.NET scenarios. All we're talking about here is partial trust within ASP.NET applications, as Levi makes clear in his Stack Overflow reply. It's still a viable security technique in other types of applications presently, but the major reason Microsoft previously recommend using it in ASP.NET applications was to provide application isolation on shared servers.
This is definitely one place where Microsoft is walking the talk. They have been releasing more and more APIs that won't run in anything but full trust, where some of these APIs even thwart different isolation techniques that developers have come up with over the years to run code requiring full trust to run in partially trusted environments. As Levi mentions, this includes MVC, Web API, SignalR, and other frameworks.
Why has this change, a rather momentous change of direction for ASP.NET, received so little attention? I suspect that there are two main reasons. The first is that most developers who were forced to work in medium or custom trust levels were just plain relieved that they finally had Microsoft's blessing to no longer needing to set up security policies and handle several security exceptions in their code. Writing good quality partial trust code is hard, and you have to really work to anticipate how code can fail because of permissions problems in a web application. Although there are nice tools that Microsoft has provided throughout the years as well as some nifty third party tools, it's certainly a relief for developers. Ding dong, the witch is dead! Which old witch? The wicked witch!
The second reason for the lack of attention is actually the one that I fear is the far more likely one: Too many web developers pay lip service to security and saw anything but full trust as an annoyance only to be dealt with when forced on them, usually when hosting an application on a shared server. And shared servers are used both by general web hosting companies and large organizations. For these developers, the ASP.NET partial trust article finally gives the Microsoft stamp of approval on what they thought all along, that anything other than full trust was a waste of time.
Can you hear the collective sigh of relief? Well, you might just have heard it in the middle of last year.
So what replaces partial trust in ASP.NET, particularly on shared servers, for application isolation? The responsibility now lies where it probably should have always been in the first place, in the operating system. Quoting Microsoft's partial trust article:
"Configuring ASP.NET page framework applications to run in separate low-privileged processes (by using individual application pools) is the recommended procedure to make sure of isolation from other ASP.NET page framework applications on the same web server."
The rest of the article goes on to describe how to implement this isolation is in various versions of Windows and IIS, as well as using discretionary access control lists (DACLs) to secure files for each web application.
I feel like an era of my life has officially passed. Only time will tell if these latest guidelines truly make our applications more secure.
About the Author
You May Also Like