AlbumenJ commented on issue #13518: URL: https://github.com/apache/dubbo/issues/13518#issuecomment-1865381128
> > 我先说个前提的问题吧：我只是单纯的从业务方使用的感受我返回值类型是父类实际返回是子类，这个业务逻辑是应该没问题不应该报错的，我实际自己手动用fastjson也是不报错的，那就是dubbo在集成fastjson的时候使用的配置方面比较严格或者别的导致这个问题。所以还是要dubbo侧来解决这个问题 > > 不太了解序列化这里的安全检查的设计, 单纯从使用来看的话,如果开发一个rpc接口,涉及对象类型及其子类,还要手动单独维护到一个允许列表的话,毫无疑问增加了成本 > > 且默认设置了最高级别 https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/advanced-features-and-usage/security/class-check/ > > ``` > 检查模式 > 检查模式分为三个级别：STRICT 严格检查，WARN 告警，DISABLE 禁用。 STRICT 严格检查：禁止反序列化所有不在允许序列化列表（白名单）中的类。 WARN 告警：仅禁止序列化所有在不允许序列化列表中（黑名单）的类，同时在反序列化不在允许序列化列表（白名单）中类的时候通过日志进行告警。 DISABLE 禁用：不进行任何检查。 > > 3.1 版本中默认为 WARN 告警级别，3.2 版本中默认为 STRICT 严格检查级别。 > ``` 这个是从安全角度出发的，如果序列化侧不做严格限制出现 RCE（远程命令执行，也就是常见的弹计算器）。在 Java 生态中，有非常多的类可以执行 `Runtime.exec`，3.1.x 及以前的版本做的是黑名单的限制的，但是黑名单逻辑永远限制不完，攻击者总是能找到新的类去执行，所以 3.2.x 才开启了强白名单。 BTW，设想一种场景，如果 interface 上写的是 Object、List、Map 这种超大的接口，如果允许子类任意传递，那理论上这个可以序列化的范围会被无限扩大，导致安全风险的扩大。 没有人期望一个 Java 程序跑着跑着 Server 被人拿到 SSH 权限的 :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@dubbo.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@dubbo.apache.org For additional commands, e-mail: notifications-h...@dubbo.apache.org
