ai时代下衍生出的通杀：从self-xss到任意用户接管和任意文件删除

声明

文中涉及到的技术和工具
仅供学习使用，禁止从事任何非法活动。
如因此造成的直接或间接损失，均由使用者自行承担责任

前言

求个信息收集厉害的大佬，一起挖洞进步

思考
AI浪潮下，各家大厂推出的AI业务其实面临一个问题：
为了快速抢占市场，他们不可能从底层架构完全自研，一定会大量复用现有的开源组件、第三方接口或者通用的业务模块。
因为代码复用的程度很高，所以它们就会存在大量的相似性（同构性）。这就意味着，其实AI业务里存在很多通用型的逻辑漏洞（比如未授权、信息泄露）。如果在A厂商的AI接口里挖到了点，去测B厂商的相似AI业务，命中率往往非常高。这也是我们最近挖SRC比较高效的一个思路。
正文
我相信有不少的师傅肯定遇到过，在ai对话场景里直接输入xss poc

这种ai对话场景大概率是不会有分享页面的
那么就变成了一个self-xss很多师傅就直接放弃掉了
这个就是我要讲的一个小通杀
接下来直接上案例
开局一个ai对话页面,二话不说直接丢poc探测：

可以看见没解析，并且没有分享按钮
这不完了吗，开局就出师不利
后面我通过fuzz发现输入框解析部分markdown语法
例如

~123~
[点击这里](javascript:alert("XSS"))
![CChen.jpg]("onerror="alert('XSS'))

通过测试发现这些常见的markdown语法都不行
于是我也放弃了。转头去测试其他功能点了。
转机

过了几天，我在刷微信公众号文章的时候看到了这位师傅的文章
【AI安全】Dify中的XSS利用&&CVE-2026-26023深度分析
他是通过代码块的形式来渲染的，因为前端未能对内容进行有效安全过滤
从而导致了xss

```这里是要渲染的内容```

那么如果我把这个思路套用在这个站点上，如果他过滤也没做好，是不是有可能解析html呢？
话不多说，实践才是检验真理的唯一标准！
构造好poc，发送！

什么竟然没解析！白高兴了。

但是转念一想，这个是web页面，有没有可能客户端，app，小程序过滤没写好呢

最后发现客户端，app均存在这个问题

但是没有分享按钮，就是一个self-xss，压根没用啊

但好不容易打到这里了，还是得想想办法。
最后我观察到大部分ai对话场景都有这个业务需求
例如某包
有时候会在手机上弹窗：

大家都在问：牛顿拉了二十多年屎💩，为什么没有发现万有引力

有没有发现我们点击弹窗后，他会自动的发送这个问题
那么猜测:

点击弹窗后
    |
    |
    ↓
发送一个请求
    |
    |
    ↓
这个请求会携带一个q参数，类似?q={你的问题}
    |
    |
    ↓
 成功实现自动发送信息的业务需求

那么同样是ai对话场景，他大概率也有这个功能
接下来就交给ai大人去审计js找出参数

最后成功找出参数query可以携带问题
那么我们构造携带恶意poc的请求

https://a.XXXXX.com?query= ```<s>123</s>```

成功的把self-xss变成了储存xss
那么由于我们是在客户端和app，我们通过审计代码
成功找到几个具有高权限的IPC功能
然后构造xss poc成功获取到有httponly的核心cookie

成功造成账户接管
并且我还找到了另外一个高权限IPC功能可以删除本地的任意文件

成功从忽略打到了高危。并且该思路适用于现在各大ai平台。
**攻击链: **

Web端XSS过滤 → 切换客户端发现代码块注入```<s>123</>``` → 利用业务query参数转为存储型XSS → 审计客户端JS挖掘高权限IPC → 构造恶意链接 → 受害者访问触发存储XSS → 调用IPC获取HttpOnly Cookie → 成功接管账号（并可删除任意文件）

最后
(我还没刷完，求大佬们留点给我。求带)
求几个资产多的大佬带我一起挖洞，不会找资产，找不到了...