dubbo 🚀 - [CVE-2020-1948] 漏洞修复方案讨论

参考这篇文章进行修改 http://rui0.cn/archives/1338

horizonzy on 24 Jun 2020

一个简单的方法解决这个问题就是。修改org.apache.dubbo.rpc.RpcInvocation#的toString方法。把arguments的打印去掉。

horizonzy on 25 Jun 2020

👍1

一个简单的方法解决这个问题就是。修改org.apache.dubbo.rpc.RpcInvocation#的toString方法。把arguments的打印去掉。

这个可行吗？

spilledyear on 25 Jun 2020

可行。我的版本是针对2.7.2

horizonzy on 25 Jun 2020

可行。我的版本是针对2.7.2

大佬，安全测试这一块我该这么做呢？就是我修改之后，该如何确认我这个修改是生效了呢？能指导一下啊吗？没接触过这快

spilledyear on 25 Jun 2020

你基于dubbo的Demo.在DubboInvoker的doInvoke方法中。强制把interface写成一个不存在的。在provider端看看最后会不会对arguments进行toString方法。本次的安全漏洞就是基于对arguments进行了toString导致的

发自我的iPhone

------------------ 原始邮件 ------------------
发件人: spilledyear <[email protected]>
发送时间: 2020年6月25日 22:12
收件人: apache/dubbo <[email protected]>
抄送: 赵延 <[email protected]>, Comment <[email protected]>
主题: 回复：[apache/dubbo] [CVE-2020-1948] 漏洞修复方案讨论 (#6364)

可行。我的版本是针对2.7.2

大佬，安全测试这一块我该这么做呢？就是我修改之后，该如何确认我这个修改是生效了呢？能指导一下啊吗？没接触过这快

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

horizonzy on 25 Jun 2020

也可以基于这个报告来进行模拟。https://www.mail-archive.com/[email protected]/msg06544.html

horizonzy on 25 Jun 2020

你基于dubbo的Demo.在DubboInvoker的doInvoke方法中。强制把interface写成一个不存在的。在provider端看看最后会不会对arguments进行toString方法。本次的安全漏洞就是基于对arguments进行了toString导致的发自我的iPhone
…
------------------ 原始邮件 ------------------ 发件人: spilledyear <[email protected]> 发送时间: 2020年6月25日 22:12 收件人: apache/dubbo <[email protected]> 抄送: 赵延 <[email protected]>, Comment <[email protected]> 主题: 回复：[apache/dubbo] [CVE-2020-1948] 漏洞修复方案讨论 (#6364) 可行。我的版本是针对2.7.2 大佬，安全测试这一块我该这么做呢？就是我修改之后，该如何确认我这个修改是生效了呢？能指导一下啊吗？没接触过这快 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

感谢。但是我在consumer端改成了一个不存在的methodName, 并没有在provider发现执行了RpcInvocation的toString方法啊.只是抛出了 Not found method "cccccc" in

spilledyear on 26 Jun 2020

你把path改成不存在的看看。provider通过path:port去找的invoked.我看ruilin说的当method或者interface不存在时会出现该问题，我认为应该是interface不存在时才会出该问题。

发自我的iPhone

------------------ 原始邮件 ------------------
发件人: spilledyear <[email protected]>
发送时间: 2020年6月26日 21:27
收件人: apache/dubbo <[email protected]>
抄送: 赵延 <[email protected]>, Comment <[email protected]>
主题: 回复：[apache/dubbo] [CVE-2020-1948] 漏洞修复方案讨论 (#6364)

你基于dubbo的Demo.在DubboInvoker的doInvoke方法中。强制把interface写成一个不存在的。在provider端看看最后会不会对arguments进行toString方法。本次的安全漏洞就是基于对arguments进行了toString导致的发自我的iPhone
…
------------------ 原始邮件 ------------------ 发件人: spilledyear <[email protected]> 发送时间: 2020年6月25日 22:12 收件人: apache/dubbo <[email protected]> 抄送: 赵延 <[email protected]>, Comment <[email protected]> 主题: 回复：[apache/dubbo] [CVE-2020-1948] 漏洞修复方案讨论 (#6364) 可行。我的版本是针对2.7.2 大佬，安全测试这一块我该这么做呢？就是我修改之后，该如何确认我这个修改是生效了呢？能指导一下啊吗？没接触过这快 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

感谢。但是我在consumer端改成了一个不存在的methodName, 并没有在provider发现执行了RpcInvocation的toString方法啊.只是抛出了 Not found method "cccccc" in

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

horizonzy on 26 Jun 2020

你把path改成不存在的看看。provider通过path:port去找的invoked.我看ruilin说的当method或者interface不存在时会出现该问题，我认为应该是interface不存在时才会出该问题。发自我的iPhone
…
------------------ 原始邮件 ------------------ 发件人: spilledyear <[email protected]> 发送时间: 2020年6月26日 21:27 收件人: apache/dubbo <[email protected]> 抄送: 赵延 <[email protected]>, Comment <[email protected]> 主题: 回复：[apache/dubbo] [CVE-2020-1948] 漏洞修复方案讨论 (#6364) 你基于dubbo的Demo.在DubboInvoker的doInvoke方法中。强制把interface写成一个不存在的。在provider端看看最后会不会对arguments进行toString方法。本次的安全漏洞就是基于对arguments进行了toString导致的发自我的iPhone … ------------------ 原始邮件 ------------------ 发件人: spilledyear <[email protected]> 发送时间: 2020年6月25日 22:12 收件人: apache/dubbo <[email protected]> 抄送: 赵延 <[email protected]>, Comment <[email protected]> 主题: 回复：[apache/dubbo] [CVE-2020-1948] 漏洞修复方案讨论 (#6364) 可行。我的版本是针对2.7.2 大佬，安全测试这一块我该这么做呢？就是我修改之后，该如何确认我这个修改是生效了呢？能指导一下啊吗？没接触过这快 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. 感谢。但是我在consumer端改成了一个不存在的methodName, 并没有在provider发现执行了RpcInvocation的toString方法啊.只是抛出了 Not found method "cccccc" in — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

path 是个final变量，有什么办法可以修改吗？

spilledyear on 26 Jun 2020

path是通过attachments传递的。debug看DubboProtocol的requestHandler的replay。有个geyInvoker方法。跟这个

发自我的iPhone

------------------ 原始邮件 ------------------
发件人: spilledyear <[email protected]>
发送时间: 2020年6月26日 21:44
收件人: apache/dubbo <[email protected]>
抄送: 赵延 <[email protected]>, Comment <[email protected]>
主题: 回复：[apache/dubbo] [CVE-2020-1948] 漏洞修复方案讨论 (#6364)

你把path改成不存在的看看。provider通过path:port去找的invoked.我看ruilin说的当method或者interface不存在时会出现该问题，我认为应该是interface不存在时才会出该问题。发自我的iPhone
…
------------------ 原始邮件 ------------------ 发件人: spilledyear <[email protected]> 发送时间: 2020年6月26日 21:27 收件人: apache/dubbo <[email protected]> 抄送: 赵延 <[email protected]>, Comment <[email protected]> 主题: 回复：[apache/dubbo] [CVE-2020-1948] 漏洞修复方案讨论 (#6364) 你基于dubbo的Demo.在DubboInvoker的doInvoke方法中。强制把interface写成一个不存在的。在provider端看看最后会不会对arguments进行toString方法。本次的安全漏洞就是基于对arguments进行了toString导致的发自我的iPhone … ------------------ 原始邮件 ------------------ 发件人: spilledyear <[email protected]> 发送时间: 2020年6月25日 22:12 收件人: apache/dubbo <[email protected]> 抄送: 赵延 <[email protected]>, Comment <[email protected]> 主题: 回复：[apache/dubbo] [CVE-2020-1948] 漏洞修复方案讨论 (#6364) 可行。我的版本是针对2.7.2 大佬，安全测试这一块我该这么做呢？就是我修改之后，该如何确认我这个修改是生效了呢？能指导一下啊吗？没接触过这快 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. 感谢。但是我在consumer端改成了一个不存在的methodName, 并没有在provider发现执行了RpcInvocation的toString方法啊.只是抛出了 Not found method "cccccc" in — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

path 是个final变量，有什么办法可以修改吗？

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

horizonzy on 26 Jun 2020

你把path改成不存在的看看。provider通过path:port去找的invoked.我看ruilin说的当method或者interface不存在时会出现该问题，我认为应该是interface不存在时才会出该问题。发自我的iPhone
…
------------------ 原始邮件 ------------------ 发件人: spilledyear <[email protected]> 发送时间: 2020年6月26日 21:27 收件人: apache/dubbo <[email protected]> 抄送: 赵延 <[email protected]>, Comment <[email protected]> 主题: 回复：[apache/dubbo] [CVE-2020-1948] 漏洞修复方案讨论 (#6364) 你基于dubbo的Demo.在DubboInvoker的doInvoke方法中。强制把interface写成一个不存在的。在provider端看看最后会不会对arguments进行toString方法。本次的安全漏洞就是基于对arguments进行了toString导致的发自我的iPhone … ------------------ 原始邮件 ------------------ 发件人: spilledyear <[email protected]> 发送时间: 2020年6月25日 22:12 收件人: apache/dubbo <[email protected]> 抄送: 赵延 <[email protected]>, Comment <[email protected]> 主题: 回复：[apache/dubbo] [CVE-2020-1948] 漏洞修复方案讨论 (#6364) 可行。我的版本是针对2.7.2 大佬，安全测试这一块我该这么做呢？就是我修改之后，该如何确认我这个修改是生效了呢？能指导一下啊吗？没接触过这快 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. 感谢。但是我在consumer端改成了一个不存在的methodName, 并没有在provider发现执行了RpcInvocation的toString方法啊.只是抛出了 Not found method "cccccc" in — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

path 是个final变量，有什么办法可以修改吗？

horizonzy on 27 Jun 2020

你把path改成不存在的看看。provider通过path:port去找的invoked.我看ruilin说的当method或者interface不存在时会出现该问题，我认为应该是interface不存在时才会出该问题。发自我的iPhone
…
------------------ 原始邮件 ------------------ 发件人: spilledyear <[email protected]> 发送时间: 2020年6月26日 21:27 收件人: apache/dubbo <[email protected]> 抄送: 赵延 <[email protected]>, Comment <[email protected]> 主题: 回复：[apache/dubbo] [CVE-2020-1948] 漏洞修复方案讨论 (#6364) 你基于dubbo的Demo.在DubboInvoker的doInvoke方法中。强制把interface写成一个不存在的。在provider端看看最后会不会对arguments进行toString方法。本次的安全漏洞就是基于对arguments进行了toString导致的发自我的iPhone … ------------------ 原始邮件 ------------------ 发件人: spilledyear <[email protected]> 发送时间: 2020年6月25日 22:12 收件人: apache/dubbo <[email protected]> 抄送: 赵延 <[email protected]>, Comment <[email protected]> 主题: 回复：[apache/dubbo] [CVE-2020-1948] 漏洞修复方案讨论 (#6364) 可行。我的版本是针对2.7.2 大佬，安全测试这一块我该这么做呢？就是我修改之后，该如何确认我这个修改是生效了呢？能指导一下啊吗？没接触过这快 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. 感谢。但是我在consumer端改成了一个不存在的methodName, 并没有在provider发现执行了RpcInvocation的toString方法啊.只是抛出了 Not found method "cccccc" in — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

path 是个final变量，有什么办法可以修改吗？

感谢！path改过之后确实发现在provider端执行了 RpcInvocation.toString 方法

spilledyear on 27 Jun 2020

引用rui0的话，“这里需要注意一下，因为最近的Dubbo反序列化漏洞公布了。所以需要补充一下，因为主题的关系文章中只提到了Dubbo的toString触发点，但是Dubbo实际上在刚传入序列化值时也有一个触发点，漏洞公布的邮件里并没有涉及全部的细节以及poc，所以一些版本如果在代码层面只去掉输出arguments处理，仍然还有其他触发位置可能存在风险。
建议各位开发者尽量采取升级措施，或在代码层面去掉arguments的输出同时对Hessian进行加固。”
我觉得有两个修复思路：

在代码层面去掉arguments的输出，同时对Hessian进行加固（这点很重要，2.7.7没有彻底修复此问题）。
暂时先使用其他协议来替代hessian2。

aquariuspj on 27 Jun 2020

@aquariuspj 实在没看懂hessian2怎么就导致这个漏洞了,其他序列化也会出现同样的漏洞吧, 只要调用Arrays.toString(arguments)都可能出现这个问题吧

brucelwl on 27 Jun 2020

引用rui0的话，“这里需要注意一下，因为最近的Dubbo反序列化漏洞公布了。所以需要补充一下，因为主题的关系文章中只提到了Dubbo的toString触发点，但是Dubbo实际上在刚传入序列化值时也有一个触发点，漏洞公布的邮件里并没有涉及全部的细节以及poc，所以一些版本如果在代码层面只去掉输出arguments处理，仍然还有其他触发位置可能存在风险。
建议各位开发者尽量采取升级措施，或在代码层面去掉arguments的输出同时对Hessian进行加固。”
我觉得有两个修复思路：

在代码层面去掉arguments的输出，同时对Hessian进行加固（这点很重要，2.7.7没有彻底修复此问题）。

暂时先使用其他协议来替代hessian2。

加固指的是什么？校验吗？

spilledyear on 27 Jun 2020

@aquariuspj 实在没看懂hessian2怎么就导致这个漏洞了,其他序列化也会出现同样的漏洞吧, 只要调用Arrays.toString(arguments)都可能出现这个问题吧

是的，目前看下来问题暴露在DubboProtocol的264行，因此在dubbo的protocol框架下，就算采用了其他序列化协议，理论上也会出现问题。
有讨论说使用protobuf能解决此问题，我持怀疑态度，并且更换代价很大。

我倾向于在反序列化前做一些校验：

先升级2.7.7版本。
org.apache.dubbo.rpc.support.RpcUtils中修改下面两个方法，对入参类型描述再做一次判断：

    // check parameterTypesDesc to fix CVE-2020-1948
    public static boolean isGenericCall(String parameterTypesDesc, String method) {
        return ($INVOKE.equals(method) || $INVOKE_ASYNC.equals(method)) && GENERIC_PARAMETER_DESC.equals(parameterTypesDesc);
    }

    // check parameterTypesDesc to fix CVE-2020-1948
    public static boolean isEcho(String parameterTypesDesc, String method) {
        return $ECHO.equals(method) && "Ljava/lang/Object;".equals(parameterTypesDesc);
    }

在DecodeableRpcInvocation中133行，把入参描述传到方法里面，在反序列化前对输入内容进行校验：

                if (pts == DubboCodec.EMPTY_CLASS_ARRAY) {
                    if (!RpcUtils.isGenericCall(desc, getMethodName()) && !RpcUtils.isEcho(desc, getMethodName())) {
                        throw new IllegalArgumentException("Service not found:" + path + ", " + getMethodName());
                    }
                    pts = ReflectUtils.desc2classArray(desc);
                }

aquariuspj on 27 Jun 2020

引用rui0的话，“这里需要注意一下，因为最近的Dubbo反序列化漏洞公布了。所以需要补充一下，因为主题的关系文章中只提到了Dubbo的toString触发点，但是Dubbo实际上在刚传入序列化值时也有一个触发点，漏洞公布的邮件里并没有涉及全部的细节以及poc，所以一些版本如果在代码层面只去掉输出arguments处理，仍然还有其他触发位置可能存在风险。
建议各位开发者尽量采取升级措施，或在代码层面去掉arguments的输出同时对Hessian进行加固。”
我觉得有两个修复思路：

在代码层面去掉arguments的输出，同时对Hessian进行加固（这点很重要，2.7.7没有彻底修复此问题）。

暂时先使用其他协议来替代hessian2。

加固指的是什么？校验吗？

嗯，是的。

aquariuspj on 27 Jun 2020

请问2.6.8的版本是不是已经修复了这个【CVE-2020-1948】漏洞。

frhui on 28 Jun 2020

请问2.6.8的版本是不是已经修复了这个【CVE-2020-1948】漏洞。

需要升级到最近版本

horizonzy on 28 Jun 2020

INVOKE_ASYNC

是不是可以理解成，在没有升级到2.7.7的情况下，如果其它版本中不存在相关会产生漏洞的代码，其实只要修改这两个地方就可以了呢？

spilledyear on 28 Jun 2020

我的建议是发布一下dubbo低版本的兼容方案（至少2.6.X还是需要的吧承诺的是2.6.x是维护版本）

qixiaobo on 28 Jun 2020

👍3

一个简单的方法解决这个问题就是。修改org.apache.dubbo.rpc.RpcInvocation#的toString方法。把arguments的打印去掉。

大佬，我有一个问题实在想不明白，添加服务和方法校验为什么就能解决这个漏洞呢？如果恶意代码在参数里面，有效的服务和方法不也可以触发触发恶意代码的执行吗？

spilledyear on 28 Jun 2020

一个简单的方法解决这个问题就是。修改org.apache.dubbo.rpc.RpcInvocation#的toString方法。把arguments的打印去掉。

大佬，我有一个问题实在想不明白，添加服务和方法校验为什么就能解决这个漏洞呢？如果恶意代码在参数里面，有效的服务和方法不也可以触发触发恶意代码的执行吗？

在恶意对象的反序列化之前就抛异常，后面的代码就都执行不到了。

aquariuspj on 28 Jun 2020

@aquariuspj 实在没看懂hessian2怎么就导致这个漏洞了,其他序列化也会出现同样的漏洞吧, 只要调用Arrays.toString(arguments)都可能出现这个问题吧

是的，目前看下来问题暴露在DubboProtocol的264行，因此在dubbo的protocol框架下，就算采用了其他序列化协议，理论上也会出现问题。
有讨论说使用protobuf能解决此问题，我持怀疑态度，并且更换代价很大。
我倾向于在反序列化前做一些校验：

先升级2.7.7版本。

org.apache.dubbo.rpc.support.RpcUtils中修改下面两个方法，对入参类型描述再做一次判断：
    // check parameterTypesDesc to fix CVE-2020-1948
    public static boolean isGenericCall(String parameterTypesDesc, String method) {
        return ($INVOKE.equals(method) || $INVOKE_ASYNC.equals(method)) && GENERIC_PARAMETER_DESC.equals(parameterTypesDesc);
    }

    // check parameterTypesDesc to fix CVE-2020-1948
    public static boolean isEcho(String parameterTypesDesc, String method) {
        return $ECHO.equals(method) && "Ljava/lang/Object;".equals(parameterTypesDesc);
    }
在DecodeableRpcInvocation中133行，把入参描述传到方法里面，在反序列化前对输入内容进行校验：
                if (pts == DubboCodec.EMPTY_CLASS_ARRAY) {
                    if (!RpcUtils.isGenericCall(desc, getMethodName()) && !RpcUtils.isEcho(desc, getMethodName())) {
                        throw new IllegalArgumentException("Service not found:" + path + ", " + getMethodName());
                    }
                    pts = ReflectUtils.desc2classArray(desc);
                }
如果不升级直接修改，是不是会有图上说的这种问题呢。升级成本比较大，有什么不升级可以解决问题的方法吗？

这块我也没有做过测试，单从这段逻辑上看我感觉应该是没问题的，你可以做下测试回头告诉一下我们结论 0w0。
不升级的话，我能想到的办法也是和horizonzy同学一样，把arguments的打印逻辑去掉，这样做也最简单，也足以应付公司安全审计了...

aquariuspj on 28 Jun 2020

一个简单的方法解决这个问题就是。修改org.apache.dubbo.rpc.RpcInvocation#的toString方法。把arguments的打印去掉。

大佬，我有一个问题实在想不明白，添加服务和方法校验为什么就能解决这个漏洞呢？如果恶意代码在参数里面，有效的服务和方法不也可以触发触发恶意代码的执行吗？

在恶意对象的反序列化之前就抛异常，后面的代码就都执行不到了。

抛出异常是因为前置添加了校验，判断它不是一个有效的服务或方法，所以抛出异常。那假如是有效的服务和方法呢？然后它的参数类型是byte[],恶意代码在参数中，这时候校验可以通过，不也会导致恶意代码执行吗？

spilledyear on 28 Jun 2020

一个简单的方法解决这个问题就是。修改org.apache.dubbo.rpc.RpcInvocation#的toString方法。把arguments的打印去掉。

大佬，我有一个问题实在想不明白，添加服务和方法校验为什么就能解决这个漏洞呢？如果恶意代码在参数里面，有效的服务和方法不也可以触发触发恶意代码的执行吗？

只是增加攻击难度，并不能解决漏洞

brucelwl on 28 Jun 2020

请问：这个漏洞是不是也可以通过魔改dubbo部分源代码形式修复？
比如在2.5.3中反序列化时，增加“Ignore deserilization when service/method not found #5733”逻辑来实现规避该漏洞呢？

感觉可以，但涉及到的内容有点多，ServiceRepository这一块的内容都要搬过去

spilledyear on 28 Jun 2020

一个简单的方法解决这个问题就是。修改org.apache.dubbo.rpc.RpcInvocation#的toString方法。把arguments的打印去掉。

大佬，我有一个问题实在想不明白，添加服务和方法校验为什么就能解决这个漏洞呢？如果恶意代码在参数里面，有效的服务和方法不也可以触发触发恶意代码的执行吗？

只是增加攻击难度，并不能解决漏洞

这个漏洞的恶意代码就是在参数里面触发的，由于可以反序列化任意参数类型才会导致相应问题。所以对服务、方法和入参类型添加校验可以屏蔽一部分攻击。
当然，不排除攻击者通过有效的服务、有效的方法加上有效的参数类型来发起攻击，不过这种场景应该在应用层去做控制..因为已经执行到了业务逻辑层了。

aquariuspj on 28 Jun 2020

@aquariuspj
这个问题在2.7.7之前的版本确实存在，2.7.7修复了这个问题

spilledyear on 28 Jun 2020

一个简单的方法解决这个问题就是。修改org.apache.dubbo.rpc.RpcInvocation#的toString方法。把arguments的打印去掉。

大佬，我有一个问题实在想不明白，添加服务和方法校验为什么就能解决这个漏洞呢？如果恶意代码在参数里面，有效的服务和方法不也可以触发触发恶意代码的执行吗？

只是增加攻击难度，并不能解决漏洞

这个漏洞的恶意代码就是在参数里面触发的，由于可以反序列化任意参数类型才会导致相应问题。所以对服务、方法和入参类型添加校验可以屏蔽一部分攻击。
当然，不排除攻击者通过有效的服务、有效的方法加上有效的参数类型来发起攻击，不过这种场景应该在应用层去做控制..因为已经执行到了业务逻辑层了。

自定义实体类参数怎么攻击，我测试了下，写入其他类型的话是无法触发toString方法的，在之前就被classNotFoundException拦截住，然后参数就变为null对象，就算触发了toString也无法执行远程代码

wujincheng2333 on 28 Jun 2020

一个简单的方法解决这个问题就是。修改org.apache.dubbo.rpc.RpcInvocation#的toString方法。把arguments的打印去掉。

大佬，我有一个问题实在想不明白，添加服务和方法校验为什么就能解决这个漏洞呢？如果恶意代码在参数里面，有效的服务和方法不也可以触发触发恶意代码的执行吗？

只是增加攻击难度，并不能解决漏洞

这个漏洞的恶意代码就是在参数里面触发的，由于可以反序列化任意参数类型才会导致相应问题。所以对服务、方法和入参类型添加校验可以屏蔽一部分攻击。
当然，不排除攻击者通过有效的服务、有效的方法加上有效的参数类型来发起攻击，不过这种场景应该在应用层去做控制..因为已经执行到了业务逻辑层了。

自定义实体类参数怎么攻击，我测试了下，写入其他类型的话是无法触发toString方法的，在之前就被classNotFoundException拦截住，然后参数就变为null对象，就算触发了toString也无法执行远程代码

POC里发起攻击的前提条件是项目里面要包含有这个依赖包：

        <dependency>
            <groupId>com.rometools</groupId>
            <artifactId>rome</artifactId>
            <version>1.7.0</version>
        </dependency>

但除了这个jar包之外，项目里依赖的其他jar包有没有类似的能够被利用的构造方法、toString方法或者其他方法，这也很难保证。

aquariuspj on 28 Jun 2020

建议修改代码解决toString这个触发点，
其次可以参考 aquariuspj 同学的建议，增加对参数类型的校验。

r00t4dm on 28 Jun 2020

👍3 🎉1

利用点除了 toString 的方式还有别的方式进行利用，所以不仅应该考虑使用 toString