《Applied Sciences》：SQLSnoop: Secondary DBMS Attack by Expanding SQL Injection Techniques
编辑推荐：
SQL注入（SQL Injection）是Web应用中长期存在的一类广为人知的漏洞。开发人员普遍持有一种假设：即便存在SQL注入漏洞，若使用数据库管理系统（DBMS）内置的密码学函数（如sha256()或md5()）对敏感数据进行哈希（Hash）或加密存储，被
SQL注入（SQL Injection）是Web应用中长期存在的一类广为人知的漏洞。开发人员普遍持有一种假设：即便存在SQL注入漏洞，若使用数据库管理系统（DBMS）内置的密码学函数（如sha256()或md5()）对敏感数据进行哈希（Hash）或加密存储，被窃取的数据也将因无法逆向而安全。本文直接挑战该假设。研究人员演示了在SQL语句中调用密码学函数并不能保护明文凭据免受已获得SQL注入权限的攻击者——并非因为哈希函数本身脆弱，而是因为其明文参数在哈希函数执行前会短暂暴露于DBMS的内存监控视图（In-memory Monitoring View）中。研究人员利用此时间窗口，提出一种称为SQLSnoop的技术，通过复用SQL内置循环结构在单条注入语句内高频轮询（Poll）监控视图。研究人员在MySQL、MSSQL、Oracle和PostgreSQL四大主流关系型数据库管理系统（RDBMS）上演示了SQLSnoop。其中MySQL进行了系统的定量评估，MSSQL、Oracle和PostgreSQL则通过针对各自内存监控视图的概念验证（Proof-of-Concept, PoC）实现确认了可行性。MySQL评估显示攻击成功率（Attack Success Rate）稳定高于90%，在分配1.2个及以上虚拟CPU（vCPU）核心时可达100%，且在所有四种数据操纵语言（Data Manipulation Language, DML）操作（INSERT、SELECT、UPDATE、DELETE）中均成立。关键实践意义在于：仅靠SQL层哈希无法防御SQL注入带来的凭据泄露，敏感数据必须在构造SQL语句之前于应用层（Application Layer）完成哈希运算。
《SQLSnoop：基于SQL注入扩展技术对二级DBMS的攻击》论文解读
一、研究背景与意义
SQL注入（SQL Injection）数十年来始终是Web应用安全的持久性威胁，Open Web Application Security Project（OWASP）将其列为Top 10安全风险之一。当前广泛接受的防御惯例是：即便数据库被SQL注入攻破，只要敏感数据（如密码）以哈希或加密形式存储于DBMS中便安全，开发者常利用DBMS内置函数如MD5()、SHA256()在SQL语句内直接对明文进行哈希后存储（即数据库端哈希）。本文挑战此惯例——研究发现，当含明文参数的SQL语句进入DBMS执行前，会被写入内存监控视图（如MySQL的INFORMATION_SCHEMA.PROCESSLIST、MSSQL的sys.dm_exec_requests、Oracle的V$SQL、PostgreSQL的pg_stat_activity），此时哈希函数尚未执行，明文短暂可见。若攻击者借SQL注入注入循环查询高频读取该视图，即可在哈希运算前截获明文凭据。此攻击不破坏密码学原语，而是利用查询处理流水线中的时序泄露窗口。该论文发表于《Applied Sciences》，揭示了"数据库端哈希"这一常见做法在SQL注入场景下的根本性缺陷，明确要求在应用层（Application Layer）先行哈希方为有效防护。
二、主要关键技术方法
研究人员搭建基于Docker的实验环境，含attack（攻击机）、user（受害用户）、backend（后端Spring Boot应用模拟SQL注入后门）、database（MySQL/MSSQL/Oracle/PostgreSQL官方镜像）四个容器。针对各DBMS分别构造SQLSnoop注入载荷（Payload）：MySQL利用BENCHMARK()函数驱动循环轮询INFORMATION_SCHEMA.PROCESSLIST并用GROUP_CONCAT()拼接结果，过滤自身条目；MSSQL利用REPLICATE()结合CROSS APPLY与sys.dm_exec_sql_text()；PostgreSQL利用GENERATE_SERIES()轮询pg_stat_activity并以PG_BACKEND_PID()排重；Oracle利用CONNECT BY LEVEL循环查询V$SQL并用LISTAGG()聚合。受害端并发提交含明文密码作数据库端哈希函数参数的DML语句（INSERT/SELECT/UPDATE/DELETE），攻击端预先启动载荷持续嗅探视图。定量评估以MySQL为平台，样本量每实验1000条SQL语句，重复30次取均值与标准差，变量控制包括MySQL版本（5.5/5.6/5.7/8.0）、vCPU核数（0.1–2.0）、数据表行数（1至106）、SQL语句长度（插入含变长BLOB字段），计算攻击成功率（成功拦截条数/总执行条数）。
三、研究结果
5.1. Attack Success Rate（攻击成功率定义）
研究人员定义攻击成功率为被SQLSnoop成功截获的SQL语句数与执行的总SQL语句数之比，每轮实验执行1000条含数据库端哈希的SQL语句并重复30次以统计均值与标准差。
5.2. Attack Success Rate Depending on MySQL Version（不同MySQL版本的攻击成功率）
在固定vCore配置下测试MySQL 5.5、5.6、5.7及8.0，结果显示各版本攻击成功率均稳定超过90%，仅配0.5 vCore时已超90%，配1.5 vCore时全部达100%，标准差随资源增多趋零。表明该漏洞具架构性而非版本特异性，无法通过常规DBMS升级修补。
5.3. Attack Success Rate Depending on the Number of vCores Allocated to the Database Container（不同vCore分配下的攻击成功率）
变更数据库容器vCore分配（0.1–2.0 vCore），成功率随vCore增加单调上升，约1.2 vCore时达完美100%。即便仅有0.1 vCore约束下成功率仍达约85.94%。CPU利用率观测显示活跃SQLSnoop可占约117%单核CPU，高迭代可能触发数据库活动监控（Database Activity Monitoring, DAM）告警；攻击者可在低迭代下权衡隐蔽性与成功率。
5.4. Attack Success Rate Depending on the Execution Time of Statements（受语句执行时间影响的攻击成功率）
对不同规模（1至106行）用户表的SELECT语句测试，分配2 vCore条件下无论表大小攻击成功率均为100%。说明在充足轮询频率下，即使瞬时执行的SQL也能被可靠截获。
5.5. Attack Success Rate Depending on the Length of SQL Statements（受SQL语句长度影响的攻击成功率）
对含变长BLOB字段的INSERT语句，少量（10条）插入时不随BLOB增大下降（保持100%）；大量（100/1000条）插入且BLOB增大时，因捕获结果字符串拼接导致轮询间隔拉长，成功率显著下降（1000条插入BLOB 10KB时降至约42.74%）。提示攻击者应校准迭代次数防结果堆积影响轮询密度。
四、讨论与结论翻译
研究人员指出SQLSnoop需以存在可执行业务循环/子查询的完整SQL注入为前提，受限SQL注入点可能无法实施；SQLite默认不缓存运行中SQL于视图故不受影响，NoSQL与云托管数据库如屏蔽管理视图亦可能限制利用；Oracle需SELECT_CATALOG_ROLE权限访问V$SQL；定量评估限于MySQL，其余三平台已通过PoC验证可行性。结论如下：
本研究提出SQLSnoop——一种利用SQL注入绕过数据库端密码学保护的攻击技术，证明在SQL语句中调用DBMS内置哈希/加密函数不足以在SQL注入场景下保护敏感数据。SQLSnoop利用现代RDBMS在执行期间暂存SQL语句的内存监控视图，通过注入载荷轮询该视图截获哈希函数执行前的明文参数。研究人员在MySQL、MSSQL、Oracle和PostgreSQL上演示了此攻击；MySQL系统评估显示攻击成功率稳定高于90%，1.2及以上vCore时达100%，且适用于全部四类DML操作。对各主流平台可行性均已通过概念验证确认。实践指导为：敏感数据必须在应用层完成哈希后再构造SQL语句传至数据库，方能防御此类攻击。
