OAuth不安全或我听不懂吗? [英] OAuth is not secure or I didn't understand it?

问题描述

我当时正在考虑我的REST Web服务API的安全性，因此决定研究其他大型服务及其如何实现.例如，我决定研究Twitter的OAuth.阅读初学者指南后，我有点困惑和震惊.

I was thinking about security for my REST web Service API, and decided to take a look at others large services and how they do it. As an example I decided to study Twitter's OAuth. After reading beginners guide I'm a little be confused and shocked.

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

As I understood it's Service provider responsibility to authenticate user and to show User what kind of access consumer is demanding (for example it want's read only access to specific resource). But I saw service providers that doesn't inform user on what type of access consumer is demanding (and even now showing consumer's identity). The second part of problem is that consumer can show his own custom Provider Service Authentication form in IFrame, and just hide access details, they can just steal you password, or request unlimited access to you resources, they can do basically what ever they want, there are lot's of way to trick user.

以LinkedIn为例.他们以自己的形式要求您的Gmail用户名和密码，而您不知道他们将如何使用它.他们可以窃取并将其存储在自己的数据库中，可以对它进行OAuth到gmail(并且不向gmail的页面显示其请求访问类型的信息)，他们可以使用此信息做任何想要的事情.

As an example let's take a LinkedIn. They request your gmail username and password inside their own form, and you have no idea how they will use it. They can just steal it and store in their DB, they can OAuth with it to gmail (and they don't show gmail's page with information what type of access they request), they can do whatever they want with this information.

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

What I'm trying to say is not that OAuth communication protocol is not secure, but rather there are lot's of way to use it improperly to trick the user and get his credentials.

顺便说一句，OAuth协议本身存在一些安全漏洞:( http://oauth.net/advisories/2009-1/)，我可以肯定还有更多，但是没人愿意找到它们.

BTW there were some security flaws in OAuth protocol itself: (http://oauth.net/advisories/2009-1/) and I'm pretty sure there are more, but no one cares to find them.

推荐答案

我要说你不理解".(为您辩护，很少有人这样做.)

I'm going to go with 'You didn't understand it.' (In your defense, very few people do.)

请明确说明:您所指的会话固定攻击影响了OAuth 1.0，但已在OAuth 1.0a中得到了解决，该问题已成为 RFC 5849 .没有OAuth 1.0的主要实现者-主要实现者都实现了OAuth 1.0a/RFC 5849或他们实现了OAuth 2.0草案之一.

Let's be clear: The session fixation attack you're referring to affected OAuth 1.0, but was resolved in OAuth 1.0a, which became RFC 5849. There are no major implementors of OAuth 1.0 — the major implementors all either implemented OAuth 1.0a/RFC 5849 or they implemented one of the OAuth 2.0 drafts.

对于用户名/密码反模式，OAuth 1.0a没有提供一种机制来交换用户名和密码以获取访问令牌.OAuth 2.0可以，但仅用于支持已安装的应用程序.请记住，如果确实需要，已安装的应用程序可以简单地记录键盘记录(或类似记录).关于安全性，如果应用程序已经在本机上运行并且未在客户端计算机上进行沙盒处理，则所有赌注都将关闭.但这实际上是一个与您所谈论的完全不同的场景.OAuth 1.0a和OAuth 2.0中的Web应用程序都不会触摸用户名和密码.

As for the username/password anti-pattern, OAuth 1.0a does not provide for a mechanism to exchange a username and password for an access token. OAuth 2.0 does, but only for the purposes of supporting installed applications. Keep in mind that an installed application could simply keylog (or similar) if it really wanted to. When it comes to security, all bets are off if an application is already running natively and unsandboxed on the client's machine. But this is actually a very different scenario than what you're talking about. Web applications in both OAuth 1.0a and OAuth 2.0 don't ever touch the username and password.

OAuth 1.0a的流程如下所示:应用程序向提供者询问请求令牌，并告知它要访问的所有内容.提供者发出临时的未授权令牌，此时客户端可以将用户发送给提供者以授权该令牌.用户使用其用户名和密码在提供商站点上登录，然后授予或拒绝访问权限.然后，提供商使用验证程序字符串重定向回去，该验证程序字符串使站点可以升级到授权的访问令牌.所有这些交互都已签名.如果签名在任何一个上都不匹配，则提供者将拒绝该请求.用户可以随时撤消任何令牌，从而消除了客户访问其帐户的能力.

The flow for OAuth 1.0a goes like this: The application asks the provider for a request token, telling it all of the things it wants access to. The provider issues the temporary unauthorized token, at which point the client may send the user to the provider to authorize that token. The user logins in with their username and password on the provider's site and then either grants or denies access. The provider then redirects back with a verifier string that allows the site to upgrade to an authorized access token. All of these interactions are signed. If the signatures don't match on any of them, the provider will reject the request. And the user can revoke any token at any time, removing the client's ability to access their account.

该协议有许多安全注意事项，但如果您实际上阅读了该列表，它实际上是影响互联网上几乎每个站点的安全问题列表.这些安全注意事项都是众所周知的，并且非常容易理解.据我所知，目前尚无针对提供商的已知可利用攻击，可以正确解决所有这些安全注意事项.

There are a number of security considerations with the protocol, but if you actually read the list, it's essentially the same list of the security issues that affect almost every site on the internet. These security considerations are all very well known and very well understood. To my knowledge, there are currently no known exploitable attacks against providers that correctly address all of these security considerations.

要点是，使用OAuth 1.0a或OAuth 2.0来授权第三方，比使用其他任何一种方法都要安全得多.如果您不满意这些，则解决方案很简单:不要授权第三方访问您的帐户.当然，您可能不想这么做的原因有很多.

Point being, you are much safer using OAuth 1.0a or OAuth 2.0 to authorize a third party than with any of the alternatives. If you don't feel comfortable with these, the solution is simple: Don't authorize third parties to access your account. There certainly are plenty of reasons why you might not want to do that.

这篇关于OAuth不安全或我听不懂吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！