OAuth 的权限问题与信息隐忧

2024-03-03 15:58

本文主要是介绍OAuth 的权限问题与信息隐忧,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

http://www.geekpark.net/read/view/156033

OAuth 的权限问题与信息隐忧

 

http://www.geekpark.net/read/view/173252
如何看待第三方登录?

[核心提示] 以 QQ 登陆和微博登陆为代表的“一键登陆”背后不仅仅是登陆这么简单,它还默认获取了你的其他隐私资料和账号的部分使用权限,我们在享受便利的同时一定不要忘记保护好我们的个人信息安全。

去年3Q大战之后,开放几乎成为了最热的词汇,随后的国内互联网看似进入了开放平台的“蜜年”,各种基于开放平台的应用和社会化登录也随之出现。

将自身的产品和服务与大网站平台对接,不仅能省去注册等繁琐工作,不用为储存和传输大量的用户账号信息而烦恼,还可以迅速的带来流量、用户资源,并得到更好的推广。而对于平台来说通过 API 支持协议可以得到很多的应用接入,可以为用户提供更多更好的服务。这对开发者和平台提供商来说是双赢的局面。因此,QQ 登录、各种微博登录和 SNS 登陆也似乎成为了第三方网站或应用的必备按钮。(在昨天腾讯宣布其QQ登录已经成为国内最大第三方帐号登录体系。)

本来利用已有的账号登陆这些第三方网站和应用是一件好的事情,因为从体验上来说可以方便用户,但是国内这些“一键登陆”真的是用户想的那样“一键登陆”吗?我们看到一个网站就用我们的账号登陆难道没有隐患吗? 这些”登陆“的背后的关键是什么?

如果你有够细心的话会发现所有登陆基本都是弹出一个对应对话框,其地址栏中也都会包含有“OAuth”字样。这说明,其当前采用的是 OAuth 协议。在目前,无论是国外还是国内,绝大部分都是采用 OAuth 协议来完成在第三方网站或应用的登陆的。

OAuth 是什么?它有什么优点呢?为什么都采用 OAuth?

OAuth(开放授权)是一个开放标准 ,允许用户让第三方应用访问该用户在某一网站上存储的私密的资源(如照片,视频,联系人列表),而无需将用户名和密码提供给第三方应用。via 维基百科

OAuth 的权限问题与信息隐忧
OAuth 的权限问题与信息隐忧

OAuth 的优点

OAuth 不会使第三方网站或应用接触到用户的帐号信息(如用户名与密码),授权后的 http 通信中也不再传输用户信息而是以数字签名和访问令牌(Access Token)取代,即使截到数据包,也无法还原出用户的登录信息。这是OAuth 最大的优点,也是它得以逐渐成为现在通用的授权标准的原因。

OAuth 被普及的原因

对用户来说方便、安全;对中小第三方网站和应用来说,OAuth 可以使它们能够得到用户基本信息外的其他信息资料和账户部分使用权限;对大网站平台来说,OAuth 可以完美的解决用户的账户安全和开发者授权的平衡问题。因此 OAuth 协议确定后就获得了包括国外 Twitter、Facebook 和 Google 等认可,之后在国内也得到了有效跟进。

OAuth 授权的信息隐患

凡是只有其利就有其弊,OAuth 也不例外。为什么在安全上看似完美无缺的 OAuth 都有信息隐患呢?

1. 被滥用了的 OAuth 授权

OAuth 是一个授权(authorization)协议而不是认证(authentication)协议,因此,对于 OAuth 来说最大的信息隐患就是其本身。

OAuth 提供的是权限分配而非认证。在国内大多数网站的一键登陆根本没有去区分认证和授权 ,全部混淆为授权。本身用类似 OpenID 的简单认证即可完成的事情却非要走授权。而一键登陆在给用户带来便利的同时也带来了另一个弊端:用户变得越来越不在意自己的账号。因为 OAuth 协议本身的安全给了我们一种假象:别人获取不到我的账号密码,所以我的账户很安全。我们要明白,授权本身的实质相当于系统为第三方网站/应用开了一个后门,而你的授权就是允许它们可以走后门进来获取你的隐私资料和使用权限。

打个比方就是,虽然它们不知道你家的锁长什么样,也没有你家的钥匙,但是人家就是能进得去你家,还可以看你家的电话簿,用你家的电话给你的亲朋好友打电话等。很多其实扮演的只是抄水表的角色,在门外瞅一眼即可,但是偏偏国内那些平台们把水表安到了你家里面,这样很多抄水表的就可以打着抄水表的借口从后门去你家向你的亲朋好友宣传它水表抄的好,想继续去你亲朋好友家抄水表。

譬如一些小游戏和星座信息之类的第三方网站和应用,无一例外都会要求我们授权给它们我们的好友关系、生日、相册、评论、甚至地理信息位置。对于我们来说,个人信息的安全不仅仅是我们的用户名和密码,那些“被授权”的都是信息安全的一部分,甚至是最重要的部分。前几天通过 QQ 圈子我们也了解到了这些信息有多重要。

你授权的网站/应用越多,意味着越多的网站和应用能够接触到你的账户资料并拥有部分使用权限,也意味着隐患越多。虽然它们并没有获取到的你的账户密码,虽然你之后从未登陆过或使用过它们,但是,除非你去隐藏很深的后台设置里面取消它们的权限,否则它们是一直能够接触到你的账户资料并拥有你账户的部分使用权限的。

某种程度上说,OAuth 对我们个人信息安全来说是一扇隐形的窗户,而且这个窗户还是默认永久开放的。

2. OAuth 使用的不规范

在很多时候,出问题的环节往往不是技术,而是背后使用技术的人。

1. 平台 OAuth 部署不规范

OAuth 部署是否规范,例如有无强制使用 https 加密,有无强制部署 OAuth 2.0。对移动应用的授权有无注意应用会自建浏览器,有无注意在信息回传过程中的信息防护,这些都是需要考据的问题。OAuth 协议本身没有问题,但是对协议的用途是否规范值得商榷。

事实上,各开放平台之间的技术差异很大,因此每个平台使用并不是相同版本的协议,有 OAuth 1.0、OAuth 2.0 或混合的技术体系(甚至还有继续使用不安全的 Basic Auth)。此外,如果你去翻看一下国内各个开放平台的开发文档就会发现,虽然 OAuth 整体流程大致类似,但是对于授权的定义各家有各家的标准,对待开发者的态度各不相同,对授权的限制也是各家有各家的标准 ,对用户的账号保护也是各有各的说法。

例如某家开发平台上对待涉及自身利益的时候用“严禁”“禁止”字眼,而涉及用户账号利益的时候就变成了“不应”、“不鼓励” 等字样。再例如,对未审核应用、待审核应用和未通过审核应用的限制,国内只有两家平台对使用人数进行限制外,其他各家都只是稍微限制了一下调用频率次数和不显示来源而已。

综合来看,国内的关于OAuth协议标准的实施部署是一个开发者和平台综合博弈的结果。

2. 应用开发者不自律

OAuth 的安全性相当一部分需要依靠应用开发者的高度自律,不该有的权限不去申请,但是事实并非如此。正常情况下,平时我们所用的 90% 的应用只需用只读权限即可,但是相反的是,只有 5% 的应用只拥有只读权限。对于开发者开说,尽量获取到用户账户的使用权限似乎是一种”追求“,而不管用不用得到。这不仅让人想起了 Android 移动应用上的普遍高权限。

3. 平台审核是否仔细

第三方网站或应用要接入平台需要通过平台的审核,审核是一层对开发者的把关。因为平台竞争的原因,各家审核标准并不一致,实际操作更是谁也不清楚。总体来看,强势的平台限制严格,弱势的平台因为要吸引开发者所以很多事情睁一只眼闭一只眼。

4. 用户对 OAuth 的不设防

OAuth 协议的实施很类似微软平台下软件的安装,用户经常在一步步的点击中默认”被授权“,因为国内大多数用户暂时还没有注意防护自己账户信息和权限的习惯。

我们该注意些什么?该怎么做?

1. 防止 OAuth 钓鱼登陆界面

注意观察弹出窗口是否为官方登陆域名,要谨防假冒钓鱼。

2. 授权之前的三思

在你将自己的账号权限授权给一个应用之前,先查清楚应用开发者的具体信息和他们的隐私保护条款,知道自己到底授权给了谁,到底给谁授予了哪些权限。

3. 定时清理你的第三方应用授权

要注意清理你的第三方应用授权,将那些无关紧要的或已经不再使用的第三方网站或应用取消授权,关上那扇隐形的窗户。

4.授权后注意其来源

授权第三方网站或应用后要注意查看其有没有通过官方平台的审核,如果来源显示来自”未审核应用“或类似字样后尽量先取消其授权,待审核通过后再进行授权。

未来,国内应该分区开认证和授权,给用户减少不必要的隐患,期待国内出现一个统一的OpenID(不像国外 OpenID 那样繁琐,或许类似 BrowserID 的东西),而不像现在,虽然号称一键登陆,但实际上许多第三方网站/应用在用户授权登录后,依旧有二次登录或重新注册等操作。

虽然目前这些隐患只是表现为偶尔的偷偷关注或偷偷以用户账号发一些广告,并没有爆发出严重的事件。但是想想那么多隐私信息和部分权限控制在那么多的第三方应用或平台上就有点不寒而栗的感觉。

服务的整合本来是大势所趋,也是未来方向,但是国内这些将认证和授权混为一谈的做法使得我们不仅没有更使得我们可以更方便更安全更省事的去管理,去获得服务,反而使我们的账户更加混乱,更埋下了信息安全的隐患。对此我们一定要提高警惕。

后记:在国外 OAuth 也没有太多安全可言,最近两天一个名为reference.me的社交服务就在滥用OAuth 协议,用户只要用 Google 账户授权登录就会自动向所有联系人发送邀请邮件,大家要注意。


这篇关于OAuth 的权限问题与信息隐忧的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/770123

相关文章

使用雪花算法产生id导致前端精度缺失问题解决方案

《使用雪花算法产生id导致前端精度缺失问题解决方案》雪花算法由Twitter提出,设计目的是生成唯一的、递增的ID,下面:本文主要介绍使用雪花算法产生id导致前端精度缺失问题的解决方案,文中通过代... 目录一、问题根源二、解决方案1. 全局配置Jackson序列化规则2. 实体类必须使用Long封装类3.

Idea插件MybatisX失效的问题解决

《Idea插件MybatisX失效的问题解决》:本文主要介绍Idea插件MybatisX失效的问题解决,详细的介绍了4种问题的解决方法,具有一定的参考价值,感兴趣的可以了解一下... 目录一、重启idea或者卸载重装MyBATis插件(无需多言)二、检查.XML文件与.Java(该文件后缀Idea可能会隐藏

Nginx 访问 /root/下 403 Forbidden问题解决

《Nginx访问/root/下403Forbidden问题解决》在使用Nginx作为Web服务器时,可能会遇到403Forbidden错误,文中通过示例代码介绍的非常详细,对大家的学习或者工作... 目录解决 Nginx 访问 /root/test/1.html 403 Forbidden 问题问题复现Ng

Python的pip在命令行无法使用问题的解决方法

《Python的pip在命令行无法使用问题的解决方法》PIP是通用的Python包管理工具,提供了对Python包的查找、下载、安装、卸载、更新等功能,安装诸如Pygame、Pymysql等Pyt... 目录前言一. pip是什么?二. 为什么无法使用?1. 当我们在命令行输入指令并回车时,一般主要是出现以

Nginx部署React项目时重定向循环问题的解决方案

《Nginx部署React项目时重定向循环问题的解决方案》Nginx在处理React项目请求时出现重定向循环,通常是由于`try_files`配置错误或`root`路径配置不当导致的,本文给大家详细介... 目录问题原因1. try_files 配置错误2. root 路径错误解决方法1. 检查 try_f

Python解决雅努斯问题实例方案详解

《Python解决雅努斯问题实例方案详解》:本文主要介绍Python解决雅努斯问题实例方案,雅努斯问题是指AI生成的3D对象在不同视角下出现不一致性的问题,即从不同角度看物体时,物体的形状会出现不... 目录一、雅努斯简介二、雅努斯问题三、示例代码四、解决方案五、完整解决方案一、雅努斯简介雅努斯(Janu

MySQL索引失效问题及解决方案

《MySQL索引失效问题及解决方案》:本文主要介绍MySQL索引失效问题及解决方案,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录mysql索引失效一、概要二、常见的导致MpythonySQL索引失效的原因三、如何诊断MySQL索引失效四、如何解决MySQL索引失

一文教你如何解决Python开发总是import出错的问题

《一文教你如何解决Python开发总是import出错的问题》经常朋友碰到Python开发的过程中import包报错的问题,所以本文将和大家介绍一下可编辑安装(EditableInstall)模式,可... 目录摘要1. 可编辑安装(Editable Install)模式到底在解决什么问题?2. 原理3.

Redis中的数据一致性问题以及解决方案

《Redis中的数据一致性问题以及解决方案》:本文主要介绍Redis中的数据一致性问题以及解决方案,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、Redis 数据一致性问题的产生1. 单节点环境的一致性问题2. 网络分区和宕机3. 并发写入导致的脏数据4. 持

vscode不能打开终端问题的解决办法

《vscode不能打开终端问题的解决办法》:本文主要介绍vscode不能打开终端问题的解决办法,问题的根源是Windows的安全软件限制了PowerShell的运行,而VSCode默认使用Powe... 遇到vscode不能打开终端问题,一直以为是安全软件限制问题,也没搜到解决方案,因为影响也不大,就没有管