在查看一位同事的库时，我看到了他描述的使用新StatusController的两种方法。重写GetStatus方法以返回更具体的数据，或者简单地让默认实现工作。好吧，所以我做了覆盖，因为我还不确定他对后者的意思，它是有效的。另一位同事问我是否看过后者，我回答
"好吧，不，因为如果我只是引用项目/nuget，而不以某种方式告诉框架它是不起作用的">
"我们试试吧"；
"好吧，但如果它有效的话，我会大吃一惊的；。
我现在踉踉跄跄。
然后我继续尝试间接引用，它仍然有效。我故意不显示任何代码，因为它只是Visual Studio MVC web应用程序或web API中的锅炉板控制器代码，你可以在几分钟内完成。但让我给你举个例子。
假设我正在为www.electionmission.gov.us编写一个应用程序，我想对特定的文件格式进行一些特殊的字符串解析，有一个nuget包可以帮助我，让我们称之为VotingMachineFormatParser，但我不知道它使用了一个名为Tviker(俄语中Tweaker的意思)的包，不知道为什么，但他们发现它很有用。Tviker内部有一个控制器类，名为GosudarsvennnoyeVmeshateStvoController，它做的事情，意思是状态干扰。
如果您现在访问www.electioncommission.gov.us/gosudarstvennnoyefmeshatelstvo，了解某些代码正在运行，正在执行任何操作。
我认为您应该使用应用程序部件的概念来从另一个程序集中引入控制器。求你了，我错过了什么？这肯定不是我想的那个洞吧？
编辑：我没有包含任何代码，因为这就是重点，您不需要任何代码。我忘了说这是一种行为；新的"；到.Net Core 3.1+它以前不是这样工作的。从另一个程序集引入控制器的唯一方法是通过ApplicationParts。
测试这一点很容易，只需重命名两个锅炉板类即可。
让VStudio在.Net Core 5中创建一个锅炉板WebAPI，并选中OpenAPI复选框。在两个单独的文件夹中执行此操作，但其中一个文件夹将WeatherForecastController重命名为ToldYouController，并将WeatherForecast类重命名(通过重构)为WeatherForecast 1。
在第一个项目中使用ToldYouController引用该项目，运行后，你会在Swagger中看到两个控制器，而你只做了引用就实现了这一点！你可以通过间接引用来尝试，它也会起到同样的作用。
.NETCore3.x对引用MVC的程序集具有自动应用程序部件注册功能。
来自Andrew Locks博客：
请注意，在ASP.NET Core 3.x中，当编译引用ASP.NET Core时，会向输出中添加程序集属性，[ApplicationPart]。ASP.NET Core 3.x应用程序在上查找此属性引用程序集并将其注册为应用程序部件自动地
关于ASP.NET Core documentation:上的ApplicationPartAttribute
指定要添加为ApplicationPart的程序集。
在普通情况下，MVC将生成ApplicationPartAttribute引用的每个依赖项的条目程序集上的实例MVC。这些程序集中的每一个都被视为ApplicationPart。
由于GosudarstvennoyeVmeshatelStvoController是Controller，其程序集将引用MVC，因此将注册为应用程序部件。
我向微软安全中心提出了这个问题，并通过电子邮件进行了以下简短讨论；太长，读不下去了它是(如@pfx先前所评论的)"；通过设计"；但他们承认我有道理(即有问题)！
2021年1月5日星期二00:08，微软安全响应中心<secure@microsoft.commailto：secure@microsoft.com>写道：你好，威廉，
再次感谢您的报告。我们的团队已经完成了审查，我们已经确定这是.NET Core在扫描或加载程序集时的预期行为。根据.NET团队："自动扫描程序集是MVC的一项功能，我们提供框架功能，如Identity.UI和其他依赖它的Razor类库
如果一个无害的nuget包碰巧引用了另一个包含坏的actor控制器的包，并且一个应用程序利用了无害包中可用的好选项，那么他们就不知道已经将坏的actoer控制器合并到了他们的应用程序中。
我们有一个小文档部分，讨论如何配置MVC可以在其中查找资源的程序集-与ASP.NET Core中的应用程序部件共享控制器、视图、Razor Pages等|Microsoft Docshttps://learn.microsoft.com/en-us/aspnet/core/mvc/advanced/app-parts?view%3Daspnetcore-5.0%23防止加载资源&data=04%7c01%7csecure%40microsoft.com%7cf99261c9a0684480189008d8b161250b%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c637454378085369085%7cTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCVCIJX6Mn0%3D%7c1000&sdata=BPxm68OOP6M7mzZUS9qMtYQnhvWabq1CMpSP7sfWLc4%3D&保留=0.
除此之外，建议您清楚地理解引用NuGet包或应用程序中任何其他外部依赖项的含义。当应用程序引用有害的包时，MVC发现额外的控制器可能不是唯一的问题">
再次感谢您给我们机会回顾您的调查结果。我们将结案，但我鼓励将任何未来的调查结果发送给我们。。。
谨致问候，丹尼尔MSRC
发件人：William Hopkins接收时间：2021年1月5日星期二02:03:28 GMT-0800(太平洋标准时间)收件人：；Microsoft安全响应中心；微软安全响应中心主题：回复：MSRC案例62669 CRM:0279001377
感谢您的回复Daniel，
我必须说这是一个令人失望的立场。.Net Core 3中引入的行为颠覆了不知名控制器的加入，并没有对其后果进行真正的宣传。是的，我明白这会让生活变得更轻松；冷却器"；对于一些新的框架特征，但即使对于那些；搜索""；包含"；可以通过初始化调用打开。拥有一段非常短且未公开的文档，即使在那时似乎也需要明确知道要排除哪些程序集，这确实让安全性回到了前台。
是的，我确实理解包括NuGet包也会引入其他风险，但对于一个糟糕的参与者来说，最大的问题是让调用发生。这种行为——即使是(非常糟糕的)设计——也会让事情变得微不足道。再加上我的许多同事直到我向他们展示我给你们举的同样的例子才发现问题，这意味着我相信这是一颗滴答作响的定时炸弹。为了能够使用任何不重要的主流软件包，现在需要付出大量的额外努力，这意味着今后我必须强烈建议我的客户不要使用NuGet系统。我担心这可能会导致人们对NuGet套餐的信心最终破灭。
所有这些都是为了让它在默认情况下变得不安全，而不是通过行动变得不安全。
问候，
Will Hopkins
Microsoft安全响应中心
附件1月5日星期二22:02(16小时前)
到Microsoft，我你好Will，
感谢您对此提供一些反馈。我和团队分享了这一点，他们同意你有一些公平的观点，因为我们已经将这个案例作为一个设计问题结束了，他们对这成为一个公开讨论没有问题。如果你愿意，你可以在GitHub repo上发布你的担忧，团队成员很乐意继续在那里讨论你的担忧。再次感谢您的报告，以提高我们产品的安全性！
谨致问候，丹尼尔MSRC