引言
近期，Doyensec 受雇于一家提供“通信平台即服务”（CPaaS）的客户。该平台允许其客户打造客服体验，并通过电子邮件、网络聊天、社交媒体等多种渠道与自己的客户沟通。
尽管此类服务价值毋庸置疑，但它也引入了独特的威胁模型。该客户的用户每天需要处理大量来自外部（通常是匿名的）用户的通信，这使他们特别容易受到网络钓鱼和其他社交工程攻击。
虽然这类威胁无法完全消除，但可以最大限度地减少被利用的可能性。认识到这一点后，客户聘请 Doyensec 进行了一次安全审查，特别侧重于社交工程攻击，尤其是钓鱼攻击。这项于今年早些时候进行的合作，被证明对双方都极具价值。最重要的是，客户利用审查结果极大地增强了其平台抵御社交工程攻击的能力。此外，Doyensec 的工程师们也有了一个绝佳的机会，将他们的创造力倾注于那些在标准安全审计中常被忽视或严重低估的漏洞，并有机会从蓝队的角度审视应用防护。
以下案例研究将讨论作为此次审计一部分而得到解决的一些漏洞。希望这篇文章能帮助开发人员了解他们的平台中可能潜伏着哪些类型的漏洞，同时也展示了此类有针对性的合作作为标准Web安全评估补充的巨大价值。
附件处理
对于任何客服组织而言，文件附件管理都是一项关键功能。一方面，用户需要能够与对话方共享文件样本、截图等。另一方面，共享文件始终是滋生各类安全漏洞的温床，尤其是在接受来自不受信任方的文件时。因此，要加固应用的这部分功能，始终需要仔细权衡如何确保机密性和完整性，同时又不牺牲可用性。
通过尾部句点绕过文件扩展名限制
被测试的平台采用了一套稳健的系统，旨在验证文件上传所允许的文件扩展名和内容类型，并包含一个全局禁止列表，以阻止本质上危险的文件类型，例如可执行文件（如 .exe）。这些措施旨在防止上传和分发潜在的恶意文件。然而，通过利用某些浏览器的特性，我们发现了一个漏洞，允许用户仅通过在文件扩展名后附加一个尾部句点（“悬挂点”）来绕过这些限制。
可以通过构造一个包含被禁止扩展名（如 .exe.）的上传请求来绕过此文件扩展名限制。这将导致系统接受该文件，因为从表面上看它符合允许上传的条件——其中包括空扩展名。但是，Firefox 和基于 Chromium 的浏览器会移除悬挂点（有趣的是，Safari 会保留它）。结果，文件以原始的 .exe 扩展名保存到受害者的文件系统中：
|
|
这里的建议很简单。应从文件名中移除尾部句点。在实际场景中它几乎没有用处，因此对可用性的影响微乎其微。
通过构造子域名规避内容来源限制
平台聊天功能创建了一项限制，只允许上传来自客户子域名的链接附件。这项安全控制旨在将图像和附件的上传及引用限制在预定义的一组来源内，防止使用可能用于钓鱼攻击的外部来源。预期的验证过程依赖于一个域名白名单。
然而，当使用正则表达式验证（子）域名时，很容易忘记这种语法的复杂性，从而导致难以发现的绕过方式。
Doyensec 观察到，子域名是使用类似于 /acme-attachments-1.com/ 的正则表达式白名单进行匹配的。这样的正则表达式没有强制字符串的开头和结尾，因此会接受任何包含所需子域名的域名。攻击者可以创建一个类似于 acme-attachments-1.com.doyensec.com 的子域名，尽管存在此安全机制，该域名仍会被接受。
另一个常见（虽然在此例中不可利用）的错误是忘记正则表达式中点（.）字符被视为通配符。当在域名正则表达式中忘记转义一个点时，攻击者可以注册一个能绕过此限制的域名。例如，类似于 downloads.acmecdn.com 的正则表达式会接受攻击者控制的域名，如 downloadsAacmecdn.com。
值得注意的是，尽管此漏洞看起来无害，但它实际上具有制造成功钓鱼攻击的巨大潜力。当受害者在受信任的平台内收到附件时，他们更有可能点击链接。此外，登录页面对受害者来说并不意外，这进一步增加了他们泄露凭证的可能性。
绕过反病毒扫描
该平台对所有传入的文件适当地实施了反病毒扫描。然而，攻击者可以通过创建加密压缩包来混淆有效载荷的真实内容：$ zip -e test_encrypted.zip eicar.com。
解决这个问题没有简单的办法。完全禁止加密压缩包是一种可用性上的权衡，在某些情况下可能无法接受。Doyensec 建议至少明确警告用户不要打开加密文件。通过创建适当的配置开关，让客户选择哪种权衡对他们可以接受，可能也很有用。
HTML输入处理
在交换消息时，能够添加格式并赋予用户更多自我表达的方式会非常有用。另一方面，当消息来自不受信任的来源时，此类功能可能使攻击者能够精心策划涉及界面伪装（例如，在其消息中模拟UI元素）的复杂攻击。
我们的客户找到了一种平衡可用性和安全性的好方法。虽然受信任的用户拥有丰富的输入格式选项，但来自平台外部的非受信任用户只能共享基本的纯文本消息。同样值得注意的是，即使是受信任的用户也无法向消息中注入任意 HTML，因为 HTML 标签会被正确解析和编码。然而，某些特定标签是被允许的，并且在某些情况下会转换为更复杂的元素（例如，链接标签会被转换为按钮）。
Doyensec 认为该解决方案在设计层面架构良好。然而，由于实现上的疏忽，公共消息 API 也接受了一个“隐藏的”（前端未使用的）参数，该参数允许某些 HTML 元素。Doyensec 能够利用链接转换为按钮的功能，演示了利用此漏洞冒充UI元素的潜力。
|
|
该问题通过在公共 API 中完全禁用此参数得到解决，仅允许经过身份验证的用户格式化其消息。
链接展示漏洞
数据展示漏洞是一种尤其容易被忽视的威胁。尽管它们具有操纵或扭曲关键信息的潜力，但数据展示漏洞在安全评估中经常被低估，并在修复优先级排序中被忽视。然而，利用这些漏洞可能导致严重后果，包括钓鱼攻击。
具有误导性的Unicode域名渲染
要理解这个问题，重要的是理解两个不同的术语。首先是 Punycode，它是一种用于在域名中表示Unicode字符的编码方案。它使浏览器和其他Web客户端能够处理域名中的Unicode。其次，我们有同形异义词，即看起来非常相似但编码不同的字符。虽然视觉上难以区分，但请考虑字符 ‘a’（编码：0x61）和 ‘а’（编码：0x430）实际上是两个不同的字符，当用于URL时会导致两个不同的域名。
这种威胁最突出的例子之一是研究员 Xudong Zheng 创建的。该研究员创建了一个链接，看起来与广泛受信任的 www.apple.com 域名惊人地相似。然而，链接 https://www.аррӏе.com 在展开 Punycode 字符串后实际上解析到 www.xn--80ak6aa92e.com。访问该链接会发现它并非由 Apple 控制，尽管其外观极具欺骗性：
|
|
为了保护用户免受此类问题的影响，我们建议以 Punycode 格式渲染 Unicode 域名。这样，用户就不会被关于给定链接指向何处的信息所欺骗。
通过RTLO注入进行URI和文件名欺骗
使用从右到左覆盖（RTLO）字符是另一种操纵链接显示方式的技术。RTLO 字符会改变后续字符的渲染顺序。对于文件名和 URL 来说，它们的结构是固定的，字符顺序很重要。因此，翻转字符顺序是混淆链接真实目标或文件扩展名的有效方法。
听起来很复杂？举个例子就清楚了。考虑指向攻击者控制域名的链接：https://gepj.net/selif#/moc.rugmi。它看起来很可疑，但当在前面加上 RTLO Unicode 字符（[U+202E]https://gepj.net/selif#/moc.rugmi）后，它会以下列方式渲染：
|
|
显示的文件扩展名也可以类似地被操纵：
考虑一个名为 test.[U+202E]fdp.zip 的文件：
|
|
这里提出的解决方案很简单——更严格的过滤。当字符顺序被改变时，URL 不应被渲染为链接。同样，包含字符流操纵符的文件名应被拒绝。
非受信任链接导航确认
即使链接总是正确显示，攻击者仍然有可能发动成功的钓鱼活动。毕竟，用户总是可能被诱骗点击恶意链接。这种风险无法完全消除，但可以通过额外的加固来缓解。被审查的平台实现了导航确认中间页面。这意味着，每当用户点击平台外部的链接时，都会出现一个额外的确认屏幕。此类UI元素会告知用户他们正在离开安全环境。这种UX设计大大降低了钓鱼攻击成功的几率。
总结
该项目是针对特定威胁进行主动合作的一个极佳范例。鉴于该平台的特殊威胁模型，此类合作作为常规安全评估及其漏洞赏金计划的补充，被证明极具价值。特别是，一次专门针对钓鱼和社交工程的合作，使我们能够制定一系列建议和加固方案，而这些在常规安全审查中可能只是一笔带过。