任务简介：下一阶段以开发者为中心的安全培训

自 2015 年以来，我们一直以主动、积极的安全方法与世界各地的开发人员互动，帮助他们培养保护代码的技能，减少返工和补救工作，并希望将安全团队视为非趣味警察。

我们仍然致力于与开发人员并肩作战，保护整个银河系的代码，但现在是时候改变现状，将我们经过艰苦奋斗、具有安全意识的开发人员提升到一个新的水平了。

我们很高兴地宣布在 Secure Code Warrior 平台上发布全新功能：任务。这一全新的挑战类别是开发人员专属安全培训的下一阶段，它将用户从回忆安全知识转向将其应用于现实世界的仿真环境。这种脚手架式微学习方法可以培养与工作相关的强大安全编码技能，而且比在工作日背景下（垂直）观看无休止的培训视频更具娱乐性。

我们的第一个可玩的公开任务是模拟GitHub Unicode漏洞。它看似简单，但它是一个非常聪明的漏洞，剖析起来很有趣。安全研究员 0xsha 做了一个 全面的案例研究 介绍如何利用同样的错误通过大小写转换来利用 Django，同时还揭示了编程语言之间漏洞行为会如何变化。关于这个安全问题，还有很多东西需要发现，我们的使命是一个很好的起点。

GitHub 的正面（案例映射）冲突

在一个 博客文章 从2019年11月28日起，安全研究组织Wisdom报告了他们在GitHub上发现的一个安全漏洞。他们概述了他们如何能够利用Unicode中的案例映射冲突触发密码重置电子邮件发送到错误的电子邮件地址（或者如果我们像攻击者一样思考，则是威胁行为者选择的电子邮件地址）。

尽管安全漏洞从来都不是好消息，但戴白帽的安全研究人员如果发现代码库中可能存在可利用的错误，确实会给予一些怜悯，更不用说避免灾难的机会了。他们的博客和报告通常是很好的读物，了解新漏洞及其运作方式也很酷。

为了将安全编码能力提升到一个新的水平，它不仅可以找到常见的漏洞（尤其是任何很酷的新漏洞——我们都知道恶意威胁行为者将寻找肥沃的土壤来利用这些新技术挖掘一些数据），而且还要有一个安全的动手环境来了解如何利用这些漏洞，这非常强大。

所以，让我们这样做吧。继续阅读以了解如何利用 Unicode 中的 Case Mapping Collision，它的实时外观，以及如何树立安全研究人员的思维方式亲自尝试一下。

现在准备好迎接案例映射碰撞了吗？向上迈进：

Unicode：复杂、可无限定制，不仅仅是表情符号

“Unicode” 可能不在普通人的词典中，但是大多数人每天很有可能以某种形式使用它。如果你使用过网络浏览器、任何微软软件或发送过表情符号，那么你已经在近距离接触了 Unicode 了。它是对世界上大多数书写系统中的文本进行一致编码和处理的标准，可确保每个人都可以（数字方式）使用单一字符集表达自己。就目前而言，有超过 143,000 个字符，因此无论你使用的是冰岛语、土耳其语无点字符，还是介于两者之间的任何字符，你都能得到保障。

由于Unicode集合中的字符数量庞大，因此在许多情况下需要一种将字符转换为另一个 “等效” 字符的方法。例如，如果你将带有无点的Unicode字符串转换为ASCII，它应该直接变成 “i”，这似乎是明智的，对吧？

大量的字符编码带来了巨大的灾难可能性

Unicode 中的大小写映射冲突是 商业逻辑 漏洞的核心可能导致账户被没收 2FA 保护的账户。为了说明所讨论的漏洞，让我们在真实的代码片段中看一下这个错误的示例：

app.post (/api/resetPassword，函数（req，res）{
var email = req.body.email;
db.get（选择 rowid 作为 ID，来自用户的电子邮件，其中 email =？，[email.toUpperCase ()]，
（错误，用户）=> {
如果（错误）{
控制台错误（错误消息）；
res.status (400) .send ();
} 其他 {
生成临时密码 ((tempPassword) => {
accountRepository.resetPassword (user.id, tempPassword, () => {
Messenger.sendPasswordResetEmail（电子邮件、临时密码）；
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. 使用以下命令将电子邮件转换为 ASCII Punycode 转换
2. 使用数据库中的电子邮件地址，而不是用户提供的电子邮件地址

在强化软件方面，最好不要碰运气，尽可能多地使用防御层。据我们所知，可能还有其他方法可以利用这种编码——我们只是还没有意识到它们。为降低风险和关闭可能为攻击者打开的窗口所能做的任何事情都是有价值的。

准备好亲自尝试这个了吗？

大多数开发人员都意识到泄露的数据对企业不利。但是，具有安全意识的工程师是应对日益严重的漏洞、漏洞和网络安全问题的有力解药。

是时候将您的安全编码和感知技能提升到一个新的水平了。在身临其境的安全模拟中体验这个 GitHub 漏洞，在那里你可以看到不良代码在前端和后端环境中的影响。攻击者有优势，所以让我们平衡竞争环境，用白帽反击来运用真正的技能。