讨论CCW的安全性

我的文笔很烂。

CCW（共创世界，一个国内 Scratch 社区、面向下一代 ACGN 创作者的 UGC 平台）的前端已经够烂了，能猜到他们的后端也很烂！事实也的确如此，而且处处隐藏着安全风险。

在2025年暑假，我就曾对CCW的API进行分析，以及对其A、B请求头校验做了逆向（这里还需要感谢Saobby的帮助）。事实上，想要逆向出AB校验并不算简单，这在一定程度上保护了CCW，但是一旦能逆向，那么整个CCW API的大门就向你展开了。CCW的其他保护措施很少或形同虚设，并且CCW的前后端稀烂，有很多漏洞，一旦了解了这些漏洞并逆向出了AB校验算法，你就可以进行大捣大乱了！

CSense 掀起了轩然大波，很多扩展开发者都针对这个“安全审计工具”做了反制，例如document.querySelectorAll()检测是否存在 CSense。哈哈，这太好笑了。事实上我只需要修改一下CSense的源码就可以轻松破解！以及他们没有使用的检测手段，例如检测特定localStorage项目的存在，都可以被轻松绕过。

绕过的方法当然不只是修改CSense的源码：我可以劫持你用的检测函数，并返回一个特定的值，这意味着他们的检测方法会统统失效！因为我的脚本权力足够大，并且比其他脚本早运行，这样一来，只要会劫持函数，一切都变得简单起来了。

魔高一尺，道高一丈。有的人想出了一种不使用某个特定扩展就无法运行的方法，即这个作品依赖于某个特定扩展而运行，且这个扩展被混淆且自带检测CSense的方法。前文提到的劫持函数可以轻松绕过检测，就算我不劫持函数，我也可以通过生成一个类似的扩展来替代那个特定的扩展，并且通过劫持网络请求的方式修改被加载的扩展。这些防护手段实际上有一定作用，但都可以被轻松绕过。

然而，真正可怕的不是这些安全审计工具，而是CCW稀烂的前后端。

先说前端。扩展会在作品运行前就被加载，这很关键。CCW会在作品使用未知或存在潜在风险的扩展时提醒用户，然而那些扩展可以轻易地删去弹窗。更恐怖的是，前端还允许加载外链的扩展，这意味着我可以随时修改某个扩展的内容而不需要重新发布作品，我也可以将部署在我服务器上的良性扩展神不知鬼不觉地变为一个恶意扩展。好在这个漏洞以及被修复了。

CCW的创作者学院还存在插入特定iframe的漏洞，此时攻击者只需要加入一段特定iframe，其中包含恶意代码，就可以轻松地盗取你的账号（稍后再来解释“鸭鸭院长”所说的“不存在盗号风险”是错误的），并且不会有诸如登录提示的任何提醒。同时还可以获取你的部分个人信息。

CCWData还存在XSS漏洞，我都懒得说了，专业水准之低令人汗颜，这个漏洞被批露到现在修都不修，明明很容易就能修好。

再来说后端。

https://community-web.ccw.site/students/list_sessions?page=1&perPage=20&sortField=createdAt&sortType=DESC 就能直接获取你的所有有效Token是何意味？这是用ORM用魔怔了吧。我承认你把Token放到Cookie里还设置了Http-Only确保JS程序不能阅读但是你这一个接口就直接把所有token以及登录地、IP给获取了你是怎么写的？我只要在一个程序里放上恶意扩展；甚至简单一点，利用CCWData的XSS的漏洞运行一段恶意脚本，我就直接把你的号盗了，只要你不清除Token（大部分人都不会这么做）我就能一直用到美西螈占领世界。甚至如果我是邪恶美西螈，我可以利用你的token在你的所有作品神不知鬼不觉地加入恶意脚本实现蠕虫式的传播，最后像蠕虫病毒一样爆发地造成破坏。我很好奇你们是怎么写后端的、怎么做测试的，甚至在反馈之后也拖着不修复。谁知道没有没人真的像我如上说到的那样操作。

再来说后端那个WAF。很厉害，内容中有时包含一段JS就能拦截，但是经过BDDJR发现只要请求够多就能漏过去。我试了试确实是这样，所以我直接写段脚本批量请求了，这也太搞笑了。再说了还能混淆。CCW很喜欢用阿里云的东西，你好好用行不行。

使用IPv6就不能正确判断IP属地，sso.ccw.site支持IPv6但是community-web.ccw.site不支持也太诡异了（BDDJR发现）。

还有很多没说了，就不一一列举了。

最后说一下最需要的联机后端吧。现在CCW的联机将客户端当服务端使用，这么做节约资源但是增加了安全风险。攻击者实施攻击轻而易举，而CCW这么有钱，做一个自定义后端出来和提供服务器不是难事吧。光想着赚钱不想着提升用户体验了；就算说做一个自定义后端很难，但是漏洞也不修就过分了吧。

开发这么消极，还有一堆小朋友为你“辩护”，实在赢得人心。