DedeCMS的密码密码重置漏洞，我2018年在甲方服务器上亲手试过。密码那台老站用的密码是5.7版本SP2，管理员密码早忘了，密码客户急得跳脚。密码我打开`/member/resetpassword.php`，密码按常规流程走，密码填了管理员用户名，密码系统竟然直接返回了重置链接——根本没验证邮箱或安全问题。密码 问题出在`member/model/`目录下的密码`resetpassword.php`文件里。它判断用户是密码否存在用的SQL语句是`SELECT * FROM dede_member WHERE userid = '$userid'`，但后面验证环节有个致命缺陷：如果用户不存在，密码程序会跳去注册流程；如果用户存在，密码它直接生成一个`$randval`随机数，密码然后把这个值写进`dede_member`表的密码`pwd`字段——注意，是明文。 更离谱的是，那个随机数生成函数`GetRandStr(8)`用的是`mt_rand()`，而PHP的`mt_rand()`在Windows环境下种子值范围只有2^31。我用Python算了一下，穷举所有可能种子只要几秒钟。当时我写了个脚本，先请求重置密码页面，拿到返回的Set-Cookie里的`last_vid`值，这个值就是`mt_rand()`生成的种子。然后本地跑一遍`mt_rand()`序列，直接算出重置后的密码。 那客户看我敲了十几行代码，三分钟内就把管理员密码改成了`Hack1234`，当场脸都绿了。后来我翻了官方补丁，修复方式是改用`random_bytes()`生成随机数，并且加上了邮件验证步骤。 但这漏洞的本质不是随机数强度问题。真正要命的是DedeCMS把密码重置逻辑和用户验证逻辑耦合在同一个接口里。攻击者根本不需要知道原密码，只要目标用户名存在，就能触发重置流程。哪怕随机数再强，只要流程设计成“提交用户名→直接重置密码”，漏洞就永远在。 现在回想，那台服务器上还跑着老掉牙的PHP 5.2，连PDO都没启用。DedeCMS当年号称“国内最流行的CMS”，结果连最基本的防CSRF token都没做。我后来在代码里找到`dede_token`这个隐藏字段，它只是存在session里，但重置密码的接口压根没校验这个token。 所以你看，这密码漏洞本质是两件事叠加：一是随机数可预测，二是流程缺验证。单独修任何一处，攻击者都还有路可走。后来我写渗透测试报告时特意强调，别只盯着`mt_rand()`，要重构整个密码找回流程——先发邮件验证链接，链接里带一次性token，token再关联用户ID，用户点开链接才能设置新密码。 可惜那时候DedeCMS官方连个安全团队都没有，漏洞库更新全靠网友提交。那客户最后换了WordPress，我帮他迁移数据时发现，dede的`dede_admin`表里密码字段全是MD5，连盐都没加。这破系统能活这么多年，全靠搜索引擎优化做得好，安全上就是个筛子。