用户凭据明文传输漏洞

上周帮朋友排查一个老系统，用户登录时抓了个包，凭据用户名密码直接躺在HTTP请求里，明文明文可见。传输朋友说这系统用了五年，漏洞一直这么跑着。用户我没笑他，凭据因为类似的明文情况我见太多了——很多开发者的第一反应是“内网没事”，可内网就绝对安全吗？传输

用户凭据明文传输，说白了就是漏洞你把家门钥匙挂在门口垫子下面，还觉得挺隐蔽。用户HTTP协议本身不加密，凭据任何能截获流量的明文人——同一WiFi下的黑客、路由器管理员、传输ISP员工——都能直接看到你输入的漏洞密码。更糟的是，很多系统连POST请求体都不编码，密码就赤裸裸地出现在开发者工具里。

有人会辩解：“我们用HTTPS了。”可现实更魔幻。我审计过一家公司，HTTPS证书过期了三个月没人管，前端代码里却写死了https链接，用户访问时浏览器直接报错，他们客服教用户“点高级，继续访问”。这个操作等于把加密通道亲手拆了，用户凭据照样裸奔。

还有个细节容易被忽略——移动端App。很多App的API接口走HTTP，因为开发时图方便，上线时忘了改。我见过一个健身App，登录接口是http://api.xxx.com/login，密码字段叫“password”，连个混淆都没有。用抓包工具一抓一个准，用户体重、心率数据全都能看，更别提账号密码了。

真正的隐患不在技术，而在认知。有些团队觉得“反正黑客看不上我们”，可攻击者不挑食，撞库、暴力破解、中间人攻击，都是自动化工具在扫。你密码明文传一次，就等于把用户数据库的钥匙主动递出去。密码复用率那么高，一个账号泄露，可能牵连用户在其他平台的资产。

修这个漏洞不难，难的是改掉“能用就行”的思维。最直接的办法是全面启用HTTPS，证书别省，现在免费的Let's Encrypt够用。再进一步，前端对密码做哈希再传输——但哈希不等于安全，得配合加盐，否则彩虹表一撞就穿。更稳妥的是用HTTPS+前端加密双层防护，但别迷信其中任何一层。

我见过最离谱的案例是某政务系统，登录页用了HTTPS，但登录后的查询接口走HTTP，用户ID和手机号在URL参数里明文传递。开发者的解释是“查询接口不涉及敏感操作”，可手机号本身就算敏感信息。这种半吊子加密比不加密更危险——它给人虚假的安全感。

说句实在话，明文传输漏洞本质上是懒惰和侥幸心理的产物。修复它不需要高深技术，只需要把“传输安全”当成默认选项，而不是可选项。下次你写登录接口时，先问自己一句：如果这个包被截获，用户会恨我吗？答案要是肯定的，就别偷懒。