从ezOFFICE漏洞复现看SQL注入原理与防御实践

1. 项目概述：从一次内部渗透测试说起

前段时间，公司安排了一次针对内部办公系统的渗透测试，目标系统里恰好有一套万户网络的ezOFFICE协同办公平台。这类OA系统在企业里太常见了，往往承载着核心的审批流程和文档数据，一旦出问题，后果不堪设想。在常规的资产梳理和端口扫描之后，我开始对Web应用层进行手工测试，一个名为wf_accessory_delete.jsp的接口引起了我的注意。从文件名看，它负责处理流程附件删除，这种涉及数据库增删改查的操作，向来是SQL注入漏洞的高发区。果不其然，经过一番测试，成功复现了一个可直接获取数据库信息的注入点。这不是一个孤立的案例，它非常典型地反映了老旧OA系统，或者说许多基于JSP+JDBC传统架构的应用中，由于参数过滤不严、拼接SQL语句等开发陋习所导致的普遍安全问题。今天，我就把这个漏洞的复现过程、原理分析和实战中的思考，完整地拆解一遍。无论你是刚入门的安全爱好者，想通过一个真实案例理解SQL注入；还是负责运维这类系统的工程师，需要排查风险，这篇文章都能给你提供清晰的路径和可操作的思路。

2. 漏洞原理与背景深度剖析

2.1 ezOFFICE系统与漏洞接口定位

万户ezOFFICE是一个历史比较悠久的协同办公平台，广泛应用于政府、企事业单位。其架构通常是经典的B/S模式，后端使用JSP/Servlet，数据库多为Oracle或SQL Server。wf_accessory_delete.jsp这个文件，从路径和命名习惯来看，属于工作流（Workflow）模块的一部分，功能是删除流程实例相关的附件。

在传统JSP开发中，特别是十多年前的代码，开发者为了图方便，经常采用字符串拼接的方式来构造SQL语句。例如，从请求中获取一个附件ID参数，直接拼接到DELETE语句中。代码原型可能简化如下：

<% String accessoryId = request.getParameter("accessoryId"); String sql = "DELETE FROM WF_ACCESSORY WHERE ID='" + accessoryId + "'"; // 然后执行这个sql... %>

这就是最经典的“错误示范”。攻击者完全可以通过控制accessoryId这个参数，注入额外的SQL逻辑，改变原语句的语义。

2.2 SQL注入漏洞的核心成因与危害

这个漏洞的本质是“信任了不可信的输入”。应用程序没有对用户传入的accessoryId参数进行有效的校验、过滤或转义，就直接将其作为SQL语句的一部分执行。这违背了信息安全最基本的原则之一。

它的危害程度通常是“高危”：

1. 数据泄露：这是最直接的危害。利用联合查询（UNION SELECT），攻击者可以读取数据库中的任何数据，包括用户表、权限表、流程表单数据，甚至是管理员密码的哈希值。
2. 数据篡改：通过注入UPDATE或INSERT语句，可以非法修改或添加数据，例如给自己提升权限、篡改审批结果。
3. 数据删除：正如这个接口的本意是删除，注入恶意语句可能导致大规模数据丢失（DROP TABLE）。
4. 进一步渗透：在某些配置下（如数据库支持多语句执行、具有写权限），可能通过注入向服务器写入Webshell，从而获取服务器控制权，实现从“注入”到“getshell”的突破。

这个漏洞的利用门槛相对较低，因为注入点明显（参数在URL或表单中），且利用工具（如sqlmap）成熟，使得即使初级攻击者也可能造成严重破坏。

2.3 手工注入与工具利用的思维差异

在复现和测试时，我们通常会交替使用手工和工具两种方式，它们的目的和思维不同：

• 手工注入：目的是理解漏洞。通过一步步添加单引号、注释符、逻辑判断（如and 1=1/and 1=2），来确认注入点类型、判断数据库类型、推测后端SQL语句结构。这个过程能让你深刻理解漏洞原理，也是应对一些简单WAF或过滤规则的基础。
• 工具利用（如sqlmap）：目的是高效利用。在确认存在注入后，使用sqlmap可以自动化地完成数据库名枚举、表名、列名暴破以及数据拖取，极大提升效率。但切忌一上来就丢给sqlmap，那样会让你错过理解漏洞细节的机会。

在本次复现中，我将结合两者，先手工验证漏洞存在，再使用sqlmap进行深度利用，最后分析防御之道。

3. 漏洞复现环境搭建与手工验证

3.1 实验环境准备

为了安全、合法地复现，必须在隔离环境中进行。

1. 靶机环境：我使用了一台Windows Server 2008 R2的虚拟机，安装了受影响版本的万户ezOFFICE（例如某个历史版本）。确保其数据库（如SQL Server）服务正常启动。
2. 攻击机环境：使用Kali Linux虚拟机，或任何安装了浏览器、Burp Suite、sqlmap的Linux/Windows系统。
3. 网络配置：将两台虚拟机置于同一NAT或仅主机网络模式，确保可以互相访问。记录下靶机的IP地址，例如192.168.1.100。
4. 浏览器与代理：在攻击机上配置浏览器（如Firefox）使用Burp Suite作为代理（默认127.0.0.1:8080），以便拦截和修改HTTP请求。

注意：所有操作必须在您拥有完全权限的测试环境或获得明确授权的范围内进行。未经授权对任何系统进行测试均属违法行为。

3.2 手工探测与注入点确认

首先，我们需要找到wf_accessory_delete.jsp的访问路径和参数。通过查阅资料或对类似系统的了解，其URL可能形如：http://192.168.1.100:8080/ezoffice/wf_accessory_delete.jsp。

第一步：基础请求与响应观察用浏览器直接访问该URL，可能会返回一个错误页面，提示“参数缺失”或直接显示SQL错误。这本身就是一个线索。更常见的情况是，它需要接收参数。我们尝试通过Burp Suite拦截一个正常的附件删除操作（如果有前端界面的话），或者直接构造请求。

假设我们发现它需要一个id参数。我们发送第一个探测请求：

GET /ezoffice/wf_accessory_delete.jsp?id=1 HTTP/1.1 Host: 192.168.1.100:8080

观察响应。如果页面正常返回（可能是空白页或“删除成功”），说明参数有效。

第二步：注入点初步判断我们开始注入测试。经典的第一步是添加一个单引号'，用于破坏原SQL语句的语法。

GET /ezoffice/wf_accessory_delete.jsp?id=1' HTTP/1.1

• 情况A：页面返回了数据库错误信息，例如“Microsoft OLE DB Provider for SQL Server 错误 '80040e14'...字符串 '' 后的引号不完整”。这强烈暗示我们的输入被直接拼接到SQL语句中，并且引发了语法错误。
• 情况B：页面返回了通用的错误页或空白页，与id=1和id=1'的响应有明显差异。这也暗示可能存在注入。

第三步：确认注入点类型与可注入性接下来，我们使用逻辑测试来确认。

1. 数字型注入测试：如果原语句是WHERE ID=1，构造id=1 and 1=1和id=1 and 1=2。

   GET /ezoffice/wf_accessory_delete.jsp?id=1 and 1=1 HTTP/1.1 GET /ezoffice/wf_accessory_delete.jsp?id=1 and 1=2 HTTP/1.1

   • 如果and 1=1返回正常页面（真条件），而and 1=2返回错误或异常页面（假条件），则基本可以断定是数字型注入，且漏洞存在。
2. 字符型注入测试：如果原语句是WHERE ID='1'，我们需要闭合单引号。构造id=1' and '1'='1和id=1' and '1'='2。

   GET /ezoffice/wf_accessory_delete.jsp?id=1' and '1'='1 HTTP/1.1 GET /ezoffice/wf_accessory_delete.jsp?id=1' and '1'='2 HTTP/1.1

   • 同样观察真/假条件下页面的差异。对于本例中的wf_accessory_delete.jsp，根据经验，它很可能是字符型注入，因为主键ID常被包裹在单引号中。

在我的测试中，使用id=1' and '1'='1返回了正常状态，而id=1' and '1'='2则返回了错误或内容缺失。这成功确认了字符型SQL注入漏洞的存在。

第四步：判断数据库类型不同的数据库，其注释语法、函数名不同。一个快速判断的方法是使用数据库特有的函数。

• SQL Server：尝试id=1' and @@version>0--。@@version是SQL Server的系统变量，--是注释符，用于注释掉原SQL语句后面的单引号。如果页面正常，很可能是SQL Server。
• MySQL：尝试id=1' and version()>0--或id=1' and sleep(5)--观察响应延迟。
• Oracle：尝试id=1' and 1=(select 1 from dual)--。

通过测试id=1' and @@version>0--页面正常，我判断后端数据库是 Microsoft SQL Server。

4. 利用sqlmap进行自动化深度利用

手工确认漏洞后，我们可以使用sqlmap这个神器来自动化、深度地利用该漏洞，获取数据库信息。

4.1 sqlmap基础扫描与数据库信息获取

首先，将Burp Suite拦截到的含有id参数的完整HTTP请求保存到一个文本文件中，比如req.txt。这样能保留Cookie、User-Agent等头部信息，对于需要登录认证的系统至关重要。

第一步：检测注入点并获取当前数据库

sqlmap -r req.txt --batch --current-db

• -r req.txt: 从文件加载HTTP请求。
• --batch: 以非交互模式运行，所有提示都选择默认值，适合自动化。
• --current-db: 获取当前应用使用的数据库名。 执行后，sqlmap会先确认注入点类型和数据库，然后输出当前数据库名，例如ezoffice_db。

第二步：枚举数据库中的所有表

sqlmap -r req.txt --batch -D ezoffice_db --tables

• -D ezoffice_db: 指定目标数据库。
• --tables: 枚举该数据库下的所有表。 输出结果可能会包含数十张表，我们需要关注用户、权限、流程相关的表，如sys_user,wf_process,oa_document等。

第三步：暴破指定表的列名假设我们对sys_user表感兴趣，里面很可能存放了用户名和密码。

sqlmap -r req.txt --batch -D ezoffice_db -T sys_user --columns

• -T sys_user: 指定目标表。
• --columns: 枚举该表的所有列名。 输出会显示列名和数据类型，例如user_id(int),login_name(varchar),password(varchar),real_name(varchar) 等。

第四步：拖取表数据

sqlmap -r req.txt --batch -D ezoffice_db -T sys_user -C "login_name,password,real_name" --dump

• -C "login_name,password,real_name": 指定要导出的列。
• --dump: 导出数据。 sqlmap会将表中的数据以表格形式输出到终端，并询问是否将哈希值（如果密码是加密的）保存到本地进行破解。这时，我们就获得了系统的用户凭证信息。密码字段可能是明文、MD5哈希或其他加密方式。如果是MD5，可以尝试在线网站或本地用hashcat进行破解。

4.2 高级利用技巧与规避策略

在实际渗透测试中，可能会遇到一些阻碍，需要调整sqlmap的策略。

1. 延迟与时间盲注：如果目标页面没有明显的真假差异（即布尔盲注），但注入存在，sqlmap会自动尝试时间盲注，通过and sleep(5)这类语句观察响应延迟。我们可以手动指定技术：

   sqlmap -r req.txt --batch --technique=T

   --technique=T指定使用基于时间的盲注。

2. 绕过简单的WAF/过滤：一些系统可能有简单的关键词过滤。

   • 使用随机User-Agent和代理：--random-agent和--proxy=http://your-proxy:port。
   • 使用tamper脚本：sqlmap的tamper/目录下有很多脚本，可以对payload进行混淆。例如，space2comment将空格替换为/**/，between用BETWEEN替换>比较符。

   sqlmap -r req.txt --batch --tamper=space2comment,between

   • 降低风险等级：--risk参数（1-3）控制测试的风险，等级越高，使用的payload越可能破坏数据或引起注意。--level参数（1-5）控制测试的深度。在需要隐蔽时，可以从低等级开始。

3. 获取操作系统Shell（谨慎！）：如果数据库用户权限足够高（如sa），并且目标系统支持，理论上可以通过sqlmap尝试获取操作系统权限。但这在真实测试中风险极高，极易造成破坏，仅在完全可控的测试环境且有必要时尝试。

   sqlmap -r req.txt --batch --os-shell

   这个命令会尝试上传一个用于执行命令的代理。成功率取决于数据库配置、权限和杀毒软件等多重因素。

实操心得：使用sqlmap时，--batch模式虽然方便，但在复杂环境或需要选择时，去掉它进行交互式操作更稳妥。另外，-v参数可以调整输出详细程度（0-6），-v 3可以查看发送的payload，对于学习payload构造和调试非常有用。

5. 漏洞根因分析与安全编码实践

复现和利用漏洞不是终点，理解其根源并知道如何修复和预防，才是安全工作的价值所在。

5.1 漏洞代码还原与错误模式

我们可以大胆推测wf_accessory_delete.jsp漏洞代码的原始模样：

<% Connection conn = ... // 获取数据库连接 Statement stmt = null; try { String id = request.getParameter("id"); // 直接获取用户输入 // 致命错误：直接拼接字符串 String sql = "DELETE FROM wf_accessory WHERE accessory_id = '" + id + "'"; stmt = conn.createStatement(); int count = stmt.executeUpdate(sql); if(count > 0) { out.println("删除成功！"); } else { out.println("附件不存在。"); } } catch (SQLException e) { e.printStackTrace(); // 另一个错误：将详细错误信息暴露给用户 out.println("系统错误，请联系管理员。"); } finally { // 关闭资源... } %>

这段代码犯了两个关键错误：

1. 未过滤的字符串拼接：用户输入的id直接拼接到SQL语句中。
2. 详细的错误回显：将SQL异常堆栈打印出来，为攻击者提供了判断注入是否成功的直接依据。

5.2 根本解决方案：参数化查询（预编译语句）

这是防御SQL注入最有效、最根本的方法。以Java JDBC为例，修复后的代码应如下：

Connection conn = ... // 获取数据库连接 PreparedStatement pstmt = null; try { String id = request.getParameter("id"); // 使用 ? 作为参数占位符 String sql = "DELETE FROM wf_accessory WHERE accessory_id = ?"; pstmt = conn.prepareStatement(sql); // 将参数安全地设置进去，JDBC驱动会负责类型检查和转义 pstmt.setString(1, id); int count = pstmt.executeUpdate(); // ... 处理结果 } catch (SQLException e) { // 记录日志到服务器文件，而非返回给客户端 logger.error("删除附件时数据库错误", e); out.println("操作失败，请重试。"); // 返回模糊的通用错误信息 } finally { // 关闭资源... }

为什么参数化查询能防注入？因为SQL语句（DELETE ... WHERE accessory_id = ?）在数据库端是先被编译的，编译确定了语句的逻辑结构。后续传入的参数id，无论其内容是什么（即使包含'、or、--），都会被数据库引擎视为纯粹的“数据值”，而不会被重新解释为SQL“语法”。这就从根本上切断了注入的可能性。

5.3 多层防御与最佳实践

除了核心的参数化查询，还应建立纵深防御体系：

1. 输入验证与过滤：在业务逻辑层，对id参数进行严格校验。例如，确认它是否为预期的数字格式。

   if (id == null || !id.matches("\\d+")) { // 立即返回错误，不进行后续数据库操作 throw new IllegalArgumentException("无效的附件ID"); }

2. 最小权限原则：连接数据库的应用程序账号，不应使用sa或root等超级管理员权限。应为其创建仅具备必要操作权限（如对特定表的SELECT, UPDATE, DELETE）的专用账号。这样即使发生注入，危害也能被限制。
3. 避免详细错误信息：在生产环境中，务必关闭向客户端显示详细数据库错误信息的功能。应使用统一的、模糊的错误处理页面，并将详细错误记录到服务器的安全日志中供管理员排查。
4. 使用Web应用防火墙（WAF）：在应用前端部署WAF，可以拦截常见的SQL注入攻击特征，作为一道有效的边界防护。但切记，WAF是“缓解”措施，而非“根治”方案，不能替代安全的代码。
5. 定期安全审计与更新：对老旧系统（如本文的ezOFFICE）的代码进行安全审计，或及时更新到官方已修复漏洞的版本。对于不再维护的系统，应考虑升级或替换。

6. 拓展思考：从漏洞复现到安全测试体系

复现一个SQL注入漏洞，不应该是一个孤立的动作。它应该被纳入一个更完整的安全测试流程中。

1. 信息收集阶段：不仅仅是IP和端口，更要关注应用框架（如Struts2、Spring）、中间件版本、已知的公开漏洞（CVE）。对于ezOFFICE，可以搜索其历史CVE编号。
2. 漏洞扫描与手动验证：使用AWVS、Nessus等工具进行初步扫描，但所有工具结果都必须经过手动验证，以排除误报。手工测试更能发现逻辑漏洞和工具无法识别的复杂注入点。
3. 权限提升与横向移动：获取数据库数据（如密码哈希）后，如果破解了管理员密码，应测试是否能登录后台，并尝试从后台功能点寻找文件上传、命令执行等漏洞，实现权限提升。在内部网络，还可能尝试从数据库服务器连接到其他内网主机。
4. 报告编写：一份好的渗透测试报告，不仅要有漏洞详情（URL、参数、Payload、截图），更要有清晰的风险等级评估（CVSS评分）、详细的漏洞原理说明、具体的修复建议（提供修复代码示例）以及可能造成的业务影响分析。

这个wf_accessory_delete.jsp漏洞，就像一面镜子，照见了许多传统企业应用在安全开发生命周期（SDLC）上的缺失。对开发者而言，它是安全编码意识的一课；对运维和安全人员而言，它是资产风险排查的一个典型入口。在实战中，保持好奇心，对每一个用户输入点都抱有一丝怀疑，同时掌握原理、善用工具、遵循流程，才能构筑起有效的应用安全防线。