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

相关文章

Springboot3统一返回类设计全过程(从问题到实现)

《Springboot3统一返回类设计全过程(从问题到实现)》文章介绍了如何在SpringBoot3中设计一个统一返回类,以实现前后端接口返回格式的一致性,该类包含状态码、描述信息、业务数据和时间戳,... 目录Spring Boot 3 统一返回类设计:从问题到实现一、核心需求:统一返回类要解决什么问题?

maven异常Invalid bound statement(not found)的问题解决

《maven异常Invalidboundstatement(notfound)的问题解决》本文详细介绍了Maven项目中常见的Invalidboundstatement异常及其解决方案,文中通过... 目录Maven异常:Invalid bound statement (not found) 详解问题描述可

idea粘贴空格时显示NBSP的问题及解决方案

《idea粘贴空格时显示NBSP的问题及解决方案》在IDEA中粘贴代码时出现大量空格占位符NBSP,可以通过取消勾选AdvancedSettings中的相应选项来解决... 目录1、背景介绍2、解决办法3、处理完成总结1、背景介绍python在idehttp://www.chinasem.cna粘贴代码,出

SpringBoot整合Kafka启动失败的常见错误问题总结(推荐)

《SpringBoot整合Kafka启动失败的常见错误问题总结(推荐)》本文总结了SpringBoot项目整合Kafka启动失败的常见错误,包括Kafka服务器连接问题、序列化配置错误、依赖配置问题、... 目录一、Kafka服务器连接问题1. Kafka服务器无法连接2. 开发环境与生产环境网络不通二、序

SpringSecurity中的跨域问题处理方案

《SpringSecurity中的跨域问题处理方案》本文介绍了跨域资源共享(CORS)技术在JavaEE开发中的应用,详细讲解了CORS的工作原理,包括简单请求和非简单请求的处理方式,本文结合实例代码... 目录1.什么是CORS2.简单请求3.非简单请求4.Spring跨域解决方案4.1.@CrossOr

nacos服务无法注册到nacos服务中心问题及解决

《nacos服务无法注册到nacos服务中心问题及解决》本文详细描述了在Linux服务器上使用Tomcat启动Java程序时,服务无法注册到Nacos的排查过程,通过一系列排查步骤,发现问题出在Tom... 目录简介依赖异常情况排查断点调试原因解决NacosRegisterOnWar结果总结简介1、程序在

解决java.util.RandomAccessSubList cannot be cast to java.util.ArrayList错误的问题

《解决java.util.RandomAccessSubListcannotbecasttojava.util.ArrayList错误的问题》当你尝试将RandomAccessSubList... 目录Java.util.RandomAccessSubList cannot be cast to java.

Apache服务器IP自动跳转域名的问题及解决方案

《Apache服务器IP自动跳转域名的问题及解决方案》本教程将详细介绍如何通过Apache虚拟主机配置实现这一功能,并解决常见问题,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,... 目录​​问题背景​​解决方案​​方法 1:修改 httpd-vhosts.conf(推荐)​​步骤

java反序列化serialVersionUID不一致问题及解决

《java反序列化serialVersionUID不一致问题及解决》文章主要讨论了在Java中序列化和反序列化过程中遇到的问题,特别是当实体类的`serialVersionUID`发生变化或未设置时,... 目录前言一、序列化、反序列化二、解决方法总结前言serialVersionUID变化后,反序列化失

C++ 多态性实战之何时使用 virtual 和 override的问题解析

《C++多态性实战之何时使用virtual和override的问题解析》在面向对象编程中,多态是一个核心概念,很多开发者在遇到override编译错误时,不清楚是否需要将基类函数声明为virt... 目录C++ 多态性实战:何时使用 virtual 和 override?引言问题场景判断是否需要多态的三个关