为什么.NET框架（V2.0）会试图混淆Internet Explorer注册表？

Question

我们的一个应用程序最近安装在严格锁定的系统中。

启动时，应用程序尝试修改HKCU \ Software \ Microsoft \ Windows \ CurrentVersion \ Internet Settings \ ZoneMap \ AutoDetect中的注册表。在源代码中没有对该位置的已知引用。实际上，有问题的应用程序不应该对注册表进行任何修改。

任何人都可以提出什么可能会导致它（或.NET框架）以这种方式访问​​注册表的应用程序错误？

Answer 1

看来问题不是由我们的软件造成的，或者至少不是直接造成的。我仍然不知道IT部门在机器上发生了什么变化，但是这个问题神秘地消失了，没有修改我们的应用程序（或者至少没有任何与解决问题相关的尝试）。迄今为止，只有那台机器受到了这个问题的影响，所以我猜测这是一个非常具体的交互问题......尽管我根本就不了解根本原因。

Answer 2

这个特别的关键与你的计算机上的安全设置，而不仅仅是IE。操作系统的其他部分使用区域设置来确定授予可执行文件的权限。 .Net框架做了很多我们不知道的内容，包括确定适当的权限。

我很想知道如何安装您的应用程序。 （即ClickOnce，还是从网络上的网址或共享驱动器下载的？）

它可能是它来自潜在的“不可信”位置，就像我刚刚提到的位置，运行时间是试图授予它需要运行的权限。

当然，还有一些明显的问题，比如应用程序做任何网络访问（Web服务调用，Internet访问，访问网络上的其他机器，连接到集中的数据库服务器，从任何以上等）

Answer 3

你确定它试图写入该密钥或只是访问和阅读它？应用程序Authenticode是否有可能被签名？如果是这样，那么你应该知道CLR将总是试图验证Authenticode签名的二进制文件，这意味着它可能触及网络以获取证书撤销列表。看看.NET Security Blog上的帖子。相关摘录：

---

大会负荷性能
当CLR加载具有验证码签名的组件，它总是试图验证签名。这与Windows加载程序相反，它只会在特定情况下验证文件的签名，例如文件是否为ActiveX控件。此验证可能需要相当多的时间，因为它可能需要多次点击网络来下载最新的证书吊销列表，并且还要确保在到受信任根的路上有完整的有效证书链。所以，当一个Authenticode签名被应用到程序集时，在加载该程序集时看到几秒的延迟并不是闻所未闻。