未经许可,不得转载。
本文涉及漏洞均已修复。
前言
想象这样一个场景:一个专门处理敏感文档的平台,如保险理赔或身份验证系统,却因一个设计疏漏而成为攻击者的“金矿”。在对某个保险门户的文件上传功能进行测试时,我意外发现了一个可导致大规模账户接管的存储型 XSS 漏洞。最初的尝试只是一次简单的安全测试,然而,漏洞的深度远超预期。让我们深入探讨这一发现。

正文
该系统允许用户上传文件,以支持提交的表单——这是类似平台上的常见功能。上传成功后,系统会将文件与一个参考编号(refNo)关联,例如 R2326400539(假设属于用户 John)。随后,用户可以通过特定页面查看已上传的文件:
https://[redacted].com/xxx.asp?refNo=R2326400539
看似平常的文件管理机制,却隐藏着巨大的安全风险。在分析上传请求时,我注意到一个名为 fileUidList 的参数,该参数用于定义文件的元数据。出于好奇,我尝试对其进行篡改,并将篡改后的请求绑定到另一个参考编号,例如 R2326400540。
结果令人惊讶:服务器毫无防备地接受了篡改后的请求。
为了验证漏洞的可利用性,我构造了以下请求,在 fileUidList 中植入 XSS 载荷:
POST /
订阅专栏 解锁全文
966

被折叠的 条评论
为什么被折叠?



