Python中如何编写自动化用例检测API的SQL注入漏洞-mysql教程-PHP中文网

SQL注入检测核心是观察响应差异而非触发报错：通过状态码、响应长度、关键词、延时或布尔真假变化判断，需结合参数上下文、绕过WAF变形及多手法一致性验证，避免误判业务逻辑干扰。

python中如何编写自动化用例检测api的sql注入漏洞

用 `requests` 发送带恶意 payload 的请求，但别直接拼接 SQL

检测 SQL 注入不是靠“让后端崩掉”，而是观察响应差异（状态码、响应体长度、关键词如 mysql_fetch、ORA-00936）、响应时间突增，或布尔盲注时的真假差异。直接在 URL 或 body 里硬塞 ' OR 1=1-- 并不可靠——很多框架会自动转义或拦截，且现代 WAF 会直接拦截含 --、UNION SELECT 的请求。

实操建议：

优先使用参数化方式构造 payload：比如把 id=1 改成 id=1' AND SLEEP(3)--，但要确保该参数确实参与 SQL 拼接（需先做基础路径/参数探测）
避免全量 fuzz：聚焦已知接口参数，例如 /api/user?uid=1 中的 uid，而不是对所有 query 参数无差别注入
设置超时（timeout=(3, 7)），防止因 SLEEP() 类 payload 卡死整个测试流程
记录原始响应哈希（hashlib.md5(r.content).hexdigest()），便于比对布尔盲注中真假响应是否一致

用 `sqlmap --batch --level=3 --risk=2` 做快速验证，但别当主力扫描器

sqlmap 是验证阶段的高效工具，不是自动化用例的组成部分。把它嵌进 Python 脚本里调用（subprocess.run）容易失控：输出难解析、进程卡死、权限问题、无法细粒度控制 payload 类型（比如只想测 time-based，不想触发 error-based）。

实操建议：

只在发现疑似漏洞后，用 sqlmap -u "http://x/api/user?id=1" --batch --technique=T --threads=2 快速确认 time-based 是否成立
禁用 --os-shell 和 --dump 等高危选项，避免误伤生产环境
不要在 CI/CD 流水线中调用 sqlmap：它依赖大量本地规则和指纹库，不同机器行为不一致，且无标准退出码语义

写布尔盲注逻辑时，必须区分 `AND` 和 `OR` 上下文

同一个 payload 在不同 SQL 位置表现完全不同。例如后端语句是 SELECT * FROM users WHERE id = $_GET['id']，那么 id=1 AND 1=1 返回正常数据，id=1 AND 1=2 返回空；但如果语句是 SELECT * FROM users WHERE active = 1 AND id = $_GET['id']，那 id=1 AND 1=2 会让整条 WHERE 失效，可能返回 0 行——这不等于漏洞存在，只是逻辑覆盖变了。

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

实操建议：

先用 id=1 和 id=999999 确认正常业务返回差异（比如 HTTP 200 vs 404，或 JSON 中 "data": [] vs "data": [{...}]）
布尔盲注 payload 必须保持原有查询结构：比如原参数在 WHERE 子句末尾，就用 1 AND 1=1 / 1 AND 1=2；若在中间，可能得补 AND 1=1 来闭合
用正则匹配响应体中的稳定标识，比如 r'"status":\s*"success"'，而不是依赖响应长度（压缩、CDN、日志注入都可能导致长度抖动）

绕过简单 WAF 时，优先用大小写混写和内联注释，别碰编码

URL 编码（%27）、Unicode 编码（\u0027）在多数 WAF 规则里早被归一化处理了，反而增加误报；而 SeLeCt、UnIoN/**/SeLeCt 这类变形能有效绕过基于关键词的正则过滤，且服务端解析不受影响。

实操建议：

准备几组轻量变形 payload：id=1' aNd 1=1--、id=1' UnIoN/*&*/SeLeCt 1,2,3--、id=1' || '1'='1（针对 SQLite/PostgreSQL）
避免使用 CHAR()、CONCAT() 等函数级混淆——它们需要更深入的数据库类型判断，且易被 WAF 的语法树解析拦截
每次发包后检查响应头 X-WAF-Matched-Rule 或 X-Firewall（如有），快速识别当前 WAF 类型，调整后续策略

真正难的不是发几个 payload，而是判断“这个响应变化到底是因为 SQL 注入，还是因为业务逻辑本身对非法输入做了不同处理”。比如 id=abc 返回 400，id=1' 也返回 400，不代表没漏洞——可能 WAF 拦了，也可能后端用了 int(id) 强转，根本没进 SQL。得结合数据库错误回显、堆栈、响应延时、以及至少两种不同注入手法的一致性反馈，才能下结论。