这是一个创建于 2414 天前的主题，其中的信息可能已经有所发展或是发生改变。
同事一直强调现在用了 https 传输 openid 没有问题，还有服务器之间通过请求用 openid 获取登录 token 也没问题； 理由是这要是有问题大厂的 app 就都有问题了，你要是觉得有问题你给我抓个 openid 看看。。。 说下目前使用登录的场景： 1.app 使用微信第三方登录 2.另一个域名下有微信商城，所以微信绑定的域名填的商城的域名，用于登录的域名没有被绑定，才会出现服务器间传输 openid 获取登录 token 的情况。
对了，我说有问题之后，人家现在传输 openid 还加了个 MD5 的验证。
我已经反驳的心累了。。
 |
1
InternetExplorer 2018-04-13 11:12:24 +08:00
所以是同事觉得没问题，你觉得有问题但是不知道问题在哪里，要我们来帮你找问题反驳吗。那我觉得用了 https 是没有问题的
|
 |
2
SingeeKing 2018-04-13 11:23:46 +08:00 via iPhone
感觉确实有问题…不知道是不是我没理解
我的理解：微信可信域名绑定的 A 网站，而用户要登录的是 B 网站 首先一点：任何情况下可以单纯的通过 openid 登录都是不安全的（包括 post 来修改 openid ；包括通过前端来加密 openid 后传输；包括与 openid 对应的无使用次数限制和有效时间限制的验证 token ） 因此，如果是以下情形是安全的：用户想要登录 B，而需要通过 A 登录，登录使用微信的登录接口，验证成功后返回一个带有一次性 /短时间有效的 token 来 redirect 到 B 的登录网址；或登录成功后直接在服务器间传递（ A 服务器告诉了 B 服务器这个账号已经登录成功了）然后直接 redirect 到 B 的相关网页。 但是，如果是以下情形则是不安全的：用户想要登录 B，而需要通过 A 登录，登录使用微信的登录接口，验证成功后返回用户的 openid 或不限制时间与次数的 token，带着这个 openid/token 直接登录 B 则是危险的。 |
 |
3
spkinger OP @InternetExplorer https 当时我提供理由是如果此客户端被安装了一个监听服务器的新认证书，那么它是可以被抓包的，依据是 charles 抓 https 包就是使用的这个方式
|
 |
4
nicevar 2018-04-13 11:38:44 +08:00
如果你们用的 https 都不能保证安全了，所有的协议都要 gg 了，盯着这个 openid 还有多大意义呢？所以没必要争论了
|
|
5
InternetExplorer 2018-04-13 11:39:35 +08:00
@spkinger 看你的描述 openid 是只在服务器间传递的，这样是不会被用户伪造的。如果通过 url 跳转来传递 openid，那么抓包之后用户可以模拟你们的请求，是有可能伪造 openid 的，这样的话可以模仿微信的签名机制来验证 openid
|
|
6
nicevar 2018-04-13 11:40:55 +08:00
我见过有些公司就很搞笑，用了 https 了还要兼容 http，这样别把程序拿过来反编译修改一下请求地址，直接就裸奔了，那用 https 还有啥意义
|
 |
7
chenuu 2018-04-13 11:41:53 +08:00
|
|
8
spkinger OP @InternetExplorer 可能前面我描述有点问题，目前客户端 app 也在使用这个模式，所以我这比较担心的是客户端。
|
 |
10
justfindu 2018-04-13 14:08:00 +08:00
伪造 openid 和伪造你们自有的 uid 有什么区别? 所以我不认为传输之后有什么问题. 难道你们内部逻辑就是只要有 openid 就是合法用户?
|
|
11
spkinger OP @SingeeKing 我比较同意这位同学的，即使做什么加密，像 openid 这种长久有效的值，在接口中作为认证标记就是有问题的。就不考虑 openid 被泄露，单单重放过往的请求也能形成重放攻击。
|
|
12
spkinger OP @justfindu 可以肯定的是这个 openid 拿上来不会做认证，而是在下一步中和手机号做绑定操作，然后二次登陆时，openid 再做自动登陆用。
|
|
13
justfindu 2018-04-13 14:15:56 +08:00
@spkinger 那你们整体逻辑就不对啊, 用户微信授权只会返回一个 code, 使用 code 服务器获取用户信息(包括 openid), 应用接可以相互传递 code, 使用同一套 key 去获取用户数据. 每次用户登录都应该是获取 code, 再获取 openid 进行验证.
你们这个直接逻辑有点猛啊, 类似两套应用相互传递 uid 来证明对方给你了这个用户. |
|
14
spkinger OP @justfindu 就是你说的这个问题，我当时给改成 code 验证了，人家给我推翻改回去了，顺带还给我栽赃点别的问题，人心难料啊。。。
|
 |
15
jason19659 2018-04-13 14:21:52 +08:00
虽然每个人的 openid 都不一样。https 被劫持的概率很低。。而且微信强制要求使用 https。但是即使是强密码长时间不改也会出问题的。
|
 |
16
ebony0319 2018-04-13 14:32:28 +08:00 via Android
用 openid 登录是没有什么问题的，但是传输就有问题了。openid 一般是在服务器通过 appid 去解密对称加密获取到的，所有比较敏感。唯一不好的地方就是网页端，app 端，小程序端各自一个 openid，还有一个通过开发者平台获得的唯一 id 的概念。
|
|
17
spkinger OP @jason19659 https 确实更安全些，就是感觉绕开 oauth2.0 安全机制不使用，单单依靠 https 保证安全怪怪的
|
 |
19
mkeith 2018-04-13 15:03:39 +08:00 via iPhone
你们是要实现 sso 单点登录吧？
|
Select Language