明文传输漏洞

早上九点，明文某电商平台的传输订单系统突然涌入大量异常请求。安全工程师调出日志，漏洞发现攻击者正用一串串明文密码批量登录用户账号——这些密码，明文正是传输从该平台自己的数据库里泄露的。讽刺的漏洞是，泄露源头并非黑客攻破了什么高深防线，明文而是传输开发者在接口文档里随手写了一句：“密码字段请使用base64编码传输。”

base64不是漏洞加密，它只是明文给数据换了个马甲。任何懂技术的传输人一眼就能扒掉这层马甲。可就是漏洞这种幼儿园级别的伪装，至今仍活跃在大量业务系统中。明文我见过某银行内部系统，传输登录时直接把账号密码拼在URL参数里——浏览器历史记录、漏洞代理服务器日志、CDN节点缓存，处处都留下用户口令的“裸奔”痕迹。

明文传输的危害像慢性毒药。攻击者不需要破解你的服务器，只要在通信链路上某个节点蹲守就够了。公共WiFi是重灾区，抓包工具一开，同一局域网里所有HTTP流量都像摊开的日记本。更隐蔽的是运营商或骨干网层面的监听，普通用户毫无感知。我认识的白帽黑客做过实验：在办公室路由器上做镜像端口，半天时间就捕获了同事登录内部OA的账号密码，以及某位HR查询员工薪资时输入的查询条件。

有人会说：“现在都上HTTPS了，明文传输早该绝迹了吧？”现实很骨感。很多系统只在登录页启用了HTTPS，但登录后的业务请求又退回HTTP——比如修改手机号、重置支付密码这类敏感操作。更常见的是混合内容漏洞：页面主体是HTTPS，但某个图片或脚本走HTTP加载，中间人就能篡改这个资源，注入恶意代码。这些漏洞在安全扫描报告里经常被标为“低危”，可一旦被利用，就能直接绕过登录保护。

还有个反直觉的盲区：内部系统。很多企业觉得内网流量“安全”，于是内部ERP、运维平台的认证信息全部明文传输。可内网恰恰是横向移动的最佳猎场——员工终端一旦被植入木马，攻击者就能在内网里捞取所有凭证。某次应急响应中，我们发现攻击者进入内网后，仅凭抓包得到的明文口令，就连续登录了十几个系统，从开发测试环境一路摸到生产数据库。事后复盘时，运维总监盯着抓包文件里的SQL Server密码，愣了半天才说：“这个密码用了八年，从来没想过会被这样拿走。”

修复明文传输漏洞的技术方案很简单：全站强制HTTPS，关闭HTTP回退；敏感接口做额外加密签名；对证书有效期和域名做严格校验。但真正难的是改变开发习惯。很多程序员图省事，直接在代码里写“http://”开头的API地址，或者忽略证书错误继续连接。有个朋友的公司做过一次内部演练：安全团队伪造了一个自签名证书的钓鱼页面，结果有三分之一的内部系统客户端因为“跳过证书校验”的配置，成功连接到了这个假服务器。

写到这里，我想起一个细节。某次测试某政务App，抓包发现它用明文传输身份证号和手机号。我联系了他们的技术负责人，对方第一反应是：“这个系统是外包做的，我们也没办法。”后来才了解到，合同里根本没提安全要求，外包团队自然怎么省事怎么来。制度上的盲区，往往比技术漏洞更难补。

明文传输不是什么高深攻击手法，它就像把家门钥匙放在门口地垫下——小偷不费吹灰之力就能进来。可偏偏很多系统连换个智能锁的意愿都没有。说穿了，这不是技术问题，是态度问题。