This is a mirror of official site: http://jasper-net.blogspot.com/

Secure or a Security Hole, hardening your Area

| Sunday, August 22, 2010
What’s the best way to secure a MVC area from anonymous users? A customer on the MVC Forum asked this question. Several of the responses where horrifyingly wrong. The first suggestion was the traditional ASP.NET WebForms approach, add a web.config to the folder you want to restrict. MVC uses routes and does not map URLs to physical file locations like WebForms, PHP and traditional web servers. Using Web.config will open a security hole in your site.

The second suggestion was restriction of routes via route constraints. Levi (the security expert on the MVC team) wrote:

Do not use a route constraint!

Let me be perfectly clear on this.  The only supported way of doing this is to have a base class with an [Authorize] attribute, then to have each controller type subclass that base type.  Any other way will open a security hole.

In general, it's extremely difficult to figure out all the possible controllers that a particular route can hit.  Even if you think that a route can only be used to hit one particular controller or group of controllers, there's probably a set of inputs that a user can feed to the system to direct it to a controller it wasn't intended to hit.

This is why we say that Routing should never be used to make a security decision.  Routing is just essentially a communication channel with your application; it's a way to make your URLs pretty.  The controller is the resource you're actually trying to protect.  So any security decisions should be done at the controller level rather than at the route level.  And currently the only way to associate a security decision with a controller is to slap an [Authorize] attribute (or some other similar attribute that you write that subclasses it) on it.

Say you have a FooController inside your Blog area.  Normally you would access this via /Blog/Foo/Action.  However, with the default {controller}/{action}/{id} route, you could also probably access this via just /Foo/Action (without the Blog prefix).  You may or may not be able to repro this on your own machine depending on your route configuration, but it's one of many examples.

Read more: Ricka on MVC & Dynamic Data

Posted via email from .NET Info

0 comments: