ASP.NET Core MVC 1.1.0 安全漏洞:拒绝服务风险与修复指南

微软安全公告4010983披露了ASP.NET Core MVC 1.1.0中一个可能导致拒绝服务的安全漏洞。本文详细分析了漏洞影响、受影响的软件,并提供了针对不同项目格式(project.json/csproj)和依赖类型(直接/传递)的逐步修复指南。

ASP.NET Core MVC 1.1.0 中的漏洞可能导致拒绝服务

发布日期: 2017年1月27日 版本: 1.0

执行摘要

微软发布此安全公告旨在提供有关公开版本 ASP.NET Core MVC 1.1.0 中存在的一个漏洞的信息。本公告还指导开发人员如何正确更新其应用程序。 微软已知悉公开版本 ASP.NET Core MVC 1.1.0 中存在一个安全漏洞,其中格式错误的 HTTP 请求可能导致拒绝服务。 ASP.NET Core 是 ASP.NET 的下一代产品,它为 Web 和云场景提供了一个熟悉且现代的框架,运行在 .NET Core 之上。这些产品由 ASP.NET 团队与开源开发人员社区合作积极开发,可运行于 Windows、Mac OS X 和 Linux。当 ASP.NET Core 发布时,版本号重置为 1.0.0,以反映其是独立于其前身 ASP.NET 的新产品。 建议开发人员将所有应用程序更新到使用 1.1.1 或更高版本的包。

缓解因素

仅针对 ASP.NET Core 1.1.0 的应用程序会受到影响。针对 ASP.NET Core 1.0.0、1.0.1 或 1.0.2 的应用程序不受影响。

受影响的软件

如果 Microsoft ASP.NET Core 项目使用以下受影响的包版本,则该漏洞会影响该项目。

扩展表格

受影响的包和版本
包名
Microsoft.AspNetCore.Mvc.Core

公告常见问题解答

如何知道我是否受到影响? ASP.NET Core 有两种不同类型的依赖项:直接依赖和传递依赖。如果你的项目直接或传递依赖于 Microsoft.AspNetCore.Mvc.Core 1.1.0 版本,则会受到影响。

.NET Core 项目格式 .NET Core 有两种不同的项目文件格式,具体取决于创建项目的软件。

  • project.json 是原始格式,包含在 .NET Core 1.0 和 Visual Studio 2015 中。
  • csproj 是 Visual Studio 2017 中使用的格式。

你必须确保遵循适合你项目类型的正确更新说明。

直接依赖 直接依赖是指你明确添加到项目中的依赖项。例如,如果你将 Microsoft.AspNetCore.Mvc 包添加到项目中,那么你就直接依赖于 Microsoft.AspNetCore.Mvc。 通过查看 project.jsoncsproj 文件可以发现直接依赖项。

传递依赖 传递依赖发生在你向项目中添加一个包,而该包又依赖于另一个包时。例如,如果你将 Microsoft.AspNetCore.Mvc 包添加到项目中,它依赖于 Microsoft.AspNetCore.Mvc.Core 包(以及其他包)。你的项目直接依赖于 Microsoft.AspNetCore.Mvc,并传递依赖于 Microsoft.AspNetCore.Mvc.Core 包。 传递依赖可在 Visual Studio 解决方案资源管理器窗口中查看(该窗口支持搜索),或者通过查看 project.json 项目根目录中的 project.lock.json 文件,或 csproj 项目 obj 目录中的 project.assets.json 文件来审核。这些文件是项目使用的所有包的权威列表,包含直接依赖和传递依赖。 任何 ASP.NET Core MVC 1.1 应用程序都将直接或间接依赖于受影响的包。

如何修复受影响的应用程序? 你需要修复直接依赖,并审查和修复任何传递依赖。漏洞包的 1.1.1 版本包含保护应用程序安全所需的修复程序。

修复直接依赖 - project.json/VS2015

1
2
3
4
5
6
7
8
    "dependencies": {
      "Microsoft.NETCore.App": {
        "version": "1.1.0",
        "type": "platform"
      },
      "Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
      "Microsoft.AspNetCore.Mvc.Core": "1.1.0",
    }

此示例有三个直接依赖项:Microsoft.NetCore.App、Microsoft.AspNetCore.Server.Kestrel 和 Microsoft.AspNetCore.Mvc.Core。 Microsoft.NetCore.App 是应用程序的目标平台,你应该忽略此项。其他包将其版本显示在包名称的右侧,在我们的示例中,我们的非平台包版本是 1.1.0。 检查你的直接依赖项中是否存在 Microsoft.AspNetCore.Mvc.Core 1.1.0 版本,在上面的示例中,存在对易受攻击包的直接依赖。 要更新到新包,请将版本号更改为 1.1.1。更新易受攻击的包版本后,保存你的 project.json 文件。

注意:作为修补 ASP.NET Core MVC 的一部分,我们更新了每个 Microsoft.AspNetCore.Mvc.* 包。例如,如果你依赖于 Microsoft.AspNetCore.Mvc,则应将其版本更新到 1.1.1,这也会更新易受攻击的 Microsoft.AspNetCore.Mvc.Core 包。

我们示例 project.json 中的 dependencies 部分现在将如下所示:

1
2
3
4
5
6
7
8
   "dependencies": {
     "Microsoft.NETCore.App": {
       "version": "1.1.0",
       "type": "platform"
     },
     "Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
     "Microsoft.AspNetCore.Mvc.Core": "1.1.1",
   }

如果你使用 Visual Studio 并保存更新后的 project.json 文件,Visual Studio 将恢复新的包版本。你可以通过打开输出窗口 (Ctrl+Alt+O) 并将“显示输出来源”下拉菜单更改为“包管理器”来查看恢复结果。 如果不使用 Visual Studio,请打开命令行并切换到你的项目目录。执行 dotnet restore 命令以恢复你的新依赖项。 处理完所有直接依赖项后,还必须审查传递依赖项。

修复直接依赖 - csproj/VS2017 在你的编辑器中打开 projectname.csproj 文件,或在 Visual Studio 2017 中右键单击项目并从上下文菜单中选择“编辑 projectname.csproj”,其中 projectname 是你的项目名称。查找 PackageReference 节点。下面显示了一个示例项目文件:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
  <Project ToolsVersion="15.0" Sdk="Microsoft.NET.Sdk.Web">
    <PropertyGroup>
      <TargetFramework>netcoreapp1.1</TargetFramework>
    </PropertyGroup>
    <PropertyGroup>
      <PackageTargetFallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</PackageTargetFallback>
    </PropertyGroup>
    <ItemGroup>
      <PackageReference Include="Microsoft.AspNetCore" Version="1.1.0" />
      <PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="1.1.0" />
    </ItemGroup>
    <ItemGroup>
      <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0-msbuild3-final" />
    </ItemGroup>
  </Project>

示例中有两个直接包依赖项,由两个 PackageReference 元素可见。包的名称在 Include 属性中,包版本号在 Version 属性中显示在其名称的右侧。示例显示了两个包:Microsoft.AspNetCore 和 Microsoft.AspNetCore.Mvc.Core,每个包的版本都是 1.1.0。 检查你的 PackageReference 元素中是否存在 Microsoft.AspNetCore.Mvc.Core 1.1.0 版本。 如果存在引用,请将 Version 属性值更改为 1.1.1 来更新到新包。更新易受攻击的包版本后,保存你的 csproj 文件。

注意:作为修补 ASP.NET Core MVC 的一部分,我们更新了每个 Microsoft.AspNetCore.Mvc.* 包。例如,如果你依赖于 Microsoft.AspNetCore.Mvc,则应将其版本更新到 1.1.1,这也会更新易受攻击的 Microsoft.AspNetCore.Mvc.Core 包。

示例 csproj 现在将如下所示:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
    <Project ToolsVersion="15.0" Sdk="Microsoft.NET.Sdk.Web">
      <PropertyGroup>
        <TargetFramework>netcoreapp1.1</TargetFramework>
      </PropertyGroup>
      <PropertyGroup>
        <PackageTargetFallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</PackageTargetFallback>
      </PropertyGroup>
      <ItemGroup>
        <PackageReference Include="Microsoft.AspNetCore" Version="1.1.0" />
        <PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="1.1.1" />
      </ItemGroup>
      <ItemGroup>
        <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0-msbuild3-final" />
      </ItemGroup>
    </Project>

如果你使用 Visual Studio 并保存更新后的 csproj 文件,Visual Studio 将恢复新的包版本。你可以通过打开输出窗口 (Ctrl+Alt+O) 并将“显示输出来源”下拉菜单更改为“包管理器”来查看恢复结果。 如果不使用 Visual Studio,请打开命令行并切换到你的项目目录。执行 dotnet restore 命令以恢复你的新依赖项。 处理完所有直接依赖项后,还必须审查传递依赖项。

审查传递依赖 有两种方法可以查看传递依赖。可以使用 Visual Studio 的解决方案资源管理器,或者通过审查你的 project.lock.json (project.json/VS2015) 或 project.assets.json (csproj/VS2017) 文件。

使用 Visual Studio 解决方案资源管理器 (VS2015) 如果你想使用 Visual Studio 2015,请在 Visual Studio 2015 中打开你的项目,然后按 Ctrl+; 以激活解决方案资源管理器中的搜索。搜索 Microsoft.AspNetCore.Mvc.Core 并记下你找到的任何结果的版本号。 例如,在包含 Microsoft.AspNetCore.Mvc 引用的示例项目中搜索 Microsoft.AspNetCore.Mvc.Core,在 Visual Studio 2015 中显示以下结果:

图 1:在 Visual Studio 2015 中搜索引用

搜索结果显示为树状结构。在这些结果中,你可以看到我们找到了对 Microsoft.AspNetCore.Mvc.Core 版本 1.1.0 的引用,即易受攻击的版本。 “引用”标题下的第一个条目是指你的应用程序使用的目标框架。这将是 .NETCoreApp、.NETStandard 或 .NET-Framework-vX.Y.Z(其中 X.Y.Z 是实际版本号),具体取决于你如何配置应用程序。目标框架下方将是你直接依赖的包列表。在此示例中,应用程序依赖于 Microsoft.AspNetCore.Mvc。Microsoft.AspNetCore.Mvc 又有叶节点列出其依赖项及其版本。在这种情况下,Microsoft.AspNetCore.Mvc 包依赖于易受攻击的 Microsoft.AspNetCore.Mvc.Core 版本和许多其他包。

手动审查 project.lock.json (project.json/VS2015) 在编辑器中打开 project.lock.json 文件。我们建议你使用能够理解 json 并允许你折叠和展开节点来审查此文件的编辑器;Visual Studio 和 Visual Studio Code 都提供此功能。 如果使用 Visual Studio,project.lock.json 文件位于 project.json 文件“下方”。单击 project.json 文件左侧的右指向三角形 ▷ 以展开解决方案树,显示 project.lock.json 文件。图 1 下方显示了一个项目,其中 project.json 文件已展开以显示 project.lock.json 文件。

图 2:project.lock.json 文件位置

project.lock.json 文件中搜索字符串“Microsoft.AspNetCore.Mvc.Core/1.1.0”。如果你的 project.lock.json 文件包含此字符串,则表示你依赖于易受攻击的包。

修复传递依赖 (project.json/VS2015) 如果未找到对 Microsoft.AspNetCore.Mvc.Core/1.1.0 的任何引用,这意味着你的直接依赖项都不依赖于易受攻击的 Microsoft.AspNetCore.Mvc.Core 版本,或者你已通过更新直接依赖项解决了问题。 如果你的传递依赖审查发现对易受攻击的 Microsoft.AspNetCore.Mvc.Core/1.1.0 的引用,则必须向 project.json 文件添加对更新包的直接依赖,以覆盖传递依赖。打开你的 project.json 并找到 dependencies 部分。例如:

1
2
3
4
5
6
7
8
      "dependencies": {
        "Microsoft.NETCore.App": {
          "version": "1.1.0",
          "type": "platform"
        },
        "Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
        "Microsoft.AspNetCore.Mvc": "1.1.0"
      }

我们的传递包搜索结果显示,Microsoft.AspNet.Mvc 依赖于 Microsoft.AspNet.Mvc.Core 1.1.0 版本。要修复此问题,你必须通过将其添加到 project.json 文件中来添加直接依赖。为此,在 dependencies 部分添加一个新行,引用修复后的版本。例如,要引入修复后的 Microsoft.AspNet.Mvc.Core 1.1.1 版本,你编辑 project.json 文件如下:

1
2
3
4
5
6
7
8
9
      "dependencies": {
        "Microsoft.NETCore.App": {
          "version": "1.1.0",
          "type": "platform"
        },
        "Microsoft.AspNetCore.Mvc.Core": "1.1.1",
        "Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
        "Microsoft.AspNetCore.Mvc": "1.1.0"
      }

添加了对已修复包的直接依赖后,保存你的 project.json 文件。 如果你使用 Visual Studio,保存更新后的 project.json 文件,Visual Studio 将恢复新的包版本。你可以通过打开输出窗口 (Ctrl+Alt+O) 并将“显示输出来源”下拉菜单更改为“包管理器”来查看恢复结果。 如果不使用 Visual Studio,请打开命令行并切换到你的项目目录。执行 dotnet restore 命令以恢复你的新依赖项。

使用 Visual Studio 解决方案资源管理器 (VS2017) 如果想使用解决方案资源管理器,请在 Visual Studio 2017 中打开你的项目,然后按 Ctrl+; 以激活解决方案资源管理器中的搜索。搜索 Microsoft.AspNetCore.Mvc.Core 并记下你找到的任何结果的版本号。 例如,在包含依赖于 Microsoft.AspNetCore.Mvc 的包的示例项目中搜索 Microsoft.AspNetCore.Mvc.Core,在 Visual Studio 2017 中显示以下结果:

图 3:在 Visual Studio 2017 中搜索引用

搜索结果显示为树状结构。在这些结果中,你可以看到我们找到了对 Microsoft.AspNetCore.Mvc.Core 版本 1.1.0 的引用。 “依赖项”节点下将有一个 NuGet 节点。NuGet 节点下方将是你直接依赖的包及其版本的列表。在此示例中,应用程序直接依赖于 Microsoft.AspNetCore.Mvc。Microsoft.AspNetCore.Mvc 又有叶节点列出其依赖项及其版本。在示例中,Microsoft.AspNetCore.Mvc 包依赖于 Microsoft.AspNetCore.Mvc.ApiExplorer 的一个版本,而该版本又依赖于易受攻击的 Microsoft.AspNetCore.Mvc.Core 版本。你可以看到其他包也依赖于易受攻击的 Microsoft.AspNetCore.Mvc.Core 版本。

手动审查 project.assets.json (VS2017) 从项目 obj 目录在编辑器中打开 project.assets.json 文件。我们建议你使用能够理解 json 并允许你折叠和展开节点来审查此文件的编辑器;Visual Studio 和 Visual Studio Code 都提供此功能。 在 project.assets.json 文件中搜索字符串“Microsoft.AspNetCore.Mvc.Core/1.1.0”。如果你的 project.assets.json 文件包含此字符串,则表示你依赖于易受攻击的包。

修复传递依赖 (csproj/VS2017) 如果未找到对 Microsoft.AspNetCore.Mvc.Core/1.1.0 的任何引用,这意味着你的直接依赖项都不依赖于易受攻击的 Microsoft.AspNetCore.Mvc.Core 版本,或者你已通过更新直接依赖项解决了问题。 如果你的传递依赖审查发现对易受攻击的 Microsoft.AspNetCore.Mvc.Core/1.1.0 的引用,则必须向 csproj 文件添加对更新包的直接依赖,以覆盖传递依赖。在你的编辑器中打开 projectname.csproj 文件,或在 Visual Studio 2017 中右键单击项目并从上下文菜单中选择“编辑 projectname.csproj”,其中 projectname 是你的项目名称。查找 PackageReference 节点,例如:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
    <Project ToolsVersion="15.0" Sdk="Microsoft.NET.Sdk.Web">
      <PropertyGroup>
        <TargetFramework>netcoreapp1.1</TargetFramework>
      </PropertyGroup>
      <PropertyGroup>
        <PackageTargetFallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</PackageTargetFallback>
      </PropertyGroup>
      <ItemGroup>
        <PackageReference Include="Microsoft.AspNetCore" Version="1.1.0" />
        <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.0" />
        <PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="1.1.0" />
      </ItemGroup>
      <ItemGroup>
        <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0-msbuild3-final" />
      </ItemGroup>
    </Project>

在上面的示例 csproj 文件中,有 3 个 PackageReference 节点。我们的传递包搜索结果显示,我们的应用程序依赖于易受攻击的 Microsoft.AspNet.Mvc.Core 1.1.0 版本。要修复此问题,你必须通过将其添加到 csproj 文件中来添加新的直接依赖。为此,在 PackageReference 列表顶部添加一个新的 PackageReference,引用修复后的版本。例如,要在示例 csproj 文件中引入修复后的 Microsoft.AspNet.Mvc.Core 1.1.1 版本,将其更改为:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
    <Project ToolsVersion="15.0" Sdk="Microsoft.NET.Sdk.Web">
      <PropertyGroup>
        <TargetFramework>netcoreapp1.1</TargetFramework>
      </PropertyGroup>
      <PropertyGroup>
        <PackageTargetFallback>$(PackageTargetFallback);portable-net45+win8+wp8+wpa81;</PackageTargetFallback>
      </PropertyGroup>
      <ItemGroup>
        <PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="1.1.1" />
        <PackageReference Include="Microsoft.AspNetCore" Version="1.1.0" />
        <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.0" />
        <PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="1.1.0" />
      </ItemGroup>
      <ItemGroup>
        <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0-msbuild3-final" />
      </ItemGroup>
    </Project>

添加直接依赖引用后,保存你的 csproj 文件。 如果你使用 Visual Studio,保存更新后的 csproj 文件,Visual Studio 将恢复新的包版本。你可以通过打开输出窗口 (Ctrl+Alt+O) 并将“显示输出来源”下拉菜单更改为“包管理器”来查看恢复结果。 如果不使用 Visual Studio,请打开命令行并切换到你的项目目录。执行 dotnet restore 命令以恢复你的新依赖项。

重新构建你的应用程序 最后,重新构建你的应用程序,像平常一样进行测试,并使用你喜欢的部署机制重新部署。

其他信息

支持

报告安全问题

  • 如果你在 .NET Core 中发现了潜在的安全问题,请将详细信息通过电子邮件发送至 . 报告可能有资格获得 .NET Core 漏洞赏金。.NET Core 漏洞赏金的详细信息(包括条款和条件)位于 https:。

Microsoft 主动保护计划 (MAPP) 为了改善客户的安全保护,微软在每月安全更新发布之前向主要安全软件提供商提供漏洞信息。然后,安全软件提供商可以使用此漏洞信息通过其安全软件或设备(例如防病毒软件、基于网络的入侵检测系统或基于主机的入侵防御系统)向客户提供更新的保护。要确定安全软件提供商是否提供主动保护,请访问计划合作伙伴列出的主动保护网站,这些网站列在 Microsoft 主动保护计划 (MAPP) 合作伙伴中。

反馈

  • 你可以通过填写 Microsoft 帮助和支持表、客户服务联系我们来提供反馈。

支持

  • 你可以在 GitHub 上的 Identity Model Extensions 仓库中询问有关此公告的问题。
  • 美国和加拿大的客户可以从安全支持处获得技术支持。有关更多信息,请参阅 Microsoft 帮助和支持。
  • 国际客户可以从当地的 Microsoft 子公司获得支持。有关更多信息,请参阅国际支持。
  • Microsoft TechNet 安全提供了有关 Microsoft 产品中安全性的更多信息。

免责声明 本公告中提供的信息“按原样”提供,不作任何担保。微软不作任何明示或暗示的担保,包括适销性和特定用途适用性的担保。在任何情况下,微软公司或其供应商都不承担任何损害赔偿责任,包括直接、间接、附带、后果性、业务利润损失或特殊损害,即使微软公司或其供应商已被告知可能发生此类损害。有些州不允许排除或限制附带或后果性损害的责任,因此上述限制可能不适用。

修订版本

  • V1.0(2017年1月27日):公告发布。

页面生成于 2017-01-27 7:57Z-08:00。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计