IIS6 Wildcard Mapping Security Concerns?

Question

We are looking to utilize extensionless URL's for the first time in our organization. We've requested our sys admins add a wildcard mapping to IIS6 so all requests get processed through the asp.net. They are pushing back, citing security concerns. I don't have enough information about potential security issues with the wildcard mapping to know what security issues it may or may not create. Any feedback would be appreciated.

Answer 1

Basically by adding wildcard mapping to IIS6 then ALL requests will be processed through the .net framework. I am not sure about security concerns but know that the performance disadvantage has never been provern

see link text

Answer 2

Big issue, I suspect, is that most admin types fear that which they don't understand. They grok IIS, but the whole ASP.NET pipeline is foreign. Get them to document their concerns then you can shoot them down one-by-one.

There is a pretty legitimate performance concern with wildcard mapping, but that can easily be solved by pushing the non-secured static files to another virtual site (or even a separately mapped virtual directory within the site sans mappings).

Answer 3

Only possible security concern would be from an increased attack surface, cause an attacker could now attack the .NET framework and not just IIS. But that's the same risk you take installing any listening applications on your server.

The misunderstanding I assume is that they think this binding will make anything run as .NET, it doesn't. It just makes .NET handle the delivery of it. Only if it's configured to be executed via HttpModule settings in the web.config will it actually run the code in any files other than the default bindings (Which are the ones it hooks up before you put in the wildcard anyway).

Performance is a reasonable issue to raise, but I don't think the security implications are a big deal.

Answer 4

The potential issue is you would now be allowing requests for extensions such as .exe to be executed on the server, and not filtered out by IIS before handing requests off to the ISAPI.

If you have any .exe, bat, or other executable files anywhere in an IIS path, any user would be able to execute them.

If you're careful in setting up IIS websites, and virtual directories so they don't contain anything that could be used maliciously, then you should be OK.