ASP.NET MVC 应用程序的性能和安全性 - 处理程序映射和模块答案

【问题标题】：Performance and security of ASP.NET MVC app - handler mappings and modulesASP.NET MVC 应用程序的性能和安全性 - 处理程序映射和模块
【发布时间】：2011-12-24 07:58:27
【问题描述】：

我刚刚读了一篇有趣的文章。基本上它说，您应该通过 2 种方式微调每个应用程序的 IIS 设置：

处理程序映射 - 删除所有未使用的应用程序
模块 - 删除所有未使用的应用程序

好吧，我开发 ASP.NET 已经有一段时间了，即使是在工作中，我们从来没有在生产环境 afaik 上这样做过。我理解所提出的理论优势 - 最大限度地减少应用程序的“表面”（安全性），并提高性能。但是我真的很好奇，如果您在现实生活中这样做（为您的客户提供的实际项目，而不是概念验证项目）。这有什么缺点（可能是可维护性？）。最重要的问题——值得吗？例如，性能提升是否可见？

此外，如果您认为这是一个很好的做法，请提供一些良好且一致的方法（或指向我的教程），您如何准确地执行此过程 - 您如何决定保留哪些内容以及删除哪些内容。

例如，什么是 ASP.NET MVC 3 应用程序的最小但工作集，它使用自定义身份验证（基于会话，不依赖于 Forms 身份验证、Windows 身份验证等），没有 Web 服务和类似功能？

编辑

我找到了这篇文章：http://madskristensen.net/post/Remove-default-HTTP-modules-in-ASPNET.aspx

其中，斯科特·格思里说：

一般来说，使用这种方法可以获得一些非常小的性能提升——尽管我可能不建议这样做。原因是 ASP.NET 的某些功能（表单身份验证、角色、缓存等）当然会在您删除它们所依赖的模块后停止工作。试图弄清楚为什么会发生这种情况通常会令人困惑。

但仍然没有测量和实践（我不太相信“你以后会感到惊讶”的说法:)

【问题讨论】：

什么是“有趣的文章”，因为您只提到了一个指向 Mads K 博客的链接，其中包含 Scottgu 的回复。他还说“非常小的”性能改进，但有趣的问题。想知道 Stackoverflow 是否这样做...
推荐阅读：c2.com/cgi/wiki?PrematureOptimization

标签： asp.net asp.net-mvc web-config iis-7.5

【解决方案1】：

<modules runAllManagedModulesForAllRequests="false">
  <!-- disable authorization section -->
  <remove name="UrlAuthorization" />
  <!-- disable unused authentication schemes -->
  <remove name="WindowsAuthentication" />
  <remove name="PassportAuthentication" />
  <!-- disable ACL file and directory check -->
  <!-- <remove name="FileAuthorization" /> -->
  <!-- We don't use ASP.NET Profiles -->
  <remove name="Profile" />
  <!-- We don't provide any WCF service -->
  <remove name="ServiceModel" />
  <!-- Remove modules not used by ASP.NET MVC + jQuery -->
  <remove name="ScriptModule-4.0" />
</modules>

【讨论】：

【解决方案2】：

对于它的价值，Security Best Practices for IIS 8 有这个：

只安装您需要的 IIS 模块。

IIS 8 由 40 多个模块组成，允许您添加所需的模块并删除不需要的任何模块。如果你只安装您需要的模块，可以减少暴露于潜在攻击的表面积。

定期删除未使用或不需要的模块和处理程序。

查找您不再使用的模块和处理程序并删除它们来自您的 IIS 安装。努力保持您的 IIS 表面面积尽可能小。

IIS Modules Overview 还具有 IIS 模块引用，其中每个模块都有一个名为“删除此模块时的潜在问题”部分。例如，如果 DefaultAuthentication 模块被移除：

如果 ASP.NET 身份验证模式为表单，则某些 ASP.NET 功能可能不适用于匿名请求。此外，不会引发 DefaultAuthentication.OnAuthenticate 事件。

【讨论】：

【解决方案3】：

这并不能直接回答您的问题，但在回答 another question on SO 时，我刚刚发现了 URL Rewrite module turned on 对 MVC 的性能影响。

当执行 URL 生成时（例如通过类似的方法 Html.ActionLink) 在某些情况下 MVC 检查当前是否请求的 URL 已被 URL 重写模块重写。如果是这样处理结果以使其正确匹配 URL 的情况客户要求的。检查 URL 是否已被访问的行为重写具有不小的成本（因为它涉及检查服务器变量）。 ASP.NET MVC 3 检查 URL 重写是否关闭并且可以缓存该事实，从而避免检查服务器的需要每个请求的变量。如果打开 URL Rewrite，MVC 将有即使没有发生重写，也要检查服务器变量特定请求，因此如果您不使用 URL Rewrite，您应该转关掉。

因此，即使您不使用模块，它也会对您的应用程序产生影响。

但是，我认为除非您对特定模块或处理程序有安全问题，我必须同意 Scott Gu 的意见，否则您可能不会注意到（除非您每天处理约 100 万个请求或其他东西）并且花时间调整缓存（数据库和内容）配置文件会更好。

哦，所以我有点回答你的问题，不，我们不这样做。

【讨论】：

这不是对我的问题的完全“规范”答案，所以我不将其标记为答案，但是我认为此响应对成本高昂的模块使用的非明显示例最有帮助，因此我授予给你的（结束）赏金

【解决方案4】：

从性能的角度来看，这是一个很好的最佳实践。但是，通常还有其他因素需要考虑。

大多数应用程序会随着时间的推移而扩展。如果您现在不使用某个功能，那么您将来可能会使用它。当您这样做时，我可以想象有人忘记重新配置 IIS 设置，导致您的生产环境停机时间更长。
生产环境通常不在开发人员手中。

一个。这些人可能有足够的想法来应用微不足道的性能调整。

b.发布手册越短越好。为性能调整添加不必要的（在这种情况下是微不足道的）步骤可能会导致检查步骤。

同样，从性能的角度来看，这是一个很好的最佳实践。根据我的经验，大多数应用程序不需要这些性能调整。因此，缺点大于优点。但是，正如 Tommy 所说，如果您的应用程序每天处理数百万个请求，那么每一点都会有所帮助。

【讨论】：

【解决方案5】：

首先，老实说，我并没有这样做，只是有一次（下面会详细介绍）。

您必须考虑，从安全的角度来看，这是不费吹灰之力的。如果您知道自己没有使用一组功能，为什么还要继续公开它们？

现在让我们回到 2010 年 9 月。有一个严重的漏洞：asp.net padding oracle。我有几篇博文，一篇在asp.net padding oracle: impact on asp.net MVC and PHP

请注意，即使没有积极使用 asp.net，这也会如何影响 PHP。

所以问题出在 asp.net MVC 中通常不使用的处理程序上。事实上，在我当时正在处理的一些客户端服务器/应用程序上，我们禁用了有问题的处理程序。在 MS 推出解决方案之前，漏洞已关闭；应用程序没有受到影响，因为我们没有使用任何处理程序。

权衡的是，并非所有处理程序都这么简单。肯定很难知道某些应用程序中使用了哪些处理程序。另一方面，很高兴知道您正在使用的 asp.net 部分发生了什么。

【讨论】：