OAuth 不安全还是我不明白？

Posted 2023-02-19

【中文标题】OAuth 不安全还是我不明白？

【英文标题】：OAuth is not secure or I didn't understand it?

【发布时间】：2011-06-26 21:57:39

【问题描述】：

我正在考虑我的 REST Web 服务 API 的安全性，并决定看看其他大型服务以及它们是如何做到的。作为一个例子，我决定研究 Twitter 的 OAuth。看完新手指南后，我有点困惑和震惊。

据我了解，对用户进行身份验证并向用户展示消费者需要什么样的访问权限（例如，它希望对特定资源具有只读访问权限）是服务提供者的责任。但是我看到服务提供商没有告知用户消费者需要什么类型的访问（甚至现在显示消费者的身份）。问题的第二部分是消费者可以在 IFrame 中显示他自己的自定义提供者服务身份验证表单，并且只是隐藏访问详细信息，他们可以窃取您的密码，或者请求无限制地访问您的资源，他们基本上可以为所欲为，欺骗用户的方法有很多。

让我们以 LinkedIn 为例。他们在自己的表单中请求您的 gmail 用户名和密码，而您不知道他们将如何使用它。他们可以窃取它并将其存储在他们的数据库中，他们可以使用它对 gmail 进行 OAuth（并且他们不会向 gmail 的页面显示他们请求的访问类型的信息），他们可以对这些信息做任何他们想做的事情。

我想说的并不是 OAuth 通信协议不安全，而是有很多方法可以不当使用它来欺骗用户并获取他的凭据。

顺便说一句，OAuth 协议本身存在一些安全漏洞：(http://oauth.net/advisories/2009-1/)，我敢肯定还有更多，但没人关心。

【问题讨论】：

如果服务在表单中请求您的用户名和密码，则不是 OAuth。事实上，这正是 OAuth 旨在解决的模式。

@BobAman：就 OAuth 不涉及身份验证而言，这不是 OAuth，但他们可以使用用户名|密码 from from 在服务提供商站点上代表 ob 用户进行身份验证，并获取 OAuth 授权令牌。所以在掩护下，它可能是 OAuth bot，而不是它应该的样子。

【参考方案1】：

我会说“你不明白”。 （为您辩护，很少有人这样做。）

让我们明确一点：您所指的会话固定攻击影响了 OAuth 1.0，但在 OAuth 1.0a 中得到了解决，变成了RFC 5849。 OAuth 1.0 没有主要的实施者——主要的实施者要么实施了 OAuth 1.0a/RFC 5849，要么实施了 OAuth 2.0 草案之一。

关于用户名/密码反模式，OAuth 1.0a 没有提供一种机制来交换用户名和密码以获取访问令牌。 OAuth 2.0 可以，但仅用于支持已安装的应用程序。请记住，如果确实需要，已安装的应用程序可以简单地记录（或类似的）。在安全性方面，如果应用程序已经在客户端机器上本地运行并且未经过沙箱处理，那么所有的赌注都将失败。但这实际上与您所说的情况截然不同。 OAuth 1.0a 和 OAuth 2.0 中的 Web 应用程序从不接触用户名和密码。

OAuth 1.0a 的流程是这样的：应用程序向提供者请求一个请求令牌，告诉它它想要访问的所有内容。提供者发布临时未授权令牌，此时客户端可以将用户发送给提供者以授权该令牌。用户使用他们的用户名和密码登录提供商的站点，然后授予或拒绝访问。然后，提供者使用允许站点升级到授权访问令牌的验证字符串重定向回来。所有这些交互都是签名的。如果其中任何一个签名都不匹配，则提供商将拒绝该请求。并且用户可以随时撤销任何令牌，从而消除客户访问其帐户的能力。

该协议有许多security considerations，但如果您实际阅读该列表，它基本上是影响互联网上几乎每个站点的安全问题列表。这些安全考虑都是众所周知的并且很好理解。据我所知，目前还没有针对提供商的已知可利用攻击能够正确解决所有这些安全问题。

重点是，使用 OAuth 1.0a 或 OAuth 2.0 授权第三方比使用任何替代方案更安全。如果您对这些感到不舒服，解决方案很简单：不要授权第三方访问您的帐户。您可能不想这样做的原因肯定有很多。

【讨论】：

“它基本上是影响互联网上几乎每个站点的安全问题列表。”我同意这一点。我预计 OAuth 会更好，但它并没有解决或试图解决当前的网络“安全考虑”。我希望它是一个复杂的安全系统，可以解决服务器真实性、欺骗等问题，但这不是所有常见的网络安全问题，但事实并非如此。

魔法子弹不存在。没有完美的安全性，使用 OAuth 肯定不会使某些东西变得安全。它的作用是消除对特定不安全反模式的需求，即将用户名和密码公开给第三方作为授权授予的一种形式。批评规范未能实现它没有尝试实现和不可能实现的东西，即使它正在尝试也有点奇怪。

我认为 OP 是在说您可以打开一个带有假登录面板的弹出窗口并以这种方式窃取某人的密码。我猜是一种网络钓鱼攻击。如果用户不检查地址栏，他们就不会更聪明，而且几乎任何带有 google 或 facebook 字样的 URL 对用户来说都可能看起来是合法的。

【参考方案2】：

听起来您对什么不安全感到困惑。据我了解，如果实施得当，OAuth 协议本身是安全的。只是很容易实施不当，用户会因为不真正了解自己在做什么而感到困惑。

例如，LinkedIn 所做的一切都是错误的。我永远不会以这种方式向他们提供我的 gmail 帐户信息。为了让我提供我的 gmail 帐户信息，我坚持要看到我的浏览器正在使用 Google 的 SSL，因此页面的根框架来自 Google。

然后是信任 Google 能够正确告诉我正在请求什么访问权限以及由谁请求的问题。如果我不相信他们会这样做，我就不应该使用 OAuth。

【讨论】：

如果您不信任 Google 可以做到这一点，那么您一开始就不应该信任他们提供您的数据 ;-)

@Joachim，Google 是一个拥有庞大代码库的大型组织。相信 gmail 可以保证您的数据安全可能是合理的，但不相信 Google 的其他部分可以提供清晰且不可欺骗的 UI。也就是说，OAuth 人员知道如何设计安全协议。想出一个 UI 来让来自不同文化的不同用户清楚地知道他们授予什么权限，这个问题仍然是一个开放研究的主题。