我听说有 safety questions over the BinaryFormatter.
我将用户生成的文件从客户端发送到服务器。这些是随后由服务器读取的序列化类。
根据我对上述链接的理解，这很危险。但我试过发送一次性类，甚至尝试过实现 ISerilizable 的类。但由于服务器不知道源代码程序集，两者都被拒绝了。
[Serializable]
public class Ship : ISerializable
{
public Ship()
{
}
public Ship(SerializationInfo info, StreamingContext context)
{
Console.WriteLine("test");
}
public void GetObjectData(SerializationInfo info, StreamingContext context)
{
}
}
那么客户端如何通过这个向量成功地将代码获取到我的服务器中呢？通过伪造命名空间名称和公钥导致服务器尝试反序列化它，从而运行上面的代码？还是有更微妙的方法来做到这一点？
不幸的是，这个功能是我游戏的核心基础，所以我要小心。
最佳答案
我知道这是一个老问题，但我对公认的答案不太满意。
Serialization works on data, not code. [...] It does NOT extract any code from the payload.
没那么简单。 BinaryFormatter使用程序集限定名称来标识类型。在反序列化过程中，这些类型名称由 Type.GetType 解析，它很乐意加载任何程序集。因此，被操纵的流可以加载准备好的程序集，其模块初始化程序会立即执行(但恶意代码也可以放在序列化构造函数或 [OnDeserializing]/[OnDeserialized] 方法中)。 This video演示了如何利用它在浏览器中打开 PowerShell 和网页。
In any case the answers to the original post were mostly speculation, comments on Java serialization that's not really relevant to .NET or really contrived examples.
也许只是因为答案太旧了，但今天有很多已知的BinaryFormatter攻击。一些例子:
-
TempFileCollection可被利用来删除文件(仅在 .NET Framework 中)。链接的视频中也提到了这一点(以及问题中链接的帖子中)。 -
StructurelEqualityComparer可用于导致StackOverflowException或无可救药地缓慢的哈希码计算(DoS 攻击)。从 .NET Core 开始，这种类型不再是可序列化的。 - 很多
[Serializable]不实现ISerializable的类型(因此只需设置字段即可恢复)可以使用无效数据进行初始化。 - 甚至大多数实现
ISerializable的类型不验证传入的SerializationInfo对于所有可能的攻击。例如，Dictionary<TKey, TValue>可以抛出OutOfMemoryException如果HashSize的值输入被操纵。 - 但是
BinaryFormatter在更深层次上也很脆弱。例如，数组是在内部处理的(它甚至不能被代理选择器覆盖)并且操纵的长度信息也可能导致OutOfMemoryException。 .
我其实相信BinaryFormatter可以做到安全。我什至在这里开了一个关于这个话题的问题:https://github.com/dotnet/runtime/issues/50909
但考虑到在实现可序列化类型时，安全性从未成为焦点，而且解决所有这些问题将是一项艰巨的任务，我可以理解 BinaryFormatter将是 obsoleted在未来的版本中。
尽管我介绍了一个 SafeMode my binary serializer 中的选项，只要可序列化类型本身易受攻击，它就不可能完全安全。原生支持多种类型只能减少威胁(这也有利于生成 very compact payload )，但通常无法消除威胁。
结论:只有在同一个进程中执行序列化和反序列化时，二进制序列化才是安全的。在任何其他情况下，您需要实现一些额外的安全措施(例如，通过对流进行加密签名)以确保完全安全。
关于c# - BinaryFormatter反序列化恶意代码？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/20990724/