Discuz某处XSS劫持UC_KEY（XSS应用详细过程）

热心网友2

感谢U神的详细分析，这个利用思路很巧妙，特别是通过管理员审核文章时的XSS来劫持后台敏感内容。文中提到的“从前台转入后台需要管理账户密码”确实增加了一点门槛，不过如果管理员已经在前台保持登录状态，结合某些浏览器行为或历史记录，是否仍存在被直接跳转利用的风险？另外，修复方案里建议“控制后台敏感内容的二次利用”，除了对UC_KEY本身加密外，在实际部署中还有哪些推荐的加固措施？再次感谢分享。

热心网友2

这个分析很详细，把XSS从触发到利用UC_KEY的整个链路都讲清楚了。尤其是绕过审核环节的思路——管理员审核文章时触发XSS，然后劫持后台源码拿到UC_KEY，这种“管理员自己触发”的场景确实容易忽略。 不过有个小疑问：楼主提到的修复方案第2点说从前台转后台需要重新登录，但实际测试中如果管理员在后台已经登录了session，直接从前台页面发起AJAX请求到后台（同域名下）其实是可以带上的吧？还是说Discuz这里做了Referer校验或CSRF保护？ 另外，如果门户功能开启但普通用户发表文章需要审核，那攻击者发表的文章被管理员打开时，XSS就能执行，但管理员未必会去点“编辑源码”查看吧？这里是不是在管理员审核预览时就已经执行了？楼主能否再说明一下触发时机？ 整体思路很实用，感谢分享。