导读
背景
Confluence是一个专业的企业知识管理与协同软件，也可以用于构建企业wiki，该软件在 2004 年首次发布。
2022 年 6 月 2 日，Atlassian 发布了针对 CVE-2022-26134 的安全公告，这是 Confluence Server 和 Confluence Data Center 中一个无需身份验证的远程代码执行漏洞。截至 6 月 3 日，官方发布安全补丁修复了这个漏洞。
攻防
Confluence出现的OGNL漏洞对于开发者来说应该不会太陌生，开发者似乎习惯了会层出不穷的OGNL问题。
于是，从Confluence从 v7.15 版开始， 在 OGNL 表达式解析时加入了一个SafeExpressionUtil安全类，针对继承类、包名、方法名和表达式进行了黑名单拦截，针对类名附加了白名单控制，并增加了一些方法调用和实例创建的沙箱限制机制。SafeExpressionUtil沙箱安全类的这些方法是：
-
unsafePropertyNames
-
unsafePackageNames
-
unsafeMethodNames
-
allowedClassNames
-
containsUnsafeExpression
思考
在学习编码的时候，估计大家都听过“不要相信用户的输入”，指的就是对用户输入做检查的必要性。对数据做预期准确性检查就是防御性编程中的一种，如检查数据格式是否准确、类型是否准确、长度是否准确等等。
这种编码意识就是防御性编程，而这一概念最早来自于汽车的防御性驾驶（defensive driving）技术，即：有预见性的驾驶，预见性地避开路上的危险。如图，我们在马路上要避开“大家伙”，我们要注意“大家伙”的盲区。
突破
当然，防御性编程是一种防卫方式，而不是一种补救形式，程序员从一开始就知道安全问题不可避免。
黑白名单作为防御性编程常见的一种方式，通俗的说它就是程序员可以预见的情况，预见这种行为，本身自己也会有“盲区”，因此绕过黑白名单也再正常不过，攻击者通常会对程序员还未预见的情况进行突破。
例如，这次的漏洞利用要突破沙盒，安全社区就想到使用白名单的原生功能增加管理员用户。
例如，程序员本身没有考虑到的反射调用情况或者Bug，可能被更彻底的直接突破进行RCE。
经过这些例子，我们会发现防御性安全编程实际上是一种人与人之间的认知经验对抗。
悟道
再多衍生一些思考，「先进攻防社群」对于可预见的信任边界和对不可预见的危机处理的话题，曾经都做过一些讨论，我们认为这些不过是安全设计的基本原则…
安全问题的本质都是信任的问题，被划分出来的具有不同信任级别的区域，划分出两个不同信任域之间的边界，我们可以称之为信任边界。
而对于无法预见的安全事故…这在传统行业被称为“黑盒子”。在做好防御检查的同时，我们也需要做好最坏的打算，对异常数据进行日志记录保存，以应对以后可能会出现的最坏情况。
防御规避机制解读（The Mechanics of Defense Evasion）
2022年最简单的Office 0day漏洞
原文始发于微信公众号（赛博攻防悟道）：Confluence 0day漏洞攻防悟道
