【实战】某第三方支付对接平台的CSRF修改管理员密码

一、故事背景

这次对某第三方支付对接平台进行 Web 安全评估。目标系统为多个棋牌平台提供代收代付的支付通道系统，接口与资金流水密集。客户重点关注后台管理安全，因为后台承载了大量敏感操作。我在拿到授权后，测试了 CSRF（跨站请求伪造）漏洞。CSRF 的原理是：攻击者诱导已登录的受害者访问恶意页面，恶意页面会自动向目标站点发起请求，利用受害者的登录态执行操作。

二、信息收集

信息收集阶段，我登录后台，抓取了管理员修改密码的请求。发现修改密码接口 /manage/change_pwd 接收 old_password 和 new_password 两个参数，请求中没有 CSRF token，也没有验证 Referer 来源。这意味着只要能诱导管理员访问一个恶意页面，就能在他不知情的情况下修改他的密码。

三、漏洞发现

我进一步分析了修改密码接口的细节。发现接口只校验了会话是否有效，没有校验旧密码是否正确（或者旧密码校验在客户端完成）。这意味着即使不知道旧密码，也能直接设置新密码。这大大降低了攻击难度。我构造了一个包含自动提交表单的恶意 HTML 页面。

四、漏洞利用

构造的恶意页面核心代码如下：一个隐藏的 form 表单，action 指向目标站点的修改密码接口，method 为 POST，其中包含两个隐藏字段 old_password 和 new_password，new_password 设置为攻击者指定的值。页面加载后自动提交表单。我让管理员在已登录后台的状态下访问了这个页面。

五、权限获取

管理员访问恶意页面后，密码被静默修改为攻击者指定的值。我用新密码成功登录了后台，验证了 CSRF 漏洞的完整危害。整个攻击过程管理员毫无察觉，这充分说明了 CSRF 的隐蔽性。我随后恢复了管理员的原始密码，并整理了完整的漏洞报告。

六、复盘总结

这次测试的核心教训是：所有状态变更请求都必须加 CSRF 防护。修复建议：第一，所有 POST 请求添加随机的 CSRF token，并在服务端校验；第二，校验 Referer 或 Origin 头，拒绝跨域请求；第三，修改密码等敏感操作必须强制验证旧密码，且旧密码校验必须在服务端进行；第四，对敏感操作增加二次验证，如短信验证码。

本文为授权安全评估实录，目标均已脱敏（IP 为文档保留段），仅用于安全研究与学习交流。