密码明文传输漏洞本质是通信链路不可信，仅前端防护无效；必须全站HTTPS、禁用混合内容、后端校验不可逆哈希而非依赖前端加密，且杜绝GET传密。
密码明文传输漏洞不是前端“没写对”就能解决的问题，而是整个通信链路是否可信的判断。只要表单提交走的是 http://，哪怕 type="password"、JS 加密、autocomplete="off" 全都加上，也等于裸奔。
用 Wireshark 或 Burp 抓包看 password 参数是否明文
这是最直接的验证方式：打开登录页，填入测试账号密码，点击登录，同时在 Wireshark 中过滤 http.request.method == "POST" 或在 Burp Proxy 中拦截请求。重点看请求体（Request Body）里 password 字段的值是不是原始字符串（如 password=123456），而不是加密后的哈希或 token。
- 如果看到明文，说明漏洞存在；即使字段名被改成
pwd、user_pass或带随机后缀，只要值可读，就仍是明文传输 - Burp 的 Repeater 功能可以反复修改该值重发，确认服务端是否接受任意明文——这会放大风险等级
- 注意区分：JS 加密后的值（如
password=sha256%3Aa1b2c3...）不算明文，但前提是 JS 文件本身由 HTTPS 加载，否则攻击者可在传输中替换加密逻辑
检查页面是否全站 HTTPS 且无混合内容
很多团队只给 action 地址配了 HTTPS，却忽略了页面本身、JS/CSS 资源、CSRF token 接口是否也走 HTTPS。浏览器一旦发现 https:// 页面里加载了 http:// 脚本，就会标记为“混合内容”，并可能禁用部分安全策略（如 autocomplete="off"）。
- 在 Chrome 开发者工具的
Security标签页查看 “Connection secure” 是否显示绿色锁图标；点开后看 “Insecure content” 有无报错 - 检查 HTML 源码：
<form action="https://...">是必须的，但更要确认<script src="http://xxx.js">这类引用不存在 - Nginx 或 CDN 配置中，如果只对外暴露 HTTPS，但 upstream 转发到
http://localhost:8000，那只是“前端加密、后端裸奔”，不满足 PCI DSS 或等保要求
验证后端是否依赖前端加密而跳过校验
有些系统前端用 JS 对密码做了 AES 加密，后端直接解密后比对数据库明文密码——这反而更危险。因为一旦加密密钥硬编码在 JS 里，或通过未鉴权接口获取，攻击者就能批量解密所有抓到的密码密文。
立即学习“前端免费学习笔记（深入）”；
- 抓包拿到加密后的
password值，在 Burp Repeater 中尝试改写为其他密文，看后端是否仍能解密并错误返回“密码错误”，说明解密逻辑是开放的 - 检查后端代码中是否有类似
decrypt(request.password)后直接查库的逻辑；正确做法是：前端只做不可逆哈希（如 PBKDF2 + salt），后端比对哈希值，且 salt 必须服务端生成并绑定 session - 若使用 WebCrypto API 做非对称加密（如 RSA-OAEP），需确认公钥是否动态下发、私钥是否绝不落盘——现实中极少这么用，容易引入密钥管理漏洞
别忽略 GET 提交和 URL 参数泄露
虽然登录表单通常用 POST，但有些系统为了“调试方便”或兼容旧逻辑，把密码塞进 URL，比如 GET /login?username=admin&password=123456。这种请求会在浏览器历史、代理日志、CDN 缓存、服务器 access log 里留下完整明文。
- 用浏览器地址栏手动拼一个带
password=的 URL 访问，看是否能触发登录或返回敏感信息 - 检查所有含认证逻辑的接口文档或 Swagger 页面，确认没有
@RequestParam String password这类 GET 参数声明 - 后端框架（如 Spring Boot）若未显式禁用 GET 方式接收敏感参数，需加注解
@PostMapping并移除@GetMapping支持
真正难排查的，是那些看似“已修复”的场景：HTTPS 配好了，JS 加密也上了，但密钥固定、salt 复用、或后端把加密结果当明文再哈希一次——这些细节不会在抓包里直接暴露，得结合前后端代码交叉验证。
