« LoadLibrary 无法加载 DLL 的 bug 处理 | 返回首页 | Lua 5.4 的改进及 Lua 的版本演进 »

为什么用本地程序通过本地端口做第三方服务认证是不安全的

今天有同事吐槽钉钉的 windows 客户端做第三方服务权限认证的流程,人机交互方面远没有 qq 好用。

我说,通过一个普通权限的本地程序做统一认证,其实是很容易出安全漏洞的,小心点比较好。一般来说,这个在操作系统层面支持会比较安全,就像 windows 的 UAC 。这种通常是第三方应用向服务器发一个认证请求,然后服务器下转发到本地客户端,然后客户端弹出一个确认窗口,经过用户确认以后,再经由第三方服务器下发给那个第三方客户端。

这里有个安全隐患就是,如果这个弹出窗口不是操作系统级别支持的话,在 windows 下很容易被普通权限的同级程序拦截。当然也不是完全没有办法。比如预留一个用户认可的信息展示,好像信用卡那样的安全识别码;我没用过 qq ,听说 qq 是用用户自己的头像做防伪确认的。

不过,这套流程做起来比较麻烦,开放个第三方使用的话,需要第三方客户端/服务器都遵循一定的协议来做。而且第一次需要做一次账号绑定,需要用户在第三方应用里输入一次自己的 qq 号,或在 qq 中输入一次第三方账号。windows 下可以先用 FindWindow 找到 qq 客户端的窗口,然后用一个自定义消息把一个 token 或第三方的账号信息发过去,完成握手。

说到这里,同事说,qq 的那套似乎没那么复杂,好像是走的本地端口。我先想说不至于吧,但是似乎每次遇到安全问题,我都会高估腾讯的产品设计人员的安全意识下限。腾讯系产品的用户权限大量被盗用似乎在黑产链上不足为奇。

我的机器上没有安装 qq ,不过我从网上搜到了这个:QQ快速登录的实现原理 。果然,qq 客户端在本地监听了 4300 端口,然后用 http 协议做的第三方认证。甚至都不是 https 。

如果还不确认,可以 ping 一下文中那个地址 localhost.ptlongin2.qq.com 解析出来就是 127.0.0.1 。

为什么这是相当不安全的?

因为本地端口是无法被操作系统权限管理的,也就是防火墙 uac 这些都无法警告和限制你有一个不相关的应用程序正在调用你的认证程序( qq 客户端)。如果用本地管道可能好点,在 linux 下可以通过文件权限控制来限制,不知道 windows 下是否能做到;但本地 socket 端口肯定是做不到权限控制的。

过去 windows 下非系统层的窗口不需要什么权限就可以被平级的程序拦截,现在不知道会不会好点。

即使认证窗口未被拦截,因为这里是不经过服务器,第三方应用根本不需要由腾讯官方授权,也不需要独立授权的证书,伪造一个请求过于容易。弹出的认证窗口上也没有说明这次认证申请的是哪些权限。这样,360 或类似竞争对手公司只要能安装一个客户端程序到用户的机器上,而用户开着 qq ,就能轻易获得用户的 qq 权限了。


如果走服务器认证的话,我认为可以把本地端口用于两个本地应用程序做绑定交互,简化绑定流程。这样安全危害小的多。因为绑定流程只用做一次,且可以用更安全(但繁琐)的程序。

Comments

跟TX反馈一下啊,

我只知道我的Steam账号(绑定的QQ邮箱且邮箱有二级密码)

最近被吃鸡黑产团队 把我的账号盗用了。在我修改了QQ密码 和 邮箱二级密码后,黑客仍然进入了我的邮箱,并删除了Steam相关通知邮件。

可见QQ的安全体系...

窗口拦截重要吗?
端口保护重要吗?
是不是你想多了?

http请求只为了获取用户id类型的信息,且是本地的,没有问题。
真正的登录还需要手机扫描确认或账号密码登录,这是难以被第三方应用利用的
另外这样的设计还把这种不重要的请求让用户端分担了,很妙。
这样设计方便,合理,安全
所以,真的只是客户端在进行认证吗?

小站若干年前一个需求:qq在线客户端在线用户出弹框提示使用qq登录。调研发现官方未公开相关接口,也发现了使用QQ快速登录原理,当然最后未利用。刚又测试了一波:使用了 https,端口 4303 (OSX)。

火钳刘明,党性相当正确。23333

Post a comment

非这个主题相关的留言请到:留言本