Some time ago,
Phil Haack posted a
really cool entry on the
System.Web.Routing feature, new in
.NET 3.5 SP1.
In his post, he noted a "subtle potential security issue" where you might think you've secured a particular directory via a nested web.config and appropriate
<authorization> element, but, in reality, you've totally circumvented that security. Phil then re-included his security check by calling to the UrlAuthorizationModule.CheckUrlAccessForPrincipal method in his
IRouteHandler implementation to determine if the user has permissions to the web resource being requested. Here are two alternative approaches without having to add the UrlAuthorizationModule code:
Option 1: Change the "BackDoor" Route
Since the rule is to deny all requests to resources in the Admin sub-directory, if we change the route slightly to this:
routes.MapWebFormRoute("Secret", "admin/BackDoor", "~/Admin/SecretPage.aspx", false);
we can get the desired result:
Option 2: Add a Location Path to the Authorization Configuration
Leaving the Backdoor route as it is in the original demo code, another approach to take would be to add a <location> element around the authorization rule. Thus, in the parent web.config file, we could add this configuration:
<location path="backdoor">
<system.web>
<authorization>
<deny users="*"/>
</authorization>
</system.web>
</location>
and achieve the desired result:
All in all, though, I'm glad Phil chose the route he did because I had the chance to learn about the
UrlAuthorizationModule.