直接使用微信 openid 登录到底有没有问题,问题在哪里?

2018-04-13 10:47:46 +08:00
 spkinger

同事一直强调现在用了 https 传输 openid 没有问题,还有服务器之间通过请求用 openid 获取登录 token 也没问题; 理由是这要是有问题大厂的 app 就都有问题了,你要是觉得有问题你给我抓个 openid 看看。。。 说下目前使用登录的场景: 1.app 使用微信第三方登录 2.另一个域名下有微信商城,所以微信绑定的域名填的商城的域名,用于登录的域名没有被绑定,才会出现服务器间传输 openid 获取登录 token 的情况。

对了,我说有问题之后,人家现在传输 openid 还加了个 MD5 的验证。

我已经反驳的心累了。。

5302 次点击
所在节点    微信
20 条回复
InternetExplorer
2018-04-13 11:12:24 +08:00
所以是同事觉得没问题,你觉得有问题但是不知道问题在哪里,要我们来帮你找问题反驳吗。那我觉得用了 https 是没有问题的
SingeeKing
2018-04-13 11:23:46 +08:00
感觉确实有问题…不知道是不是我没理解
我的理解:微信可信域名绑定的 A 网站,而用户要登录的是 B 网站
首先一点:任何情况下可以单纯的通过 openid 登录都是不安全的(包括 post 来修改 openid ;包括通过前端来加密 openid 后传输;包括与 openid 对应的无使用次数限制和有效时间限制的验证 token )

因此,如果是以下情形是安全的:用户想要登录 B,而需要通过 A 登录,登录使用微信的登录接口,验证成功后返回一个带有一次性 /短时间有效的 token 来 redirect 到 B 的登录网址;或登录成功后直接在服务器间传递( A 服务器告诉了 B 服务器这个账号已经登录成功了)然后直接 redirect 到 B 的相关网页。
但是,如果是以下情形则是不安全的:用户想要登录 B,而需要通过 A 登录,登录使用微信的登录接口,验证成功后返回用户的 openid 或不限制时间与次数的 token,带着这个 openid/token 直接登录 B 则是危险的。
spkinger
2018-04-13 11:34:42 +08:00
@InternetExplorer https 当时我提供理由是如果此客户端被安装了一个监听服务器的新认证书,那么它是可以被抓包的,依据是 charles 抓 https 包就是使用的这个方式
nicevar
2018-04-13 11:38:44 +08:00
如果你们用的 https 都不能保证安全了,所有的协议都要 gg 了,盯着这个 openid 还有多大意义呢?所以没必要争论了
InternetExplorer
2018-04-13 11:39:35 +08:00
@spkinger 看你的描述 openid 是只在服务器间传递的,这样是不会被用户伪造的。如果通过 url 跳转来传递 openid,那么抓包之后用户可以模拟你们的请求,是有可能伪造 openid 的,这样的话可以模仿微信的签名机制来验证 openid
nicevar
2018-04-13 11:40:55 +08:00
我见过有些公司就很搞笑,用了 https 了还要兼容 http,这样别把程序拿过来反编译修改一下请求地址,直接就裸奔了,那用 https 还有啥意义
chenuu
2018-04-13 11:41:53 +08:00
@spkinger 如果监听证书了那就没什么安全的了.
@InternetExplorer +1
spkinger
2018-04-13 13:55:54 +08:00
@InternetExplorer 可能前面我描述有点问题,目前客户端 app 也在使用这个模式,所以我这比较担心的是客户端。
spkinger
2018-04-13 13:57:07 +08:00
@nicevar 你说的这情况我们还真存在
justfindu
2018-04-13 14:08:00 +08:00
伪造 openid 和伪造你们自有的 uid 有什么区别? 所以我不认为传输之后有什么问题. 难道你们内部逻辑就是只要有 openid 就是合法用户?
spkinger
2018-04-13 14:08:25 +08:00
@SingeeKing 我比较同意这位同学的,即使做什么加密,像 openid 这种长久有效的值,在接口中作为认证标记就是有问题的。就不考虑 openid 被泄露,单单重放过往的请求也能形成重放攻击。
spkinger
2018-04-13 14:11:38 +08:00
@justfindu 可以肯定的是这个 openid 拿上来不会做认证,而是在下一步中和手机号做绑定操作,然后二次登陆时,openid 再做自动登陆用。
justfindu
2018-04-13 14:15:56 +08:00
@spkinger 那你们整体逻辑就不对啊, 用户微信授权只会返回一个 code, 使用 code 服务器获取用户信息(包括 openid), 应用接可以相互传递 code, 使用同一套 key 去获取用户数据. 每次用户登录都应该是获取 code, 再获取 openid 进行验证.
你们这个直接逻辑有点猛啊, 类似两套应用相互传递 uid 来证明对方给你了这个用户.
spkinger
2018-04-13 14:21:45 +08:00
@justfindu 就是你说的这个问题,我当时给改成 code 验证了,人家给我推翻改回去了,顺带还给我栽赃点别的问题,人心难料啊。。。
jason19659
2018-04-13 14:21:52 +08:00
虽然每个人的 openid 都不一样。https 被劫持的概率很低。。而且微信强制要求使用 https。但是即使是强密码长时间不改也会出问题的。
ebony0319
2018-04-13 14:32:28 +08:00
用 openid 登录是没有什么问题的,但是传输就有问题了。openid 一般是在服务器通过 appid 去解密对称加密获取到的,所有比较敏感。唯一不好的地方就是网页端,app 端,小程序端各自一个 openid,还有一个通过开发者平台获得的唯一 id 的概念。
spkinger
2018-04-13 14:35:55 +08:00
@jason19659 https 确实更安全些,就是感觉绕开 oauth2.0 安全机制不使用,单单依靠 https 保证安全怪怪的
spkinger
2018-04-13 14:58:33 +08:00
@ebony0319 这个确实是,得去换个 unionid 来存。
mkeith
2018-04-13 15:03:39 +08:00
你们是要实现 sso 单点登录吧?
spkinger
2018-04-13 21:41:05 +08:00
@mkeith 因为有 app 端所以有了一整套完整的 api 接口,然后又整了个微信商城,本来微信商城可以做成静态页面+js 走接口来完成所有类似 app 的功能(或者单页面应用),然而被做成了靠后端动态生成的普通网站,然后很神奇的是还要靠后端来请求接口模拟 app 的操作。还真有点单点登录的意思。不过无关紧要了,写这代码的人觉得自己什么都对,别人提出疑问他会记仇,这两天还找茬栽赃我,心累。。。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/446466

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX