基于ExtJS框架下的XSS漏洞分析挖掘

admin 2025-12-22 03:59:13 网络安全文章 来源:ZONE.CI 全球网 0 阅读模式

文章总结: 文章分析了ExtJS4.2.x框架中的两个XSS漏洞,POC1通过滥用opendmc.cache.getSystemParam()接口结合Ext.MessageBox渲染机制触发,POC2利用__enum.getStoreData()将恶意内容注入ComboBox下拉框。这些漏洞源于框架默认支持HTML渲染组件的特性,暴露了系统在输入校验输出编码和权限控制方面的缺失。作者建议升级框架版本清理历史数据并建立全流程安全审查机制。 综合评分: 91 文章分类: 漏洞分析,WEB安全,代码审计


cover_image

基于 ExtJS 框架下 的XSS 漏洞分析挖掘

原创

tangkaixing

开心网安

2025年10月10日 14:45 重庆

免责声明

由于传播、利用本公众号开心网安所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,公众号开心网安及作者不为承担任何责任,一旦造成后果请自行承担!如需要转载等,请标注文章来源。如有侵权烦请告知,我们会立即删除并致歉,谢谢!

概述

在某次渗透测试中,进入了一个很老的jsp系统中,发现使用了ExtJS 框架,就想打发时间分析审计js,成功发现了跨站脚本攻击(XSS)漏洞。其中:

POC1为:通过滥用'opendmc.cache.getSystemParam()'接口,结合'Ext.MessageBox'渲染机制触发;POC2为:利用枚举模块'__enum.getStoreData()'将恶意内容注入 ComboBox 下拉框并自动执行。

这两个漏洞均依赖于 ExtJS 4.2.x 版本默认支持 HTML 渲染组件的特性,且暴露了系统在“输入校验”、“输出编码”和“权限控制”方面的多重缺失。本文将从整体逻辑、技术细节、攻击链构造出发,详细阐述两个POC的发现过程、触发原理等,并总结此类漏洞的通用挖掘方法。

正文:漏洞发现全过程剖析

0X1、初始入口:审计发现 opendmc.cache模块

  1. 初始观察:

在分析opendmc.cache.getSystemParam()函数时,注意到其行为模式存在显著风险特征:

if (!rtnParam && !noAlert) {    opendmc.dialog.error("缺少系统参数配置",         Ext.String.format("系统中没有配置 [{0}] 的系统参数,参数名称[{1}]", errParamName, paramName));}
- 使用 `Ext.String.format()` 拼接用户可控字符串;-调用'opendmc.dialog.error()'→ 实际调用 `Ext.MessageBox.show({msg: ...})`;- 关键点:ExtJS 4.2.x 默认允许 msg 字段解析 HTML。📌 这是一个经典的 UI 组件安全盲区:开发者认为“弹窗只是文本提示”,但实际上框架底层默认开启了富文本渲染能力。
  1. 为什么选择构造如下 POC?
opendmc.cache.getSystemParam('<img&nbsp;src=x&nbsp;onerror=confirm("XSS_via_getSystemParam")>', 'Image Param');

构造分析:

paramName&nbsp;和 errParamName 完全由调用者传入;若页面从 URL 获取参数并直接使用,即构成外部可控输入若该参数名不存在,必然进入错误提示流程 → 触发 dialog.error()Ext.MessageBox.msg 在 ExtJS <&nbsp;4.2.3&nbsp;中等价于 innerHTML 输出,支持 <img onload>、<svg> 等自动执行标签onerror= 属于事件处理器,即使插入在双引号属性内也不影响解析(浏览器会自动匹配语法)即使 CSP 存在&nbsp;'unsafe-inline'&nbsp;限制,但图片内联事件通常仍可执行(除非严格禁止)

0X2、深入分析:__enum 枚举模块

  1. 发现阶段:数据绑定与 displayField 的致命结合

在审计 __enum.getStoreData() 函数时,注意其返回结构用于构建 ExtJS 数据源:

data.push({&nbsp;abbr:&nbsp;key,&nbsp;name:&nbsp;(noPrefix?"":"["+key+"]") + value });
随后常用于&nbsp;ComboBox:displayField:&nbsp;'name',valueField:&nbsp;'abbr'
📌 至关重要的一点:ExtJS 的&nbsp;`displayField`&nbsp;默认以&nbsp;HTML&nbsp;方式渲染字段值**(尤其是下拉项列表),这意味着如果&nbsp;`name`&nbsp;包含&nbsp;HTML&nbsp;内容,它将被完整解析执行。

2. 为什么构造如下 POC?

// 强制设置一个危险枚举__enum.enums['TEST_XSS'] = [&nbsp; &nbsp; {codeId:&nbsp;'EVIL', codeValue:&nbsp;'<img src=x onerror=alert(document.domain)>'}];var&nbsp;testData = __enum.getStoreData('TEST_XSS');var&nbsp;combo = Ext.create('Ext.form.ComboBox', {&nbsp;&nbsp;&nbsp; store: Ext.create('Ext.data.Store', {&nbsp;fields: ['abbr','name'],&nbsp;data: testData }),&nbsp;&nbsp;&nbsp; displayField:&nbsp;'name', &nbsp; // ← 此处是 XSS 触发点&nbsp;&nbsp;&nbsp; valueField:&nbsp;'abbr',&nbsp;&nbsp;&nbsp; renderTo: Ext.getBody()});

构造分析:
因为管理员后台允许手动录入 codeValue(如“状态描述”),而未做过滤 → 攻击者可写入恶意 HTML__enum.enums[codeGroup] 将数据缓存在内存中,刷新前一直有效 → 实现“一次注入、多次触发”getStoreData() 自动拼接成 {name: "[EVIL]<img&nbsp;...>"} → 赋给 displayField 后被 ExtJS 当作 HTML 解析只需打开下拉框(甚至 hover),<img&nbsp;src=fail&nbsp;onerror>&nbsp;即触发脚本
攻击链条完整分析:
[写入恶意 codeValue]&nbsp;&nbsp; &nbsp; →&nbsp;[前端调用 getEnum 返回污染数据]&nbsp; &nbsp; →&nbsp;[生成 Store 数据包含 HTML payload]&nbsp; &nbsp; →&nbsp;[渲染 ComboBox → 显示下拉项]&nbsp; &nbsp; →&nbsp;[浏览器加载图片失败 → 触发 onerror → 执行 JS]

总结分析:

1、ExtJS 数据绑定机制的本质风险:

  • 组件不区分 “纯文本字段” 与 “HTML 字段”;

  • displayField, tpl, html 都统一处理为可能含 HTML 的内容;

  • 开发者常常忽略这一隐式行为,默认以为 text: “hello” 是安全的;

  • 即使原始数据来自 AJAX 请求,只要服务端没过滤,前端又不做转义,就等于开了“后门”;

  • 都依赖 ExtJS 旧版本的安全缺陷;

  • 都利用了“前端组件自动渲染 HTML”的特性;

  • 都规避了传统 DOM-based XSS 检测规则;

  • 均属于 XSS 攻击,非 self-XSS,具备真实可利用性。

2、ExtJS 4.2.1 的历史性漏洞土壤

console.log(Ext.version&nbsp;||&nbsp;Ext.getVersion?.());// 输出:{ version: "4.2.1.883" }

查证官方文档和公开 CVE 记录可知:

ExtJS 4.2.x版本的MessageBox\ComboBox\GridCellRenderer等组件默认开启HTML内容渲染,直到 4.2.3+ 才引入部分防护措施。

📌 因此,在该版本下:

  • 所有涉及“动态内容显示”的字段都应视为潜在 XSS 输出点;
  • 必须显式转义才能保证安全;
  • 而本系统的多个模块恰恰忽略了这一点。

3、挖掘此类漏洞的技巧与原理

| 方法 | 描述 | | — | — | | 查找“错误提示函数” | 如 dialog.error()showMessage(),关注其是否接收动态参数 | | 审计“数据转换函数” | 如 list2MapgetStoreData,看是否有字符串拼接用于 UI | | 搜索关键词 | "format""innerHTML""Ext\.create""store""displayField" | | 关注同步 Ajax 调用 | async: false 的接口更可能被滥用(阻塞执行、便于构造) |

结语:

     本次发现的两个 XSS 漏洞虽形式不同,本质却相同:现代 Web 安全不仅是“防 script 标签”,更是“防任何动态内容进入可渲染上下文”。尤其在使用 ExtJS、Dojo 等重型前端框架的老系统中,组件级的HTML渲染能力是一把双刃剑。一旦缺乏安全治理,极易成为突破口。

建议所有类似系统立即开展三项工作:

  1. 升级前端框架版本;
  2. 全面清理历史数据中的恶意内容;
  3. 建立“输入-处理-输出”全流程安全审查机制。

部分知识参考来源如下:

https://www.sencha.com/forum/showthread.php?263287-HTMl-in-ComboBox-displayFieldhttps://stackoverflow.com/questions/20897899/how-to-show-html-text-in-extjs-comboboxhttps://docs.sencha.com/extjs/4.2.1/#%21/api/Ext.grid.column.Column-cfg-rendererhttps://docs.sencha.com/extjs/4.2.1/#%21/docs/api/Ext.MessageBoxhttps://portswigger.net/web-security/cross-site-scripting/dom-basedhttps://owasp.org/www-project-client-side-security/

查看原文:《基于 ExtJS 框架下 的XSS 漏洞分析挖掘》

Ollvm混淆还原学习 网络安全文章

Ollvm混淆还原学习

文章总结: 本文深入分析了OLLVM混淆技术的两种核心方法:虚假控制流(BCF)和控制流平坦化(FLA/CFF),并提供了多种去混淆实战方法。BCF通过插入不透
评论:0   参与:  0