今天早上我给家里三张文旅权益卡写了个预约机器人（来历写在这篇里）。为了不每次开小程序，我把它的接口摸了一遍——登录态是一个账号级的长期 token，不用微信、不用手机、不用浏览器，一个请求头就能进。
跑通的那一刻我停了一下：这个账号里，我填过姓名和身份证号。
于是花了一整个上午，把它能从外面看到的部分翻了个遍。
结论先说：没有找到它泄露的证据，但也找不到任何理由相信它能安全地保存这些东西。
一、先把边界划清楚
这篇东西里有严格的两类内容：一类是我实测到的，一类是我推断的。混在一起说是不负责任的，所以先讲清楚我做了什么、没做什么。
做了的：
- 用我自己的账号、我自己的数据；
- 只读地看公开页面：响应头、TLS 握手、证书、静态文件时间戳、错误页；
- 用
curl和openssl，没有任何自动化扫描。
没做的：
- 没有尝试越权访问、没有遍历别人的订单、没有撞库、没有端口扫描；
- 没有碰任何写接口。
以及一条最重要的：我看不到它的数据库。
有没有加密、留存多久、谁能查、有没有审计日志——这些从公网永远验证不了。任何跟你说”我测出来了它数据库没加密”的人，要么在吹牛，要么在违法。
所以这是一份”暴露面评估”，不是渗透测试报告。它能回答的是”这家人有没有在认真做安全”，而不是”你的身份证现在在谁手上”。
二、门是有的，只是没关
第一件事，http:// 进来不跳 https://。
不是跳转失败，是压根没打算跳：访问 80 端口，它 302 到 http:// 的同名路径，然后在这个明文页面上开始走微信授权流程。
更具体一点。正常的网页授权是这样的：用户点登录 → 跳到微信 → 微信带着 code 回调到你的 redirect_uri → 你用 code 换 openid 和会话。
而这套系统在 HTTP 入口触发的授权，redirect_uri 长这样：
|
注意那个 http%3a%2f%2f。它明确告诉微信：把授权码回传到明文地址。
在同一个 Wi-Fi 下，或者任何一个能插进链路的中间人，都能看到这个 code，以及随后的 ASP.NET_SessionId。
而那个会话 cookie 的属性是：
|
HttpOnly 有，SameSite 有，Secure 没有。意思是浏览器不介意把它通过明文发出去。
我知道有人会说”用户都在微信里点，微信是 https”。对，正常情况下是这样。但只要链路上任何一个环节把用户带到 http——旧书签、群里转发的链接、公众号文章里没改过的老地址、缩短链接——后面的授权码和会话就跑在明文上。而这个系统没有任何机制去阻止这件事发生。
一行 301 就能解决。九年了，没加。
三、地址栏里那把锁，不证明任何事
证书是有效的，DigiCert 签发，通配符，2027 年 1 月到期。看起来挺正规。
但它是 DV（Domain Validation）证书。
DV 只验证一件事：申请者能控制这个域名。它不验证这家公司叫什么、在哪注册、是不是真的存在。OV 才查营业执照，EV 才查得更深——而现在浏览器早就把 EV 的”绿色公司名”藏起来了，所以普通人从地址栏上根本分不出这三种。
换句话说：小锁只证明”你连的是这个域名”，不证明”这个域名背后是谁”。
对一个要收身份证的平台来说，这个区别不算小。
四、一台 2012 年的机器
看响应头的时候我愣了一下：
|
IIS 7.5 是 Windows Server 2008 R2 自带的版本，微软对它的扩展支持在 2020 年 1 月就结束了。ASP.NET MVC 4 发布于 2012 年。日期字段也还是 /Date(1777305600000)/ 这种上古格式。
一个 2026 年还在卖权益卡、还在收身份证的系统，跑在一台（或者一套标着）十五年前的操作系统上。
两种可能：要么它真的还在裸奔跑一个停止支持的 Windows，要么版本号只是没人想起来改。两种都不让人放心，只是不放心的地方不一样。
再看安全响应头，我逐项查了：
| 响应头 | 作用 | 结果 |
|---|---|---|
Strict-Transport-Security |
强制后续走 HTTPS | 没有 |
Content-Security-Policy |
XSS 的第二道防线 | 没有 |
X-Frame-Options |
防点击劫持 | 没有 |
X-Content-Type-Options |
防 MIME 嗅探 | 没有 |
Referrer-Policy |
控制 Referer 泄露 | 没有 |
一个都没有。
没有 HSTS，所以降级攻击是可行的；没有 X-Frame-Options，所以可以把预约页塞进一个透明 iframe 里诱导你点；没有 CSP，所以一旦有 XSS，浏览器没有任何兜底。
然后是错误页。我随手请求了一个不存在的接口，它跳到了自定义错误页，页面上写着：
处理您的请求时发生异常。此外，对第一个异常执行自定义错误页时发生另一异常。已终止请求。
这句话翻译过来是：错误处理器自己也崩了，而且线上从来没演练过一次 500。
最后一个细节。登录页那个静态文件的响应头里：
|
2017 年 8 月 4 日。九年，这个文件一个字节都没动过。
停服之后的一千个补丁
有人会说：IIS 7.5 是 2008 年的东西，老归老，能有多少漏洞？
我去 NVD 拉了一遍。口径是官方 CVE 库按 CPE 匹配 windows_server_2008 这一族（含 R2），统计到 2026 年 11 月：
| 口径 | 全部历史 | 2020-01-14 停服之后 | 2023-01-10 付费补丁也停之后 |
|---|---|---|---|
| CVE 总数 | 4,078 | 2,134 | 1,063 |
| Critical | 100 | 67 | 37 |
| High | 2,818 | 1,572 | 749 |
| 描述含 RCE | 937 | 628 | 314 |
| 已被在野利用（CISA KEV） | 199 | 88 | 40 |
翻译一下：微软停止支持之后，这个系统上又冒出来两千多个漏洞；连付费 ESU 都停了之后，还有一千多个，永远不会再有补丁。
这里有个陷阱。如果按”IIS”这个产品去查，NVD 里一共只有 93 条，2020 年之后是 0 条。
不是因为 IIS 变安全了，是因为 HTTP.sys 跑在内核里，它的漏洞全部记在 Windows 名下。按”IIS 版本号”数漏洞，会数出一个虚假的安心。真正的攻击面是操作系统。
几个绕不过去的名字，都在上面那个集合里，也都上过在野利用清单：
CVE-2015-1635（MS15-034），HTTP.sys 远程代码执行，CVSS 9.8。一个畸形的 Range 头就能打，IIS 7.5 时代最出名的一个；CVE-2019-0708（BlueKeep），RDP，9.8，蠕虫级，WannaCry 同款剧本；CVE-2020-1350（SIGRed），DNS 服务，10.0，蠕虫级，停服半年后才披露；CVE-2020-1472（Zerologon），Netlogon，NVD 给 10.0，一个包打穿域控；CVE-2021-34527（PrintNightmare），打印服务，8.8。
2023 年 ESU 结束之后新出的 Critical 里，还有一堆 9.8 的 RCE：PEAP（CVE-2023-21689/21690/21692）、iSCSI（CVE-2023-21803）、MSMQ（CVE-2023-21554）、ICMP（CVE-2023-23415）。这些补丁，2008 R2 永远拿不到。
所以这三条曲线是这样的：
- 2020-01-14 之前：微软还在发补丁，问题可控。
- 2020-01-14 ~ 2023-01-10：只有买了 ESU 的机器才有补丁，没买的从那天起开始裸奔。
- 2023-01-10 之后：ESU 也停了。任何新漏洞都不再有修复路径——不是”懒得修”，是”没有可修的东西”。
话说回来，版本号不等于可入侵。真正决定能不能打进去的，是它开了哪些端口、装了哪些模块、前面有没有 WAF、ESU 到底买没买。我只看到 80 和 443 有响应，没做任何主动探测，所以我不能证明它此刻能被攻破。
我能证明的是另一件事：它已经失去了被修复的能力。
安全不是一个状态，是一个过程——发现、评估、打补丁、再发现。这台机器在 2020 年就退出了这个过程。所以问题不是”它现在有多少漏洞”，而是”从今往后每一个新漏洞，它都只能等着”。
顺便，Server: Microsoft-IIS/7.5 这个头是可以伪造的。它可能真跑在 2008 R2 上，也可能只是版本号懒得改。前者是”修不了”，后者是”故意让你以为修不了”——两种都不是好消息，只是坏的地方不一样。
还有一个旁证，来自别人早就扫过的公开数据。Shodan 对这台机器的记录里，除了 80 和 443，还挂着 5985——WinRM，Windows 的远程管理端口，而且是明文的那一个（5986 才是 HTTPS）。同一份记录给它打的标签是 eol-os，直译就是”生命周期已结束的操作系统”。
我没去连那个端口，也没做任何主动探测，所以不知道它此刻是否还开着。但一个把远程管理口摆在公网上的 Windows，本身就已经说明了很多事——那个端口后面是密码认证，而密码认证是可以被慢慢试的。
顺带说一句，我原本也想过”扫一下端口不就知道了”。扫不出来。端口只回答”开了哪些门”，回答不了”门锁没锁”；而版本号之所以有用，恰恰是因为它回答的是后一个问题。
六、从有赞到自己写，中间省掉的是什么
翻这些东西的时候，我想起一件事。
前两年用他们家的小程序，底下挂的是有赞。
那是一套做了十几年电商 SaaS 的东西，上市公司，支付、订单、会员、数据合规都有一套现成的体系。你不需要无条件信任它，但你至少知道：出了事，有人要担责，而且担得起。
今年再看，小程序换成了一套自己做的页面。
我不反对自研。自研可以更贴业务，也可以更便宜。但从”租一套成熟的”到”自己搭一套”，中间省掉的不只是年费，还有一整套别人踩过坑才长出来的东西：
- 强制 HTTPS 与 HSTS；
- 会话的生命周期与失效；
- 证件字段的加密、脱敏与访问审计；
- 上线前的回归和上线后的告警。
如果省掉这些，换来的是一个明显更好用的产品，那也算值。
但我看到的是另一种”降本增效”：成本降了，速度提了，质量那一栏是空的。
这几年”降本增效”这四个字听得太多。落到实处，通常是三步：把外包换成年假更少的自研，把自研换成 AI 生成，把测试和运维换成”先上线再说”。
用 AI 写代码本身没有任何问题，我天天在用。问题在于：AI 能帮你在一个下午里把一个页面搭出来，但它不会替你想起”http 要跳 https”，除非你本来就知道这件事存在。
于是最后交付出来的东西长这样：
- 一个 2017 年就没再动过的登录页；
- 一台标着 IIS 7.5 的服务器；
- 五个安全响应头，一个都没有；
- 一个”错误页自己也会崩”的错误处理；
- 一个把授权码往明文地址回传的登录流程。
说实话，这套东西不像是有一个工程团队在维护，更像是某个人花了一个周末拼出来的——而且是那种”能跑就行”的拼法。
但我想说的不是”写代码的人水平差”。
是这条链路上，没有任何一个环节，有人对”安全”负责。
可能它没有这个岗位。可能这个岗位在”降本”那一栏里，被优化掉了。
七、一把换不了的钥匙
这套系统的登录态不走 cookie，走一个自定义请求头，账号级、长期有效。我那个脚本就是靠它免登录的——把 token 存进一个 0600 的文件，之后永远不用再扫码。
从工程角度这很方便，从安全角度这是另一个故事：
- 它没有有效期（至少我没观察到过期）；
- 没有二次验证；
- 没有设备列表，也就没有”把别的设备踢下线”这个动作；
- 它的权限等于整个账号：卡、订单、出行人、证件。
也就是说，任何一个环节泄露一次——日志、截图、共享电脑上的浏览器插件、代理软件、别人借你手机看一眼——就是永久接管。
更麻烦的是，它不像密码。密码泄露了你能改，这个 token 你连”改”的入口都找不到。
八、我唯一看不到的那部分
抓包能看到的是：出行人的证件字段是原样返回给客户端的，没有掩码、没有脱敏、没有只返回后四位。
界面上它其实做了处理——票券页里那串号码显示成星号。但那是前端画的：同一个字段，接口里给的是完整的。
掩码在页面上，不在数据里。
这只说明 API 层没做最小化——它不直接等于数据库明文存储。很多系统确实是”库里加密、接口解密后全量返回”，那也算一种（糟糕的）设计。
但结合前面那一堆 2017 年的痕迹，”他们有一套成熟的字段级加密、密钥轮换和访问审计”这个假设，我是不敢下的。
能验证的到此为止，再往下就是猜了。 我把猜测的部分标出来，你自己判断。
九、隐私政策在哪
身份证号属于《个人信息保护法》第 28 条明确列举的敏感个人信息（特定身份）。处理它，法律要求的不止是”告知”：
- 第 29 条：取得单独同意；
- 第 30 条：告知必要性和对个人权益的影响；
- 第 55 条：事前做个人信息保护影响评估；
- 第 51 条：采取加密、去标识化等安全措施；
- 第 47 条：你要求删除时，它应当删除。
而我在未登录状态下，找不到任何可以公开访问的隐私政策或用户协议页面——整站强制微信授权，不授权就什么都看不到。
这不能证明它没有（可能藏在小程序的某个二级页面里，可能在你勾选的那个框后面）。但至少说明：它没打算让你在交出数据之前读到这些。
如果你正在用类似的平台，值得花三十秒做一件事：回到那个”添加出行人”的页面，找找有没有一个单独的勾选框、有没有一句”我们将如何保存你的证件信息”。没有的话，第 29 条那关它就没过。
十、那到底有多危险
把上面的东西收拢成一张表：
| 风险 | 我的判断 | 依据 |
|---|---|---|
| 链路上被中间人截获 | 中 | HTTPS 可用但从不强制，回调地址可以写成 http |
| 账号被接管 | 中高 | 长期 token、无二次验证、无设备管理 |
| 平台内部泄露或滥用 | 无法验证，按投入推断偏高 | 技术栈停留在 2012 年，错误页都没人管 |
| 合规（单独同意、删除入口） | 未观察到 | 公开层面找不到隐私政策 |
综合：中等偏高风险。
不是”快跑”，是”别把它当保险箱”。
补一句公道话：微信小程序内部的通道是微信自己的加密链路，比 H5 那一层要好；但后端还是同一套 IIS，还是同一个 token。
十一、我做了什么
给自己列了几条，也贴在这儿：
- 只在官方小程序里操作，不点任何
http://链接；从浏览器进也手动敲https://。 - 能给号码就不给照片。很多场馆核销只要姓名 + 身份证号，上传正反面是把风险抬高一个数量级。
- 非给照片不可，就加水印：”仅用于 X 月 X 日 XX 场馆核销，他用无效”，再把住址和签发机关遮掉。
- 不往”常用出行人”里长期存。用完就删，账号里不留档案。
- 问客服三个问题：保存多久、是否加密存储、哪些人能访问。要求活动结束后删除，并留下工单号。
- 拒绝删除就投诉：12315、12377，或属地网信办。第 47 条给了你删除权，用不用是另一回事。
- 订单页、核销码不截图外发。那上面有姓名、证件和订单号，一张图能在群里传很久。
十二、一个爆论
说完我自己，说个更大的。
前面这些不是个案。一家公司用五年前的架构收身份证号，另一家也在——只是没人去翻。而”翻的人不存在”这件事本身，就是行业现状。
我的判断是：未来两三年内，一定会出现一次大规模的个人信息泄露事件，源头就是这类 AI 加速搭出来的系统。
理由是一条断层。
现在很多公司大裁员、降本增效，一个人干好几个人的活，美其名曰 DRI，还有更响的叫法——“超级个体”。有经验的老员工被优化掉，年轻人一看：计算机研究生出来找个实习转正都难，学那么多东西出来工作都找不到，投入产出彻底失衡，那就不学了。
于是市场上会出现一种人：三脚猫的功夫，问 AI 要一个服务，网页跑起来了，就上线了。他不是没有 https——他挂了一个 DV 证书，免费的，浏览器里那把锁一样亮；但他跟微信做授权交互的时候，回调走的是 http。他的 token 长期有效，永远不过期。这种设计架构也敢做成产品挂出来卖，我有时候真不知道该说什么。
AI 很强，但用它的得是人更强。现在的局面是，AI 恰恰把”能跑”和”能用”之间的距离藏起来了。不懂 HTTP、不知道 Nginx 是什么的人，也能搭出一个对外提供服务的网站——因为报错之前，它看起来一切正常。撑死胆大的，饿死胆小的。能跑就行，又不是不能用。
我最近工作中遇到的真实样本：有人连 JSON 格式化都不会——你不会用 AI 没关系，JSON 的格式有问题你总能看出来吧？还有程序员拿着 IDEA 搞 Java，一个最基本的报错处理不了，还死鸭子嘴硬，非说自己没问题。这两种我都遇到过。
这些人搭出来的东西不会留文档，不会做回归，出了事没人担责。给老板交个差就好了，至于好不好用、有没有数据安全问题——关我屁事，反正明年这个岗位可能就没我了。
而防守这一侧呢？有能力、有经验的人，能通过 AI 把潜在风险分析出来，抢在出事之前补上。但很多公司没有这个人——那个人要么被优化掉了，要么根本没打算招。
PHP 圈子里隔三差五爆一个漏洞，底下无数老系统裸着，就是这个结构的预演：进攻方的工具越来越强，防守方连自己的资产清单都没有。
所以我说这是爆论，但它不是玄学：草台班子越多，塌下来的概率越高；而接住塌方的那批人，正在被裁掉。这两条曲线会在某个时间点交叉。交叉那天，新闻标题会是”某平台疑似遭入侵，XX 万条实名信息在兜售”。
到那时候再回头看，今天这篇文章里的每一条，都不是意外。
写在最后
密码泄露了可以改，手机号泄露了可以换，身份证号泄露了——它跟着你一辈子。
所以对它的要求，本来就应该比一个普通账号高得多。
一家公司可以没钱做等保、没钱养安全团队，这我理解。但”http 跳 https”是一行配置，”加个 HSTS 头”是一行配置，”把 X-Powered-By 关掉”也是一行配置。这些东西同时缺失，说明的不是没钱，是没人在看。
而我把身份证，交给了一个没人在看的系统。
这种事不用替它担心：生意越好，报名字的公司越多，接手的团队越换，那几行配置照样没人补。草台班子只会越来越多，直到某天塌下来砸到别人头上。
所以明年卡一到期，我打算把账号删干净，不再用了。
不是因为这次调研挖到了什么确凿的泄露证据——我没挖到。
是因为我看不出它有任何能力，挡住下一次。
应合规考虑，文中隐去平台域名与运营主体。所有技术结论来自 2026 年 11 月的被动探测，仅代表当时状态；平台随时可能修补，本文不构成对其安全状况的持续担保。文中未涉及任何他人数据，也未进行任何越权测试。
评论
0 条评论