评论字符限制绕过导致客户端拒绝服务漏洞

原创

游山玩水
游山玩水

山水SRC

2026年9月28日 08:47
河南

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

免责声明

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

测试流程

测试前提

1. 功能入口

：目标应用（Web 或移动端）存在评论功能，且前端对评论长度进行了限制（如最多 500 字符）。
2. 后端校验缺失

：服务器端未对评论内容的长度进行严格校验，仅依赖前端限制。
3. 请求可拦截

：攻击者能够使用代理工具（如 Burp Suite）拦截提交评论的 HTTP 请求。
4. 客户端渲染缺陷

：客户端（尤其是移动端 App）在加载评论时，未对超长文本做截断或分页处理，直接将完整数据载入内存并尝试渲染，导致内存溢出或 UI 线程阻塞。
5. 账号权限

：拥有一个可发表评论的普通用户账号。

测试流程

步骤一：定位评论请求

1. 登录账号，进入任意帖子（优先选择官方账号或热门帖子以放大危害）。
2. 在评论框输入正常文本（如 test），点击提交。
3. 使用 Burp Suite 拦截该请求，观察请求结构。通常为 POST /api/comments，包含 post_id、content 等参数。

步骤二：构造超长载荷

1. 在 Burp Suite 的拦截界面或 Repeater 模块中，修改 content 参数的值。
2. 生成大量文本（例如，将一段字符重复百万次，使最终请求体达到数 MB 甚至更大）。

• 示例

：\"content\": \"A[重复1,000,000次]\"

3. 若请求包含长度标识（如 Content-Length），确保同步更新。

步骤三：绕过限制并提交

1. 放行修改后的请求。
2. 观察服务器响应：

• 漏洞存在

：返回 200 OK 或 201 Created，且响应中包含新创建的评论 ID，表明超长评论已被成功存储。
* 漏洞不存在

：返回 400 Bad Request 或 413 Payload Too Large，说明后端存在长度校验。

步骤四：验证客户端崩溃

1. 使用受害客户端（如手机 App，不同操作系统/版本）访问该帖子。
2. 触发评论列表加载（下拉刷新或自动加载）。
3. 预期结果

：客户端出现卡顿、无响应，最终闪退（崩溃），或提示“加载失败”。
4. 影响范围验证

：观察该帖子是否从用户的新闻推送（Feed）中消失，或点击后同样导致崩溃，实现“禁用访问”。

危害等级与影响