让我们开始谈谈我是如何发现业务逻辑缺陷的。被阻止的用户仍然可以发送消息/文本的地方。

这个问题还没有解决，所以我不能透露那个程序的名字。假设该程序为https://xxxxxx.com。

Web 应用程序是关于游戏站点的。用户可以在其中参与足球比赛，分享他们的比赛时刻，还可以在个人聊天中与其他用户发短信。

花了几天时间，我在这个 Web 应用程序上发现了一些易受攻击的功能点。

今天我要讨论DG Chat部分。用户可以通过个人聊天与其他用户交流的地方。

我创建了两个帐户，假设用户 A和用户B。我从用户 A搜索了用户 B的帐户并发送了一条测试消息。

这个短信功能很容易受到攻击。在发送文本时，我捕获了以下请求，

将请求发送到repeater（稍后需要用于开发）

存在阻止用户功能。所以我从用户 B的帐户中屏蔽了用户 A。

通常当用户阻止某人时，被阻止的用户不能向该人发送任何文本/消息。有趣的部分来了。

还记得吗？我在之前的repeater上发送的那个请求。请求中有一个评论正文。我更改了评论并在repeater中发送了响应请求。

响应是 200 OK 。这意味着我的文本/消息已发送。

有了这个技巧，我就可以给阻止我的用户发短信了。

如果有聊天功能，请始终尝试在阻止后发送文本。

推荐阅读

实战 | 记一次渗透拿下某儿童色情网站的经过

实战 | 某某街一处XSS的绕过思路

实战 | 记一次企业钓鱼演练

干货 | 2022年超全的安全知识库

实战 | 实战一次完整的BC网站渗透测试

星球部分精华内容推荐

其他更多精彩内容，欢迎加入我们的星球