没有强命名的代码签名是否会让您的应用程序容易被滥用？
尝试了解authenticode代码签名和强命名。
我是否正确地认为，如果我对引用一些 dll（非强命名）的 exe 进行代码签名，则恶意用户可以替换我的 DLL 并以看似由我签名但正在运行的方式分发应用程序他们的代码？
假设这是真的，那么您似乎并不想在不对整个应用程序进行强命名的情况下签署 .NET 应用程序，否则您将让人们能够在您编写的应用程序的幌子下执行代码？
我不确定的原因是，我在网上找到的所有文章（包括关于使用 SN+Authenticode 的 MSDN 文档）似乎都没有提到这一点，而且这似乎是一个相当重要的理解点（如果我理解正确的话） ？
Trying to get my head around authenticode code-signing and strong-naming.
Am I right in thinking that if I code-sign an exe that references a few dlls (not strong named) that a malicious user could replace my DLLs and distribute the app in a way that appears as if it's signed by me, but is running their code?
Assuming that's true, it seems like you wouldn't really want to sign a .NET app without strong-naming the whole thing, otherwise you're giving people the ability to execute code under the guise of an app you wrote?
The reason I'm unsure, is that none of the articles I found online (including the MSDN doc about using SN+Authenticode) seem to mention this, and it seems like a fairly important point to understand (if I've understood correctly)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
是的，如果其余 DLL 仅经过签名且未强命名，则可以替换它们，而 .NET 不会引发异常。您可以在 exe 内部验证 DLL 是否由与 exe 相同的密钥进行签名。这些方法都无法阻止他人替换您的 DLL 或 EXE。
一般来说，我认为这是“最佳实践”，但你又没有阻止任何事情。一旦用户有权更改本地系统上的文件，您就无法阻止他们进行恶意活动。
有多种混淆技术可以将完整的 .NET 项目构建到单个 exe 中，这可能是“最安全”的方法，但仍然可能被篡改。
真正的问题是你想阻止他们做什么？我的意思是，为什么有人有兴趣替换你的 dll？他们希望实现什么，他们的目标是什么？如果您试图阻止某人读取流程中的敏感信息，那么您将陷入漫长而艰难的失望之路。假设恶意方可以完全访问您的源代码以及您的进程使用的每条信息，因为他们确实如此。假设他们可以随意替换你的全部或部分代码，因为他们可以。
已更新
正确，但值得注意的是，代码注入仍然可以通过多种方式完成。
并不真地。代码签名（不是强命名）有两个不同的目的：
通常，这仅在安装期间进行身份验证和验证。这就是我们对 setup.exe 进行签名的原因，以确保客户收到我们发送的未经修改的安装程序。他们会收到“您信任 XXXX 公司吗”的提示，从而向经过身份验证/签名的安装程序授予授权。然而，一旦安装，操作系统就很少内置使用代码签名（驱动程序和其他一些模糊的情况除外）。
另一方面，强命名的存在有着完全不同的目的。它完全专注于应用程序的“完整性”。没有证书，没有签名机构（CA）来验证它，没有用户显示的信息供他们确认，操作系统也无法验证它将要运行的可执行文件。
.NET 框架对许多事物使用强名称，我将所有这些事物松散地归类为应用程序完整性：
我确信我还缺少其他东西，但这些是我知道的主要用途。
签名和强命名的最佳实践
*注意：代码签名在某些情况下对于 DLL 很有用，例如标记为“安全”并嵌入到浏览器中的 COM 对象应进行签名和强命名，就好像它是可执行文件一样。代码签名还可用于外部验证依赖项，而无需加载程序集或反映其属性。
Yes if the remainder of the DLLs are only signed and not strong named they can be replaced without .NET raising an exception. You could, inside the exe, verify the DLLs are signed by the same key as the exe. None of these approaches prevent someone from replacing your DLLs or the EXE.
Generally I suppose that is the 'best practice', but again you have not prevented anything. Once a user has the rights to change files on the local system there is not much you can do to stop them from malicious activity.
There are several obfuscation technologies that build complete .NET projects into a single exe, this might make the 'most secure' approach but still can tampered with.
The real question is what are you trying to prevent them from doing? I mean to say, why would someone be interested in replacing your dll? What would they hope to achieve, what is their goal? If you're trying to prevent someone from reading sensitive information from the process you in for a long hard road of disappointment. Assume a malicious party has complete access to your source code and every piece of information used by your process, because they do. Assume they can replace all or part of your code at will, because they can.
Updated
Correct, with the noted exception that code injection can still be done in numerous ways.
Not really. Code signing (not strong naming) has two distinct purposes:
Often this is only authenticated and validated during installation. This is why we sign our setup.exe, to ensure that the customer has received the unmodified installer from us. They are prompted with the "Do you trust XXXX Company" and are thereby granting authorization to the authenticated/signed installer. Once installed however there is little built-in use of code signing by the OS (except for drivers and some other obscure cases).
Strong Naming on the other had has a completely different purpose for it's existence. It's entirely focused on 'integrity' of the application. There is no certificate, no signing authority (CA) to verify it against, no user-displayed information for them to confirm, and nothing the OS can verify about the executable it's going to run.
The .NET framework uses strong names for many things, all of them I loosely categorize as application integrity:
I'm sure there are other things I'm missing here, but these are primary uses I'm aware of.
Best practices for Signing and Strong-naming
*Note: Code signing can be useful in some cases for a DLL, for example COM objects marked 'safe' and embedded into a browser should be signed and strong-named as if it were an executable. Code signing can also be useful in externally verifying dependencies without loading the assembly or reflecting it's attributes.
一旦有人可以替换 dll 或在您的计算机上运行代码，您就没有那么多保护措施了。就我而言，所有 Dll 都是单独进行代码签名的。我的代码拒绝下载未作为自我更新一部分进行签名的 Dll。然而，在我的系统上以我的完整性级别或更高级别运行的任何应用程序（在> = Vista Windows的情况下）仍然可以使用诸如CreateRemoteThread等之类的东西将dll注入到我的exe中（http://www.codeguru.com/Cpp/ WP/dll/article.php/c105)
但再次假设有人可以将外部代码输入系统是困难的部分。剩下的就很容易了。
Once someone can replace dll's or run code on your machine there arent that many safeguards left to you. In my case all the Dll's are code signed individually. My code refuses to download Dll's that are not signed as part of the self update. However any app running at my integrity level or higher on my system (In the case of >= Vista Windows) can still inject a dll into my exe with something like CreateRemoteThread etc (http://www.codeguru.com/Cpp/W-P/dll/article.php/c105)
But again assuming someone can get foreign code into the system is the hard part. The rest is easy.
您还必须记住，在升级 dll 而不部署应用程序的其他部分时，代码签名通常会带来很多麻烦。
这就是为什么许多流行的库没有对 dll 进行强命名
you must also remember that Code Signing often introduces lots of pain when upgrading dll's without deploying other parts of the application.
This is why many popular libraries do not strongly name the dll's
在搜索相同内容并阅读很多内容之后。我终于可以回答你的问题了，是的，如果你要对你的应用程序exe进行数字签名，依赖项的强名称是必须的。
如果您的依赖项没有强名称，请假设这一点。他们被替换了。您的应用程序将毫无问题地加载它们。用户将看到对话框“已验证的发布者：您的名字”。虽然可执行文件未受影响，但依赖项已更改。
问题不在于该用户，而在于该软件包的分发具有改变的依赖关系，而每个人都会在上面看到您的名字。
After being searching for same and reading many stuff. I finally can say to your question, YES, strong name for dependencies is must if you are going to digitally signing your app exe.
Assume this, if your dependencies don't have strong name. And they get replaced. Your application will load them without any problem. And user will see dialog "Verified Publisher : Your Name". While executable was untouched but dependencies got altered.
Problem is not that user but distribution of that package with altered dependencies while everyone will see your name on it.