隆重推出 Missions：以开发者为中心的安全培训新阶段

自 2015 年以来，我们一直致力于以积极主动的态度吸引全球开发者参与安全建设，帮助他们掌握保护代码的技能，减少返工和修复工作，并希望让安全团队在他们眼中不再是只会说“不”的“扫兴警察”。

我们依然致力于与开发者并肩作战，共同守护代码安全，但现在是时候做出改变，将我们那些久经沙场、具备安全意识的开发者提升到新的高度了。

我们非常高兴地宣布 Secure Code Warrior 平台推出了一项全新功能：Missions（任务）。这一全新的挑战类别是开发者安全培训的下一阶段，旨在引导用户从单纯的安全知识记忆，转向在真实的模拟环境中应用这些知识。这种支架式微学习方法能够构建实用的安全编码技能，不仅与工作高度相关，而且比在工作间隙枯燥地观看冗长的培训视频要有趣得多。

我们首个可玩的公开任务是模拟 GitHub Unicode 漏洞。它看起来可能很简单，但实际上是一个非常巧妙且值得深入剖析的漏洞。安全研究员 0xsha 撰写了一份详尽的案例研究，分析了该漏洞如何通过大小写转换来攻击 Django，并揭示了漏洞行为在不同编程语言间可能产生的差异。关于这个安全问题还有很多值得探索的地方，而我们的任务正是绝佳的起点。

GitHub 的正面（大小写映射）碰撞

在 2019 年 11 月 28 日的一篇博客文章中，安全研究小组 Wisdom 报告了他们在 GitHub 上发现的一个安全漏洞。他们概述了如何利用 Unicode 中的大小写映射碰撞（Case Mapping Collision）来触发密码重置邮件，将其发送到错误的邮箱地址（或者，如果我们站在攻击者的角度思考，即发送到攻击者指定的邮箱地址）。

虽然安全漏洞绝非好事，但那些秉持白帽精神的安全研究人员确实提供了一定的“救赎”——更不用说他们还提供了规避灾难的机会——如果他们能在代码库中发现潜在的可利用错误。他们的博客和报告往往非常值得一读，了解一个新的漏洞及其工作原理也是一件很酷的事情。

为了提升安全编码能力，不仅要发现常见的漏洞（尤其是那些酷炫的新漏洞——我们都知道恶意攻击者会寻找肥沃的土壤，利用这些新技术窃取数据），还要拥有一个安全、可操作的环境来理解如何利用它们，这一点至关重要。

那么，让我们开始吧。继续阅读，了解如何利用 Unicode 大小写映射碰撞，观察其实时表现，并尝试以安全研究员的思维方式亲自体验一番。

准备好现在就挑战大小写映射碰撞了吗？请加入我们：

Unicode：复杂、无限可定制，且远不止表情符号那么简单

“Unicode”可能不在普通人的词汇表中，但大多数人每天都在以某种形式使用它。如果你使用过网页浏览器、任何微软软件或发送过表情符号，那么你已经与 Unicode 进行了亲密接触。它是用于一致性编码和处理全球大多数书写系统文本的标准，确保每个人都能使用统一的字符集进行数字化表达。目前，Unicode 包含超过 143,000 个字符，无论你使用的是冰岛语、土耳其语无点字母，还是其他任何语言，它都能满足你的需求。

由于 Unicode 字符集极其庞大，在许多情况下需要一种将字符转换为另一个“等效”字符的方法。例如，将带有无点字母的 Unicode 字符串转换为 ASCII 时，它应该直接变成“i”，这看起来很合理，对吧？

字符编码的巨大容量，也带来了巨大的灾难潜力

Unicode 中的大小写映射碰撞是一种业务逻辑缺陷，其核心可能导致未受双重身份验证（2FA）保护的账户被接管。为了说明该漏洞，让我们看一个真实代码片段中的示例：

app.post(/api/resetPassword, function (req, res) {
  var email = req.body.email;
  db.get(SELECT rowid AS id, email FROM users WHERE email = ?, [email.toUpperCase()],
      (err, user) => {
          if (err) {
              console.error(err.message);
              res.status(400).send();
          } else {
              generateTemporaryPassword((tempPassword) => {
                  accountRepository.resetPassword(user.id, tempPassword, () => {
                      messenger.sendPasswordResetEmail(email, tempPassword);
                      res.status(204).send();
                  });
              });
          }
      });
});

其逻辑大致如下：

1. 接收用户提供的电子邮件地址，并将其转换为大写以保持一致性
2. 检查该电子邮件地址是否已存在于数据库中
3. 如果存在，则设置一个新的临时密码（顺便说一下，这不是最佳实践。应该使用带有令牌的链接来启用密码重置）
4. 然后将包含临时密码的电子邮件发送到第 1 步中获取的地址（由于多种原因，这是一种非常糟糕的做法。天哪。）

让我们看看原始博文中提供的示例会发生什么，其中用户请求重置电子邮件 John@GıtHub.com（注意土耳其语中无点 i）的密码：

1. 逻辑将 John@Gıthub.com 转换为 JOHN@GITHUB.COM
2. 它在数据库中查找该地址并找到用户 JOHN@GITHUB.COM
3. 它生成一个新密码并将其发送到 John@Gıthub.com

请注意，此过程最终会将高度敏感的电子邮件发送到错误的地址。糟糕！

如何驱除这个 Unicode 恶魔

这一特定漏洞的有趣之处在于，有多个因素导致了它的存在：

1. 实际的 Unicode 转换行为
2. 确定所用电子邮件地址的逻辑，即使用用户提供的电子邮件地址，而不是数据库中已有的地址。

理论上，正如 Wisdom 的博文中所指出的，你可以通过两种方式解决这个问题：

1. 通过Punycode 转换
2. 将电子邮件转换为 ASCII；使用数据库中的电子邮件地址，而不是用户提供的地址

在加固软件时，最好不要抱有侥幸心理，应尽可能多地部署防御层。据我们所知，可能还存在其他利用此编码的方法——只是我们尚未发现。任何能降低风险并关闭攻击者可能利用的漏洞的行为都是有价值的。

准备好亲自尝试了吗？

大多数开发人员都知道数据泄露对业务不利。然而，具备安全意识的工程师是应对日益增长的漏洞、违规和网络安全问题的有力解药。

是时候将你的安全编码和意识提升到新水平了。在沉浸式、安全的模拟环境中体验此 GitHub 漏洞，亲眼见证糟糕代码在前端和后端环境中的影响。攻击者占据优势，让我们通过白帽反击来拉平竞争环境，运用真正的技能进行防御。