WEB登录明文传输检测

打开浏览器开发者工具，录明切到Network面板，文传勾选Preserve log，输检然后在一个看起来挺正规的录明网站上输入用户名和密码，点击登录。文传如果那个POST请求的输检Payload里，password字段的录明值是"mypassword123"这种一眼就能读出来的东西，而不是文传一长串乱码——那你刚才做的事，跟在广场上用喇叭喊出自己的输检银行卡密码没有本质区别。

这不是录明危言耸听。我去年帮一个做电商的文传朋友看他的后台，顺手抓了个包，输检发现登录接口传的录明密码就是明文。他当时还挺自信，文传说"我们用了HTTPS啊"。输检对，传输层是加密的，但问题在于，很多网站的前端代码里，密码在提交之前压根没做任何处理。HTTPS保护的是"路上"的安全，可一旦请求到了服务端，或者中间被某种方式截获并解密——比如企业内网的SSL中间人、代理工具、或者服务端日志——明文密码就赤裸裸地躺在那里。

明文传输到底怎么判断

最直接的办法就是抓包。Chrome的F12、Fiddler、Charles、Wireshark，随便哪个都行。重点看登录请求的body部分。如果看到类似 username=admin&password=123456 这种结构，基本可以断定是明文。有些网站稍微"讲究"一点，用Base64编码一下，比如 cGFzc3dvcmQ=，这玩意儿跟明文没区别，解码就是一瞬间的事。还有人用简单的MD5，不带盐的那种，网上彩虹表一查就出来。这些都属于"伪加密"，骗自己可以，骗不了攻击者。

另一种情况更隐蔽：前端JS里做了RSA或者AES加密，但密钥是硬编码在JS文件里的。攻击者下载你的JS，找到密钥，照样解密。这种叫"客户端加密"，本质上只是增加了点工作量，并没有真正解决传输安全问题。真正靠谱的做法是：前端不做任何加密，直接依赖HTTPS，密码在服务端用bcrypt或者argon2这类慢哈希加盐存储。传输层交给TLS，存储层交给哈希算法，各司其职。

为什么2024年了还有这么多明文

我观察下来，原因挺杂的。老系统遗留是一大类——十年前写的代码，那时候HTTPS还没普及，大家就这么传了，后来加了个SSL证书，但代码没人动。另一类是开发者认知问题，有人真的以为"加了HTTPS就等于密码安全了"，没想过服务端日志、APM监控、错误上报这些环节会不会把密码记下来。还有一类是内部系统，觉得"反正是内网，没人看"，结果内网被横向移动之后，攻击者拿到的就是一堆明文凭证。

有个细节值得注意：很多网站在登录失败时，会把整个请求体打到日志里方便排查。如果密码是明文，那日志文件就成了密码库。我见过一个Spring Boot应用，logback配置里把org.springframework.web的日志级别设成了DEBUG，结果每次登录，控制台就打印一行 Parameters: { username=[admin], password=[admin123]}。运维觉得方便，安全人员看了想打人。

怎么改

如果你在维护一个系统，先别急着上什么前端加密方案。第一步，确认全站HTTPS，包括登录接口，别搞什么混合内容。第二步，检查服务端日志配置，把密码字段脱敏，Spring Boot可以用 @JsonIgnore 或者自定义序列化器，Nginx层面也可以做日志过滤。第三步，如果实在需要在前端做点什么，用SRP（安全远程密码）协议或者PAKE类方案，别自己发明加密流程。第四步，服务端存储用bcrypt，cost设到12以上，别用MD5和SHA1。

最后说个真事。某次渗透测试，目标是一个省级单位的OA系统。登录请求是明文的，我抓包之后没急着爆破，先翻了翻他们的前端JS，发现有个 checkUser 接口，传用户名返回该用户是否存在。再结合明文登录，等于把"用户名枚举"和"密码明文"两个漏洞凑齐了。后来报告里写了一句：攻击者不需要任何高级技巧，只需要一个浏览器和十分钟耐心。对方看完沉默了很久。

密码明文传输这件事，技术难度不高，但暴露的是对安全边界的理解偏差。HTTPS不是万能药，前端加密不是护身符。真正该做的，是把密码当成敏感数据，从输入框到数据库，每个环节都问一句：这里会不会泄露？

本文地址：http://www.79wt.cn/news/030d1099959.html