views:

394

answers:

4

We're are looking to utilized 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.

+1  A: 

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

I'd ask them to document their security concerns.
Jon Galloway
I too would ask them!
A: 

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.

AaronS
To my knowledge this is wrong. Adding a wildcard handler would not change how an exe or bat file is handled. More specifically, unless it's specifically set up this way, the request should either be filtered out by the web application as a resource not found, or would be handled by the default handler, which would just return the file. (I've tested this locally, and was unable to reproduce the behavior you describe)
CoderTao
What about the web.config file then? Will IIS return this file if someone were to request it?
Striker
ASP.net does have it's own set of safeguards around this. However, you are still taking out the first line of defense of not allowing them to reach the ISAPI in the first place.
AaronS
This stuff won't execute in the aspnet_isapi pipeline anyhow. Of course, admins tend to fear that which they don't understand.
Wyatt Barnett
A: 

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).

Wyatt Barnett
A: 

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.

Tim Schneider
Chances are the framework's already a vulnerable surface on a machine running IIS, even 2k3/IIS6.
andrewbadera
Yes, but what I'm saying is that if an exploit exists that affects .NET's delivery of non-code files then that's potentially a security risk, and hence the attack surface is increased. I know of no such flaws and imo the actual chances of this being an issue is minimal (Hence saying it's not a concern I'd take seriously), but it is the best argument I could make for it being a security flaw so I tried to give a balanced perspective by stating the potential cause for concern then stating why I didn't think it would ever realistically be an issue.
Tim Schneider