前言 这周收到外部合作同事推送的一篇文章，【漏洞通告】Apache Dubbo Provider默认反序列化远程代码执行漏洞（CVE-2020-1948）通告。 按照文章披露的漏洞影响范围，可以说是当前所有的 Dubbo 的版本都有这个问题。 无独有偶，这周在 Github 自己的仓库上推送几行改动，不一会就收到 Github 安全提示，警告当前项目存在安全漏洞CVE-2018-10237。 可以看到这两个漏洞都是利用反序列化进行执行恶意代码，可能很多同学跟我当初一样，看到这个一脸懵逼。好端端的反序列化，怎么就能被恶意利用，用来执行的恶意代码? 这篇文章我们就来聊聊反序列化漏洞，了解一下黑客是如何利用这个漏洞进行攻击。 反序列化漏洞 在了解反序列化漏洞之前，首先我们学习一下两个基础知识。 Java 运行外部命令 Java 中有一个类 Runtime，我们可以使用这个类执行执行一些外部命令。 下面例子中我们使用 Runtime 运行打开系统的计算器软件。 // 仅适用macos Runtime.getRuntime().exec("open -a.... Dubbo 高危漏洞！原来都是反序列化惹得祸 Dubbo
又到周末了，周更选手申请出站~ 这次分享一下上个月碰到的离奇的问题。一个简单的问题，硬是因为异常被悄咪咪吃掉，过关难度直线提升，导致小黑哥排查一个晚上。 这个美好的晚上，本想着开两把 LOL 无限火力，在召唤师峡谷来个五杀的~ 哎，就这样没了啊！我知道，你们一定能理解这种五杀被抢的感觉~ 下次，真的，谁再让我看到悄咪咪的吃掉异常，我真的要上去一 Jio 了！ 好了，本文可不是水文，看完本篇文章，你可以学到以下知识点： Arthas 排查技巧 啥是 NoClassDefFoundError Dubbo 异常内部处理方式 好了，同学们，打开小本子，准备记好知识点~ 起因 我们有个业务系统，应用之间调用链如下所示： A 应用是业务发生起始应用，在这个应用中将会根据一定规则选择最后的通讯渠道 C，然后将这个渠道标识传递给 B 应用。 B 应用的功能类似网关，这个应用将会根据 A 应用传递过来的渠道标识，将会请求路由下发到具体的 C 应用，起到服务路由的功能。 C 应用是与外部应用交互的应用，我们将其称为渠道通讯机。 假设一次业务中，A 应用根据规则选择 C2 的渠道标识，然后传递给.... 谁再悄咪咪的吃掉异常，我上去就是一 JIO Dubbo
晚上日常发布，无奈将应用发挂十几分钟，复盘一下，聊聊一下一些感悟。 晚上发布是一个渠道应用，主要作用为是去支付机构端进行银行卡扣款。 由于这个过程需要报文信息需啊哟在互联网中传输，所以需要进行相应的加签处理。 这里的银行卡等敏感信息需要采用 AES 加密，由于用于加密的私钥长度大于128位，JDK 自带的加密类将会抛出 java.security.InvalidKeyException: Illegal key size 从而导致加密失败。 加密工具类内部吃掉该异常，返回一个空字符串。然后我们上送给支付机构后，对方返回解密失败，从而导致此次交易失败。 解决办法很简单，更换如下目录的这两个 jar 包 local_policy.jar, US_export_policy.jar 。 ${java_home}/jre/lib/security 参考如下：https://blog.csdn.net/wangjunjun2008/article/details/50847426 解决办法 上面说过只要更换这两个 jar 包就可以就解决问题，但是生产环境技术人员是没有权限，只能通过邮件审批，.... 一不小心又把应用发挂了，复盘一下这十几分钟的黑暗时刻 小黑黑的碎碎念
程序通事