DataGear 源码审计记录：我重点看了两条危险链

因为它不是在理解SQL 方言函数语义语法树结构数据库能力边界它只是拿一段字符串做边界猜测。所以这种设计最容易出现的情况就是你以为自己拦的是危险能力 实际上你拦住的只是“某个单词长得像危险能力的写法”。3.4 风险落点文件读取能力如果后端数据库支持对应文件读取函数并且数据库账号权限没有收住风险就可能进一步落到文件读取。但这个地方也不能写飘。是否能真正读到文件至少还要看条件影响数据库类型是否支持相应文件读取函数账号权限当前数据库账号是否具备相应能力文件可读性目标路径是否对数据库进程可读接口可达性SQL 预览能力是否对当前用户开放所以更稳妥的表达是这条链说明系统试图用关键字黑名单限制高危 SQL 能力但边界规则本身存在缺口在满足数据库能力和权限条件时风险可以进一步落到文件读取。3.5 修这类问题别再只修正则如果这里只是继续补黑名单很大概率还会被别的写法绕过去。更稳的方向是方向建议能力限制针对具体数据库类型做能力级限制权限最小化预览 SQL 使用单独的低权限账号白名单能白名单就不要继续赌黑名单结构化解析能做 AST、模板化或结构化约束就不要只做字符串匹配审计对 SQL 预览、查询测试、导出等能力做单独高风险日志4. 把两条链放在一起看如果把这次记的两条链放在一起其实就是两类典型后台风险第一类上传 / 驱动 / 插件 / 模板 - 最终进入解释器、类加载器或执行链第二类校验看起来做了很多 - 但本质只是字符串黑名单 - 稍微换个写法就能从边上绕过去这两类点在后台系统里都很常见而且都特别容易被埋在“辅助能力”里测试连接SQL 预览导入导出驱动管理模板预览调试接口名字都很日常链路往下一跟碰到的却是类加载、文件读取、命令执行、外联能力这些真正的安全边界。5. 如果我是防守方我会先翻什么如果后面真要收这两个点我会优先检查这些问题。5.1 对 driver 这条线上传的 jar 最终是不是直接进了可加载路径driver上传和普通数据源管理是不是混在一套权限里testConnection是否在主应用上下文里直接完成类加载是否存在 driver 上传、driver 变更、测试连接的单独审计日志历史上有没有异常 jar 上传或异常驱动变更5.2 对 SQL 预览这条线现在是不是还在用关键字黑名单硬拦数据库类型是否做了分开能力限制预览 SQL 用的数据库账号是不是单独降权过文件读取、命令执行、外联这类能力是不是默认就在预览 / 测试 / 查询类接口有没有高风险审计很多时候问题不在系统“看起来危险”而在这些地方根本长期没人翻。6. 结论这次先记两条一条是driver上传最后接到了类加载边界一条是 SQL 黑名单被函数名边界绕过去风险能继续落到文件读取我更想强调的不是“哪一个点单独看起来很吓人”而是后台系统里很多真正危险的能力并不挂在“执行命令”这种显眼名字上而是挂在“测试连接”“SQL预览”“兼容更多数据库”“方便管理员操作”这类日常功能里。如果后面继续翻这类平台我自己会持续优先看两件事外部对象最后会不会进入解释器、类加载器或执行链安全校验到底是在理解能力边界还是只是在做字符串猜测这两类问题往往比一个单点漏洞编号更能决定系统后面的真实风险。备注这篇记录不包含 weaponized 利用代码也不对真实环境可利用性作过度结论。如果团队正在使用类似后台平台可以先做三件实事清点谁能上传 driver、谁能测试连接、谁能执行 SQL 预览回看日志里是否有异常 jar 变更、异常连接测试、异常 SQL 预览检查这类管理面能力是不是已经很久没有被单独做过安全审计原文https://mp.weixin.qq.com/s/x479lRHOrU0hVixOmQtX0g