Ale*_*sev 15 security authentication rest authorization oauth
我正在考虑我的REST Web服务API的安全性,并决定看看其他大型服务以及他们如何做到这一点.作为一个例子,我决定研究Twitter的OAuth.阅读初学者指南后,我有点困惑和震惊.
据我了解,服务提供商有责任对用户进行身份验证并向用户显示消费者要求的访问权限(例如,它希望只读访问特定资源).但我看到服务提供商没有告知用户访问消费者要求的类型(甚至现在显示消费者的身份).问题的第二部分是消费者可以在IFrame中显示自己的自定义提供者服务身份验证表单,只是隐藏访问详细信息,他们只是窃取您的密码,或者请求无限制地访问您的资源,他们基本上可以做任何他们想要的,欺骗用户有很多方法.
举个例子,我们来看看LinkedIn吧.他们在自己的表单中请求您的gmail用户名和密码,而您不知道他们将如何使用它.他们可以窃取它并存储在他们的数据库中,他们可以将OAuth与它一起发送到gmail(并且他们不会向gmail的页面显示他们请求的访问类型的信息),他们可以使用这些信息做任何他们想做的事情.
我想说的不是OAuth通信协议不安全,而是有很多方法可以不恰当地使用它来欺骗用户并获取他的凭据.
BTW在OAuth协议本身存在一些安全漏洞:(http://oauth.net/advisories/2009-1/)我很确定还有更多,但没有人关心找到它们.
Bob*_*man 18
我要去'你不明白'.(在你的辩护中,很少有人这样做.)
让我们明确一点:您所指的会话固定攻击受影响的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来授权第三方比使用任何替代方案更安全.如果您对这些不满意,解决方案很简单:不要授权第三方访问您的帐户.肯定有很多理由你可能不想那样做.
听起来你对什么不安全感到困惑.据我了解,如果实施得当,OAuth协议本身是安全的.只是它很容易实现不当,用户感到困惑,因为他们并不真正理解他们在做什么.
例如,LinkedIn正在做的事情都是错的.我绝不会以这种方式向他们提供我的Gmail帐户信息.为了让我提供我的Gmail帐户信息,我坚持看到我的浏览器正在使用SSL与Google,因此页面的根框架来自Google.
然后是信任谷歌正确地告诉我正在请求什么访问以及由谁.如果我不相信他们这样做,我不应该使用OAuth.
| 归档时间： |
|
| 查看次数： |
11781 次 |
| 最近记录： |