Question

I’m playing around with MVC 4 for the first time to check out what’s been changed/added/etc compared to MVC 3.

To start off, I created a blank MVC 4 Web Application and started building from scratch.

One of the first things that I noticed that is different in MVC 4 is the fact that the following web.config settings have no affect on the accessibility of the web pages:

<configuration>
    <location path="">
    <system.web>
      <authorization>
        <deny users="?"/>
      </authorization>
    </system.web>
    </location>
    .....
</configuration>

Back in MVC 3, the authorization settings above would deny all anonymous users from accessing any content within the site. However, if I add the same settings to an MVC4 Web.config file, an anonymous has free reign over an URL that s/he chooses.

What do I need to do in MVC 4 to lock-down all paths like I did in MVC 3?

Answer 1

Take a look at Securing your ASP.NET MVC 4 App and the new AllowAnonymous Attribute.

You cannot use routing or web.config files to secure your MVC application (Any Version). The only supported way to secure your MVC application is to apply the Authorize attribute…

Quote

MVC uses routes and does not map URLs to physical file locations like WebForms, PHP and traditional web servers. Therefore using web.config will definitely open a security hole in your site.

The product team will have a communication if this changes in the future, but for now it is without exception the rule.

Examples:

Start with the default ASP.Net MVC project (internet/intranet).

Edit the web.config adding:

<location path="Home">
  <system.web>
    <authorization>
      <deny users="*">
    </authorization>
  </system.web>
</location>

Run the project, by default you will use the Default route /Home/Index and you see content, simply bypassing the web.config with no changes to the default template. Why? Because the ASP.Net pipeline is comparing the URL requested to the location specified in the web.config. However, after the Authorization Event has been executed in the pipeline the routing taking place (Default routing or custom routing) and allows access to the supposedly restricted area.

Additionally, any MVC Redirect() will also by-pass the same security measures as again the routing takes place after the Authorization Pipeline Event.

I don’t think anyone should accept sorta working security. Do it correctly the first time, don’t be lazy and use something that wasn’t designed to be used with a specific technology.