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

[vincent2518]

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

[horizonzy]

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

[horizonzy]

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

[spilledyear]

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

这个可行吗？

[horizonzy]

可行。我的版本是针对2.7.2

[spilledyear]

可行。我的版本是针对2.7.2

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

[horizonzy]

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

…

------------------ 原始邮件 ------------------ 发件人: spilledyear <notifications@github.com&gt; 发送时间: 2020年6月25日 22:12 收件人: apache/dubbo <dubbo@noreply.github.com&gt; 抄送: 赵延 <1060026287@qq.com&gt;, Comment <comment@noreply.github.com&gt; 主题: 回复：[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]

也可以基于这个报告来进行模拟。https://www.mail-archive.com/dev@dubbo.apache.org/msg06544.html

[spilledyear]

你基于dubbo的Demo.在DubboInvoker的doInvoke方法中。强制把interface写成一个不存在的。在provider端看看最后会不会对arguments进行toString方法。本次的安全漏洞就是基于对arguments进行了toString导致的 发自我的iPhone
…
------------------ 原始邮件 ------------------ 发件人: spilledyear <notifications@github.com> 发送时间: 2020年6月25日 22:12 收件人: apache/dubbo <dubbo@noreply.github.com> 抄送: 赵延 <1060026287@qq.com>, Comment <comment@noreply.github.com> 主题: 回复：[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

[horizonzy]

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

…

------------------ 原始邮件 ------------------ 发件人: spilledyear <notifications@github.com&gt; 发送时间: 2020年6月26日 21:27 收件人: apache/dubbo <dubbo@noreply.github.com&gt; 抄送: 赵延 <1060026287@qq.com&gt;, Comment <comment@noreply.github.com&gt; 主题: 回复：[apache/dubbo] [CVE-2020-1948] 漏洞修复方案讨论 (#6364) 你基于dubbo的Demo.在DubboInvoker的doInvoke方法中。强制把interface写成一个不存在的。在provider端看看最后会不会对arguments进行toString方法。本次的安全漏洞就是基于对arguments进行了toString导致的 发自我的iPhone … ------------------ 原始邮件 ------------------ 发件人: spilledyear <notifications@github.com&gt; 发送时间: 2020年6月25日 22:12 收件人: apache/dubbo <dubbo@noreply.github.com&gt; 抄送: 赵延 <1060026287@qq.com&gt;, Comment <comment@noreply.github.com&gt; 主题: 回复：[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.

[spilledyear]

你把path改成不存在的看看。provider通过path:port去找的invoked.我看ruilin说的当method或者interface不存在时会出现该问题，我认为应该是interface不存在时才会出该问题。 发自我的iPhone
…
------------------ 原始邮件 ------------------ 发件人: spilledyear <notifications@github.com> 发送时间: 2020年6月26日 21:27 收件人: apache/dubbo <dubbo@noreply.github.com> 抄送: 赵延 <1060026287@qq.com>, Comment <comment@noreply.github.com> 主题: 回复：[apache/dubbo] [CVE-2020-1948] 漏洞修复方案讨论 (#6364) 你基于dubbo的Demo.在DubboInvoker的doInvoke方法中。强制把interface写成一个不存在的。在provider端看看最后会不会对arguments进行toString方法。本次的安全漏洞就是基于对arguments进行了toString导致的 发自我的iPhone … ------------------ 原始邮件 ------------------ 发件人: spilledyear <notifications@github.com> 发送时间: 2020年6月25日 22:12 收件人: apache/dubbo <dubbo@noreply.github.com> 抄送: 赵延 <1060026287@qq.com>, Comment <comment@noreply.github.com> 主题: 回复：[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]

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

…

------------------ 原始邮件 ------------------ 发件人: spilledyear <notifications@github.com&gt; 发送时间: 2020年6月26日 21:44 收件人: apache/dubbo <dubbo@noreply.github.com&gt; 抄送: 赵延 <1060026287@qq.com&gt;, Comment <comment@noreply.github.com&gt; 主题: 回复：[apache/dubbo] [CVE-2020-1948] 漏洞修复方案讨论 (#6364) 你把path改成不存在的看看。provider通过path:port去找的invoked.我看ruilin说的当method或者interface不存在时会出现该问题，我认为应该是interface不存在时才会出该问题。 发自我的iPhone … ------------------ 原始邮件 ------------------ 发件人: spilledyear <notifications@github.com&gt; 发送时间: 2020年6月26日 21:27 收件人: apache/dubbo <dubbo@noreply.github.com&gt; 抄送: 赵延 <1060026287@qq.com&gt;, Comment <comment@noreply.github.com&gt; 主题: 回复：[apache/dubbo] [CVE-2020-1948] 漏洞修复方案讨论 (#6364) 你基于dubbo的Demo.在DubboInvoker的doInvoke方法中。强制把interface写成一个不存在的。在provider端看看最后会不会对arguments进行toString方法。本次的安全漏洞就是基于对arguments进行了toString导致的 发自我的iPhone … ------------------ 原始邮件 ------------------ 发件人: spilledyear <notifications@github.com&gt; 发送时间: 2020年6月25日 22:12 收件人: apache/dubbo <dubbo@noreply.github.com&gt; 抄送: 赵延 <1060026287@qq.com&gt;, Comment <comment@noreply.github.com&gt; 主题: 回复：[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]

你把path改成不存在的看看。provider通过path:port去找的invoked.我看ruilin说的当method或者interface不存在时会出现该问题，我认为应该是interface不存在时才会出该问题。 发自我的iPhone
…
------------------ 原始邮件 ------------------ 发件人: spilledyear <notifications@github.com> 发送时间: 2020年6月26日 21:27 收件人: apache/dubbo <dubbo@noreply.github.com> 抄送: 赵延 <1060026287@qq.com>, Comment <comment@noreply.github.com> 主题: 回复：[apache/dubbo] [CVE-2020-1948] 漏洞修复方案讨论 (#6364) 你基于dubbo的Demo.在DubboInvoker的doInvoke方法中。强制把interface写成一个不存在的。在provider端看看最后会不会对arguments进行toString方法。本次的安全漏洞就是基于对arguments进行了toString导致的 发自我的iPhone … ------------------ 原始邮件 ------------------ 发件人: spilledyear <notifications@github.com> 发送时间: 2020年6月25日 22:12 收件人: apache/dubbo <dubbo@noreply.github.com> 抄送: 赵延 <1060026287@qq.com>, Comment <comment@noreply.github.com> 主题: 回复：[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]

你把path改成不存在的看看。provider通过path:port去找的invoked.我看ruilin说的当method或者interface不存在时会出现该问题，我认为应该是interface不存在时才会出该问题。 发自我的iPhone
…
------------------ 原始邮件 ------------------ 发件人: spilledyear <notifications@github.com> 发送时间: 2020年6月26日 21:27 收件人: apache/dubbo <dubbo@noreply.github.com> 抄送: 赵延 <1060026287@qq.com>, Comment <comment@noreply.github.com> 主题: 回复：[apache/dubbo] [CVE-2020-1948] 漏洞修复方案讨论 (#6364) 你基于dubbo的Demo.在DubboInvoker的doInvoke方法中。强制把interface写成一个不存在的。在provider端看看最后会不会对arguments进行toString方法。本次的安全漏洞就是基于对arguments进行了toString导致的 发自我的iPhone … ------------------ 原始邮件 ------------------ 发件人: spilledyear <notifications@github.com> 发送时间: 2020年6月25日 22:12 收件人: apache/dubbo <dubbo@noreply.github.com> 抄送: 赵延 <1060026287@qq.com>, Comment <comment@noreply.github.com> 主题: 回复：[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 方法

[aquariuspj]

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

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

[brucelwl]

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

[spilledyear]

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

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

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

[aquariuspj]

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

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

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

1. 先升级2.7.7版本。
2. 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);
    }

3. 在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]

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

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

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

嗯，是的。

[frhui]

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

[horizonzy]

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

需要升级到最近版本

[spilledyear]

INVOKE_ASYNC

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

[qixiaobo]

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

[spilledyear]

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

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

[aquariuspj]

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

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

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

[aquariuspj]

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

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

1. 先升级2.7.7版本。
2. 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);
    }

1. 在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的打印逻辑去掉，这样做也最简单，也足以应付公司安全审计了...

[spilledyear]

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

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

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

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

[brucelwl]

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

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

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

[spilledyear]

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

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

[aquariuspj]

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

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

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

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

[spilledyear]

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

[wujincheng2333]

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

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

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

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

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

[aquariuspj]

一个简单的方法解决这个问题就是。修改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方法或者其他方法，这也很难保证。

[r00t4dm]

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

[xxxxbxxxxx]

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

[chickenlj]

#6378
#6388

Hessian Whitelist

[awayings]

#6378
#6388

Hessian Whitelist

1. 有没有推荐的blacklist列表。部分已知的能否直接做到系统里面。
2. 在之前讨论( https://xz.aliyun.com/t/7238 )提到的有多个列表的设置。目前的参数形式并设置困难

[clickxiaomi]

-Ddubbo.application.hessian2.allow="org.apache.dubbo.demo.*"
这个配置如果要配置多个路径，要怎么配置呢