Question

我在考虑REST web Service API的安全性，并决定看看其他大型服务以及它们是如何实现的。作为一个例子，我决定研究Twitter的OAuth。看完初学者指南后，我有点困惑和震惊。

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

让我们以领英为例。他们在自己的表单中请求你的gmail用户名和密码，而你不知道他们将如何使用它。他们可以窃取它并存储在他们的数据库中，他们可以用它对gmail进行OAuth（他们不会在gmail的页面上显示他们请求的访问类型），他们可以对这些信息为所欲为。

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

顺便说一句，OAuth协议本身存在一些安全缺陷：（http://oauth.net/advisories/2009-1/），我很确定还有更多，但没有人愿意找到它们。

Answer 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的流程如下：应用程序向提供程序请求一个请求令牌，告诉它想要访问的所有内容。提供程序发布临时未授权令牌，此时客户端可以将用户发送给提供程序以授权该令牌。用户使用其用户名和密码登录提供商的网站，然后授予或拒绝访问。然后，提供程序使用验证器字符串重定向回来，该字符串允许网站升级到授权访问令牌。所有这些交互都已签名。如果其中任何一个签名都不匹配，则提供程序将拒绝该请求。用户可以随时撤销任何令牌，从而取消客户端访问其帐户的能力。

有许多协议的安全注意事项，但如果你真的阅读了这份列表，它本质上是影响互联网上几乎每个网站的安全问题的相同列表。这些安全注意事项都是众所周知的。据我所知，目前还没有针对正确解决所有这些安全问题的提供商的已知可利用攻击思考。

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

Answer 2

听起来你对什么是不安全的感到困惑。据我所知，如果实现得当，OAuth协议本身是安全的。只是它很容易实现不当，用户会感到困惑，因为他们并不真正理解自己在做什么。

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

还有一个问题是，相信谷歌会正确地告诉我请求访问的内容和用户。如果我不相信他们会这么做，我就不应该使用OAuth。

友情链接