拉黑后消息重放漏洞

原创

游山玩水
游山玩水

山水SRC

2026年10月14日 09:30
河南

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

免责声明

本公众号分享的所有渗透测试技术文章仅面向合法授权的安全测试、学习交流与研究用途。读者必须确保自身行为符合《网络安全法》等相关法律法规，严禁将其用于任何未授权攻击等非法活动。因不当使用或传播相关内容所引发的任何法律责任与风险，由行为人自行承担，本公众号（或本人）概不负责

前提

技术性描述

① 系统在B拉黑A后，仅在前端/客户端禁用了A向B发送私信的入口，服务端发送消息接口未校验双方黑名单状态。

② 服务端发送消息接口仅验证发送者与接收者账号是否存在，未校验发送请求是否来自当前合法会话或时效性，也未校验拉黑关系。

③ A在B拉黑前正常发送消息并抓包保存该请求，拉黑后利用Repeater等重放工具重新发送该请求，服务端按正常消息处理并成功投递。

通俗易懂

① B把A拉黑后，APP只是把A的私信按钮变灰了，但后台服务器并没有检查拉黑这件事。

② A在拉黑之前偷偷把“发消息”的操作抓包存了下来。

③ 现在A把这个旧操作原样再发一遍，服务器不知道B已经拉黑了A，照样把消息发给了B。

测试流程

1. A登录并向B发送一条正常消息，抓包记录该发送请求，保存到Repeater模块。
2. B将A拉黑，A在客户端尝试向B发送消息，确认前端已禁用私信功能或提示无法发送。
3. A使用Repeater重放之前保存的发送消息请求。
4. 观察B是否收到该消息，或服务端是否返回发送成功。
5. 若B成功收到消息，即确认漏洞存在。

危害

1. 拉黑功能形同虚设，被拉黑者仍可通过重放旧请求继续骚扰受害者，导致核心安全功能失效。
2. 服务端长期不校验拉黑状态，受害者无法阻止不受欢迎的联系，可能引发骚扰、辱骂、诈骗等安全风险。
3. 若消息内容包含恶意链接或附件，攻击者可绕过拉黑限制持续投递恶意内容，扩大攻击面。