关于国内云服务器做微信认证全程 HTTPS 的情况下，数据仍然泄露，这种情况大家遇到过吗？（新版本，格式正确版本）

[sxpcrazy]

这几天在做微信公众号的网页授权，发现一个惊天秘密，不知道是不是算是个秘密，搜了下发现没有人说这种事情，所以发出来看看是不是我的个例。

UPDATE:下班前发的之前的旧主题，没想到发出来格式和我写的完全不一样，想编辑当时赶着回家就没弄，结果现在不能编辑了，只好把格式正确的重新发一遍了，已经看过挫格式的版本的辛苦你们了，此版本除了格式外，就是最后加了一些感想和疑问，其他没了，看过旧版本的可以直接跳到最后看附加的感想和疑问：

我先说下涉及的几个节点：

• A:我在阿里云上的网站，主要用来给自己的服务做授权代理。（ HTTPS ）
• B:我在阿里云上的网站，业务网站，通过调用 A 获得用户 openid 来做用户身份认证。（ HTTP ）
• C:腾讯微信鉴权网站，参见：微信文档->微信网页授权（https://api.weixin.qq.com/sns/oauth2/）（ HTTPS ）
• D:用户
• E:恶意访问者（目前不明身份，只知道地址全部来自上海电信，去 abuseipdb.com 搜了下，大部分都有被报告过）

事件流程如下：

1. D--->B 进行业务请求，其中页面上有按钮进行身份认证，也就是登录
2. 进行鉴权代理认证，A 认证成功会带一个 TOKEN 回到 B，B 会使用 TOKEN 去 A 获取 openid

 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 能安全点，在这样的基础环境下信息安全根本就是扯淡啊。

[kmahyyg]

mitn 目前没遇到 遇到过移动的 replay attack

[sxpcrazy]

@kmahyyg 也是 HTTPS 连接的情况？能具体说说嘛？

[imn1]

/t/176429

[zoues]

中间有 HTTP 的过程

[yushiro]

看了好几遍，也许理解了 lz 的描述。
1、通篇没有看到有提到 state 参数，不知道楼主是否用到了。
2、看似 A 站是负责所有微信授权的，那为什么要暴露给用户 D，我以为的流程不应该是 D-》 B （ B-》 A-》 B ）-》 D，拿到微信授权 url 的嘛。等到授权成功，还是从 B 向 A 发起请求，这个过程 A 对用户是完全透明的，AB 之间可以内网通讯。
3、“权鉴代理认证”是指 B 访问 A 需要的特殊认证，不通过的话 A 就不会被任何人调用？看日志这样的格式，我随便自己组几个 guid 发到 A，是否也能真实的产生结果？

[sxpcrazy]

@imn1 那个主题的情况和我的不太一样，毕竟他是存在外部链接的，而且最后也没讨论出什么结果。

[sxpcrazy]

@zoues 中间的 A C 的跳转都是 HTTPS 的，理论上不应该被任何除了客户端和服务器端的第三方知道通讯内容。

[sxpcrazy]

@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 成功的，后续的非法请求全部失败了。

[sxpcrazy]

这里还真是冷清啊，没人关注信息安全吗？难道这问题都没人遇到过？我发现只要不做微信认证，做其它的访问都不会有 replay attack，难道是 微信 里面的搞得鬼？

[nmdx]

忽然看到这个主题。。。E 是微信强制转码入口。。每个在微信发来的白名单以外的链接都会被强 x