没有强命名的代码签名是否会让您的应用程序被滥用？

Question

试图了解authenticode代码签名和强命名.

我是否正确地认为,如果我对引用一些dll(不是强名称)的exe进行代码签名,恶意用户可以替换我的DLL并以一种看起来像是由我签名但正在运行的方式分发应用程序他们的代码？

假设这是真的,看起来你真的不想在没有强烈命名整个事情的情况下签署.NET应用程序,否则你会让人们能够在你编写的应用程序的幌子下执行代码？

我不确定的原因是,我在网上找到的文章(包括使用SN + Authenticode的MSDN文档)似乎都没有提到这一点,这似乎是一个相当重要的理解点(如果我理解正确) ？

Answer 1

我是否正确地认为,如果我对引用一些dll(不是强名称)的exe进行代码签名,恶意用户可以替换我的DLL并以一种看起来像是由我签名但正在运行的方式分发应用程序他们的代码？

是的,如果其余的DLL只是签名而不是强名称,则可以在不引发异常的情况下替换它们.您可以在exe内部验证DLL是否由与exe相同的密钥签名.这些方法都不能阻止某人替换您的DLL或EXE.

假设这是真的,看起来你真的不想在没有强烈命名整个事情的情况下签署.NET应用程序,否则你会让人们能够在你编写的应用程序的幌子下执行代码？

一般来说,我认为这是"最佳实践",但你再次没有阻止任何事情.一旦用户有权更改本地系统上的文件,您就无法阻止他们进行恶意活动.

有几种混淆技术可以将完整的.NET项目构建到单个exe中,这可能会成为"最安全"的方法,但仍然可以被篡改.

真正的问题是你想阻止他们做什么？我的意思是说,为什么有人会有兴趣更换你的dll？他们希望实现什么,他们的目标是什么？如果你试图阻止某人从你进入的过程中读取敏感信息,那就是一段漫长的艰难道路.假设恶意方可以完全访问您的源代码以及您的进程使用的每条信息,因为它们可以访问.假设他们可以随意替换全部或部分代码,因为他们可以.

更新

因此,绑定重定向仅适用于使用相同键进行强名称的程序集,因此可以保护您免受更改的DLL的影响吗？

正确,除了注意到的例外,代码注入仍然可以通过多种方式完成.

...回到原来的问题,没有强命名的代码签名有点破坏了代码签名的意义吗？

并不是的.代码签名(不强命名)有两个不同的目的:

1. 验证.验证软件作者是谁.
2. 诚信.验证软件自签名后未被篡改.

通常,这仅在安装期间进行身份验证和验证.这就是我们签署setup.exe的原因,以确保客户已收到我们未经修改的安装程序.系统会提示"您信任XXXX公司",从而授权经过身份验证/签名的安装程序.一旦安装,操作系统几乎没有内置的代码签名使用(除了驱动程序和其他一些模糊的情况).

另一方的强命名与它的存在有着完全不同的目的.它完全专注于应用程序的"完整性".没有证书,没有签名机构(CA)来验证它,没有用户显示的信息供他们确认,操作系统也无法验证它将要运行的可执行文件.

.NET框架对很多东西使用强名称,所有这些我都松散地归类为应用程序完整性:

1. dll/exe的内容具有签名哈希,因此不会被篡改.
2. 加载依赖项时,每个引用都必须强名称和验证.
3. 可以在GAC中注册程序集,也可以使用发布者策略.
4. 可以生成本机图像以生成程序集IL的编译图像.

我确信这里还有其他一些我不知道的东西,但这些是我所知道的主要用途.

签名和强命名的最佳实践

• 使用已签名的安装程序
• 使用代码签名的可执行文件
• 使用强名称的可执行文件
• 强名称所有依赖项和对它们的引用
• 通常不需要代码签名依赖项*
• 考虑GAC在安装时注册程序集

*注意:代码签名在某些情况下对于DLL很有用,例如标记为"安全"并嵌入浏览器的COM对象应该签名并强名称,就像它是可执行文件一样.代码签名在外部验证依赖关系时也很有用,无需加载程序集或反映它的属性.