IIS6 通配符映射安全问题？
我们希望在我们的组织中首次使用无扩展名 URL。 我们已要求系统管理员向 IIS6 添加通配符映射，以便所有请求都通过 asp.net 进行处理。 他们以安全问题为由进行反击。 我没有足够的有关通配符映射潜在安全问题的信息，无法了解它可能会或不会造成哪些安全问题。 对于任何反馈，我们都表示感谢。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
基本上，通过向 IIS6 添加通配符映射，所有请求都将通过 .net 框架进行处理。 我不确定安全问题，但知道性能劣势从未被证明，
请参阅 链接文本
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
我怀疑，最大的问题是大多数管理员类型都担心他们不理解的事情。 他们了解 IIS，但整个 ASP.NET 管道都是外国的。 让他们记录下他们的担忧，然后你就可以一一解决它们。
通配符映射存在相当合理的性能问题，但是可以通过将不安全的静态文件推送到另一个虚拟站点（甚至是站点内没有映射的单独映射的虚拟目录）来轻松解决这个问题。
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).
唯一可能的安全问题是攻击面的增加，因为攻击者现在可以攻击 .NET 框架而不仅仅是 IIS。 但这与您在服务器上安装任何侦听应用程序所承担的风险相同。
我认为的误解是他们认为这种绑定将使任何东西都以 .NET 的形式运行，但事实并非如此。 它只是让 .NET 处理它的交付。 只有当它配置为通过 web.config 中的 HttpModule 设置执行时，它才会实际运行除默认绑定之外的任何文件中的代码（在您放入通配符之前它会挂接这些文件）。
性能是一个值得提出的合理问题，但我认为安全影响并不是什么大问题。
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.
潜在的问题是您现在允许在服务器上执行扩展名（例如 .exe）的请求，并且在将请求交给 ISAPI 之前不会被 IIS 过滤掉。
如果 IIS 路径中的任何位置有任何 .exe、bat 或其他可执行文件，则任何用户都可以执行它们。
如果您小心地设置 IIS 网站和虚拟目录，使其不包含任何可能被恶意使用的内容，那么您应该没问题。
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.