文章总结： 文档分析了某通系统CXF框架的认证漏洞，通过配置文件获取硬编码keyCode后构造SOAP请求可实现未授权获取用户敏感信息。文章详细展示了从框架分析、路由探测到PoC构造的全过程，指出AuthInterceptor仅验证固定密钥导致鉴权缺陷，并演示了通过getUserinfoList接口批量获取用户密码MD5的漏洞复现。 综合评分： 85 文章分类： 代码审计,WEB安全,实战经验,漏洞分析,安全工具
【代码审计】某通漏洞审计分析
原创
PumpkinBridge PumpkinBridge
红细胞安全实验室
2026年6月11日 09:51 广东
在小说阅读器读本章
去阅读
一、了解系统框架
依旧拿到安装后的代码，源码位于tomcat/webapps/下
一眼看过去，authserver、XXapi和XXWeb是三个独立war包，一般来说WebService的认证和鉴权做得比其他地方的鉴权松得多，这种也许是最好打的地方
二、分析框架
第一步：从框架配置入手
现在因为时间比较充足，不用上来就全局搜ScriptEngine、Runtime这种关键字，先搞清楚它用了什么框架，那就先看这个系统框架的配置文件
Tomcat的web.xml会有servlet mapping，CXF的xml配置文件会把所有接口、拦截器等都列出来
实际翻了一下，关键文件在tomcat/webapps/fmapi/WEB-INF/classes/spring-cxf.xml
其实这个文件就已经暴露很多了
<!-- REST 接口 --><jaxrs:server id="IWebServiceJaxrs" address="/"> <jaxrs:serviceBeans> <ref bean="jaxrsWebservice" /> </jaxrs:serviceBeans></jaxrs:server><!-- SOAP 接口 --><jaxws:server id="IWebServiceJaxws" serviceClass="com.xxx.ces.webservice.IWebserviceJaxws" address="/webservice/jaxws"> <jaxws:serviceBean> <ref bean="jaxwsSerivce"/> </jaxws:serviceBean> <jaxws:inInterceptors> <bean class="com.xxx.ces.utils.AuthInterceptor"></bean> <bean class="org.apache.cxf.interceptor.LoggingInInterceptor"/> </jaxws:inInterceptors></jaxws:server>
从这几行就能提炼出一堆关键信息，要是不了解CXF框架的话可以问问ai，这里把ai给出的结论放下面了
| CXF 框架（jaxws + jaxrs） | 支持 SOAP 1.1/1.2，可以 WSDL 发现 |
| — | — |
| address="/webservice/jaxws" | SOAP 端点的 URL 路径 |
| serviceClass="...IWebserviceJaxws" | 「接口类全限定名拿到，可以反编译找所有方法」 |
| AuthInterceptor 作为 inInterceptor | 有一个认证拦截器，但它是「自定义的」，不是标准 Shiro 过滤器链 |
| LoggingInInterceptor | 请求会被记录到日志（后来确实在日志里看到了明文请求） |
com.hst.ces.webservice.IWebserviceJaxws
有了接口类名com.hst.ces.webservice.IWebserviceJaxws，去jar包里找这个class或者接口实现
用IDEA反编译或者jadx一看，这个接口大概暴露了这些方法
getUserinfoListaddUserinfoupdateUserinfodelUserinfogetDepartinfoaddDepartinfodoRoomRightByUserNamedoUserRightByRoomid.....
到这里，一个接口类里几十个方法，其实就有很多潜在的sink，那回头看看鉴权是不是有问题呢，其实这里还存在很多未授权的方法，比如未授权添加用户也是可以的
观察认证逻辑
AuthInterceptor
这里只有提供了有效keyCode的SOAP请求才能访问后续的业务接口，否则直接返回错误码0003，其实这里的keycode是硬编码，后续可以直接用
public class AuthInterceptor extends AbstractPhaseInterceptor<Message> { public void handleMessage(Message message) { // 从 SOAP body 里提取 keyCode 参数 String keyCode = extractKeyCode(message); // 调用验证 String result = KeyCodeCheckout.keyCodeCheckout(keyCode); if (!result.equals("SUCCESS")) { throw new Fault(new QName("0003")); } // 验证通过，放行 }}
而且它只检查keyCode，不检查登录态、session、token、IP，什么都没有，而且keyCode是从请求体里直接取的
三、分析/xxx/webservice/jaxws路由
如何看这个路由是否为前台可以访问的呢，最快的验证方式就是直接访问该路由看返回包状态，如果返回的不是401 Unauthorized，而是返回了业务错误码0003表示，那就说明是前台可以访问的路由，这里拼接路由其实已经可以看到并不是401等状态，待会分析完构造body试试
四、寻找KeyCode
现在知道了接口是前台的，只要搞定keyCode就能打进去。那keyCode其实也很容易找，通过代码跟或者直接找配置文件，这里config.cfg放在 WEB-INF/classes/ 下面，直接跟也不难找
tomcat/webapps/xxx/WEB-INF/classes/config.cfg
打开一看：
#密钥 xxxxxxxkeyCode=xxxxxxx
#分析平台appkey(私有云传固定值)，不区分大小写appkey=xxxxxxx
第一行注释直接把MD5写出来了。第二行的 keyCode=xxxxx2011 就是明文密钥。而且有个appkey和注释里的MD5完全一样，答案已经非常明显了，只要不修改该配置文件那么我们是可以直接拼到请求体当中的keycode参数利用的
五、PoC 怎么构造
5.1 SOAP 请求长什么样？
CXF的SOAP服务一般可以通过WSDL发现
类似这样：https://目标:8443/xxx/webservice/jaxws?wsdl
WSDL会告诉每个方法叫啥名字、参数叫啥、类型是啥、namespace是啥，如果没有WSDL，也能从接口类的注解推断，这里之前恩师也讲过
CXF的标准SOAP envelope格式如下：
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="http://webservice.ces.xxx.com/"> <!-- 这个 namespace 来自接口包名 --> <soapenv:Header/> <soapenv:Body> <web:方法名> <!-- web = namespace 前缀 --> <参数1>值</参数1> <参数2>值</参数2> </web:方法名> </soapenv:Body></soapenv:Envelope>
5.2 getUserinfoList构造
<web:getUserinfoList> <serachType>1</serachType> <keyCode>xxxxxxxxxxxxx</keyCode> //硬编码kecode <currPage>0</currPage> <pageSize>10</pageSize> <serachKey></serachKey> </web:getUserinfoList>
这里我解释一下各个参数名的含义
serachType：方法名叫 getUserinfoList，参数里有个serachType注意它拼错了，是serach不是search，可能是开发手误？然后0、1、2的含义如下：
1 = 按用户名搜索
2 = 按显示名搜索
0 或者不传 = 查全部
keyCode：前面说了，来自于配置文件硬编码
currPage：分页参数，从0开始，传0表示第一页
pageSize：每页返回多少条，先用10试探，确认能返回数据后加大到100一次性拖更多
serachKey：搜索关键词，比如填admin就能查到admin用户的信息
六、漏洞复现
在分析完上面以后，开始尝试构造参数，这里成功拿到目标全部用户的账号密码
把password字段用CMD5解密出来即可进入后台
七、漏洞总结
第一是因为CXF拦截器认证太弱，AuthInterceptor.handleMessage()从请求体里拿keyCode去配置文件比对，如果匹配相同就直接放行，基本上无鉴权，没有session、没有token、没有签名、没有时间戳校验，其次config.cfg 里的 keyCode=xxxx是这个系统的默认值，除非主动改，否则每个系统都一样，而大多数不会改，而且像getUserinfoList能返回所有用户的密码MD5、邮箱、手机号，也没有做任何限制，直接就导致了未授权可以获取所有用户的账号密码。总的来说漏洞不难，考验对框架的熟悉程度，如果不会也可以多学习，当长长见识了。
八、最后
本文当中所提及知识来自实战代码审计班课程内容，关于该产品更加深入利用手法可以咨询课程
顺便再推荐一下我师傅的代码审计课程。近期某报表的课程章节已结束，马上开启新的章节，感兴趣的朋友可以尽快加入。课程中包含各类产品最新补丁对应的 0day 漏洞（非水洞） 的挖掘与分析；过往课程也涵盖多款市面产品的 0day / 1day / nday 漏洞案例讲解。课程后续会持续更新推进，支持一次报名长期学习与答疑。适合真正对代码审计感兴趣、或想系统学习但缺少思路与方法体系的同学（如有其他目的请勿打扰）。对基础要求不高，能读懂代码即可，真正帮助你从只能读懂代码到找到问题。个人学习过程中受益良多，特此分享推荐给希望提升自己的朋友（非广告）。若有打扰，敬请见谅。
下方是进阶班课表
下方是基础班课表
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：红细胞安全实验室 PumpkinBridge PumpkinBridge《【代码审计】某通漏洞审计分析》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论