这几天在做微信公众号的网页授权,发现一个惊天秘密,不知道是不是算是个秘密,搜了下发现没有人说这种事情,所以发出来看看是不是我的个例。
UPDATE:下班前发的之前的旧主题,没想到发出来格式和我写的完全不一样,想编辑当时赶着回家就没弄,结果现在不能编辑了,只好把格式正确的重新发一遍了,已经看过挫格式的版本的辛苦你们了,此版本除了格式外,就是最后加了一些感想和疑问,其他没了,看过旧版本的可以直接跳到最后看附加的感想和疑问:
我先说下涉及的几个节点:
https://api.weixin.qq.com/sns/oauth2/
)( HTTPS )事件流程如下:
D
|FORM POST
(A)
|HEAD LOCATION
|其中带了 URL,此 URL 为服务器生成每次不同,位于 A 下的地址
(C)
|微信认证成功
|HEAD LOCATION
|这个过程微信服务器带了 CODE 然后回调 URL
(A)
|根据 CODE 获取 AccessToken 及 openid,此为服务器通过直接通信 C 获取
|为了安全,保存了 openid 产生了随机 TOKEN
|HEAD LOCATION
B
整个过程结束,本来很简单的事情。A 一开始不是 HTTPS 的,后来我为了安全想要将 A 部署成 HTTPS,配置证书的时候查看了下 Apache 日志,这一看不要紧,发现了惊天大秘密。
当我进行过上述过程后,(A)生成的 URL 会被不明来历的(E)调用多次,请注意,这里 URL 是(A)每次生成的,里面带有随机串,而且这个地址直接通过客户端 REDIRECT LOCATION 到(C),这个过程都是 HTTPS 的,但是就算是这样的过程,仍然会有人知道这个地址是什么,这是在 iOS 的微信客户端里面发生的事情,区别是(E)使用的是 URL 原始地址,而不是带了 CODE 的(C)的回调地址,也就是我传递给(C)的 redirect_uri 参数,这个参数是绝对不应该被任何人知道的,但就是被知道了。这种调用会发生 1-2 次,经过多次测试只发现了最多 2 次,不知道是否还有更多次,使用的是不同的 IP 和多种 Agent
怪事还有呢,这同时还会有很多(E)访问 B 的回调地址,也就是带了(A)生成的 TOKEN 的地址,当然了这个过程是不加密的,也没啥好说的,但同样证明了数据监听的存在,至少在电信的链路层有监听。
我不知道这个事情大家有没有遇到过,所以在这里问问大家。
(E)的 ip 列表和 agent 如下:
101.226.33.223 - - [17/May/2017:17:44:20 +0800] "GET /test.php?token=a8312b4a-94de-4e8e-a2c6-5cd0401df139&type=wxOid HTTP/1.1" 200 942 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 10_2_1 like Mac OS X) AppleWebKit/602.4.6 (KHTML, like Gecko) Mobile/14D27 MicroMessenger/6.5.5 NetType/WIFI Language/en"
101.226.99.197 - - [17/May/2017:17:44:22 +0800] "GET /test.php?token=a8312b4a-94de-4e8e-a2c6-5cd0401df139&type=wxOid HTTP/1.1" 200 942 "" "Mozilla/5.0 (iPhone; CPU iPhone OS 8_4 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12H143 Safari/600.1.4"
101.226.33.237 - - [17/May/2017:18:30:05 +0800] "GET /test.php?token=28a02056-6092-4f15-a38d-501400aa1fde&type=wxOid HTTP/1.1" 200 942 "" "Mozilla/5.0 (iPhone; CPU iPhone OS 8_4 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12H143 Safari/600.1.4"
101.226.51.227 - - [17/May/2017:18:31:05 +0800] "GET /test.php?token=293c9baa-8866-45d5-813d-b7845c4702df&type=wxOid HTTP/1.1" 200 942 "-" "Mozilla/5.0 (Linux; Android 6.0.1; OPPO R9s Build/MMB29M) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/37.0.0.0 Mobile MQQBrowser/6.9 TBS/036906 Safari/537.36 MicroMessenger/6.5.4.1000 NetType/4G Language/zh_CN"
180.163.2.118 - - [17/May/2017:18:31:08 +0800] "GET /test.php?token=293c9baa-8866-45d5-813d-b7845c4702df&type=wxOid HTTP/1.1" 200 942 "" "Mozilla/5.0 (iPhone; CPU iPhone OS 8_4 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12H143 Safari/600.1.4"
101.226.66.172 - - [17/May/2017:18:31:05 +0800] "GET /api/v1/weixin/code?key=4d77d444-a07d-4c12-81b2-704f7959c4f1&type=oid HTTP/1.1" 404 3267 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36 MicroMessenger/6.5.2.501 NetType/WIFI WindowsWechat QBCore/3.43.27.400 QQBrowser/9.0.2524.400"
61.151.226.189 - - [17/May/2017:18:31:07 +0800] "GET /api/v1/weixin/code?key=4d77d444-a07d-4c12-81b2-704f7959c4f1&type=oid HTTP/1.1" 404 3571 "" "Mozilla/5.0 (iPhone; CPU iPhone OS 8_4 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12H143 Safari/600.1.4"
101.226.65.105 - - [17/May/2017:18:36:02 +0800] "GET /api/v1/weixin/code?key=2e3e977a-2009-4414-86c7-f3ceef4e5d8f&type=oid HTTP/1.1" 404 3535 "" "Mozilla/5.0 (iPhone; CPU iPhone OS 8_4 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12H143 Safari/600.1.4"
这种情况其他人遇到过吗?或者你们可以看看你们的微信认证服务器是不是也有这种问题存在。刚才想了下,这个事情应该是发生在客户端的网关这边,因为服务器间的直接 HTTP/HTTPS 行为都没有被重复发送过。
如果真的是在电信网关做的 SSL 中间人攻击,不管是为了收集信息做坏事也好,还是为了监控信息也好。国内的 HTTPS 环境根本没有信任可言啊,感觉除了用 VPN 能安全点,在这样的基础环境下信息安全根本就是扯淡啊。
1
kmahyyg 2017-05-18 00:11:31 +08:00 via Android
mitn 目前没遇到 遇到过移动的 replay attack
|
4
zoues 2017-05-18 08:36:27 +08:00 via iPhone
中间有 HTTP 的过程
|
5
yushiro 2017-05-18 09:24:06 +08:00 via iPhone
看了好几遍,也许理解了 lz 的描述。
1、通篇没有看到有提到 state 参数,不知道楼主是否用到了。 2、看似 A 站是负责所有微信授权的,那为什么要暴露给用户 D,我以为的流程不应该是 D-》 B ( B-》 A-》 B )-》 D,拿到微信授权 url 的嘛。等到授权成功,还是从 B 向 A 发起请求,这个过程 A 对用户是完全透明的,AB 之间可以内网通讯。 3、“权鉴代理认证”是指 B 访问 A 需要的特殊认证,不通过的话 A 就不会被任何人调用?看日志这样的格式,我随便自己组几个 guid 发到 A,是否也能真实的产生结果? |
7
sxpcrazy OP @zoues 中间的 A C 的跳转都是 HTTPS 的,理论上不应该被任何除了客户端和服务器端的第三方知道通讯内容。
|
8
sxpcrazy OP @yushiro
1、A 生成的给微信的 redirect_url 里面已经带了类似 state 参数的随机字符串,并且用过一次就失效了,所以 E 的攻击对我并没有什么用处,我只是觉得这个现象太不正常了,看看其他人有没有遇到过,最好是有人知道是什么原因造成的,如果真的是 HTTPS 被中间人攻击泄露内容,这个网络环境 TTMD 差了。 2、A 比如暴露给 D 的原因是,微信只允许一个域名可以进行网页授权,授权必须通过微信客户端内部访问 C 来做到,C 也只能跳转到 A,这是 OAuth2 基本的规则,但我们的业务会有很多域名,不能每个都去申请新的公众号,所以用 A 来做统一的网页授权再跳回到 B 业务。 3、B 访问 A 是通过 A 带回来的 TOKEN,相当于一个临时密钥,每一个密钥只对应唯一的一次鉴权,使用一次立即失效,随便自己组的 UUID 在 A 并不存在,所以只有 404,日志里面我已经将我自己的 IP 日志部分去掉了,因为我自己是第一次访问,都是 200 成功的,后续的非法请求全部失败了。 |
9
sxpcrazy OP 这里还真是冷清啊,没人关注信息安全吗?难道这问题都没人遇到过?我发现只要不做微信认证,做其它的访问都不会有 replay attack,难道是 微信 里面的搞得鬼?
|
10
nmdx 2017-11-26 01:30:40 +08:00 via iPhone
忽然看到这个主题。。。E 是微信强制转码入口。。每个在微信发来的白名单以外的链接都会被强 x
|