Yakit 抓包配置与 SQL 注入理论基础 day02（上）

Yakit 抓包配置与 SQL 注入理论基础day02（上）

day01 把实验环境搭好了，但只有环境还无法进入实战，或者说没有趁手的“武器”，和对应实战的“武学”，实战效果肯定不尽人意。

本篇就是这两件事：配置 Yakit 的抓包能力，然后是SQL 注入的原理讲解。

在我学习时会明显感觉直接实战对于很多解题思路和专业术语都看不懂，所以本篇将分为上下两篇：上篇全是「配置 + 概念」，下篇才是「真刀真枪地打 DVWA」。

一、为什么我用 Yakit 而不是 Burp Suite

我很喜欢一位前辈说的：“没有最好用的工具，适合你的才是最好的”，而我的选择则是Yakit，不是说bp不好，而是Yakit的生态和社区对我这种新手更为友好。

Burp Suite 的问题：

版本	价格	关键限制
Community（免费）	0	没有漏洞扫描器、Intruder 暴力破解被限速、不能保存项目
Professional	约 $475/年	功能完整

对学习者来说，社区版最难受的是爆破被限速——你测个弱口令要等到天荒地老。

Yakit 的优势：

• 免费，功能不阉割——爆破、扫描、插件都不限制
• 全中文界面，没有术语翻译的门槛
• 集成度高：MITM 抓包、Web Fuzzer、端口扫描、Codec 编解码、插件商店全在一个软件里，不用装一堆
• 国产，下载和更新不用折腾网络
• 底层是 Yak 语言，后面想做自动化可以写脚本扩展

不是说 Burp 不好。 Burp 是行业标杆，很多公司内部也用。但现阶段需要的是「能顺畅练手」，Yakit 在这方面对新手更友好。等以后工作了再学 Burp 也不迟。

二、安装与首次启动

官网下载：yaklang.com（或 yaklang.io）

Windows 下就是一个安装包，一路下一步。装完打开，主界面左侧是功能导航。

几个马上会用到的入口：

入口	作用
手工测试	手动渗透的主战场，MITM 和 Web Fuzzer 都在这里
MITM 交互式劫持	抓包核心功能
Web Fuzzer	改包、重放、爆破
插件商店	别人写好的检测插件，可以直接用

三、配置 MITM 抓包

3.1 为什么抓 HTTPS 需要装证书

HTTPS 是加密的，正常情况下抓到的只是一堆乱码。 Yakit 要看到明文，就必须在中间解密再加密——这就是「中间人」。

流程是这样的：

问题来了：浏览器凭什么相信 Yakit 冒充的证书？

正常情况下不该信——这正是 HTTPS 防中间人的机制。所以要手工把 Yakit 的 CA 证书装进系统的「受信任根证书颁发机构」，等于告诉浏览器：「以后它签的证书也算数。」

装错了位置（比如装到「个人」里）是不生效的，一定注意安装位置哦。

3.2 方式一：免配置启动（推荐先从这个开始）

Yakit 提供了一个偷懒的办法：它自己拉起一个已经信任了证书的浏览器，你什么都不用配。

步骤：

1. 左侧点 手工测试 → MITM交互式劫持

2. 点击 免配置启动
   

3. 代理地址保持默认 http://127.0.0.1:8083，不用改

4. 点 启动免配置Chrome
   

浏览器会自动打开，这时候它发出的所有流量都已经经过 Yakit 了。

验证一下：在打开的浏览器里访问任意 HTTPS 网站，回到 Yakit 看 History，应该能看到完整的明文请求。

想关掉：点界面上的 免配置启动 按钮即可。

这个方式的优势：零配置、不用装证书、不会污染你自己的浏览器。
代价：只能用 Yakit 拉起的那个浏览器实例。

3.3 方式二：用自己的浏览器 + 装 CA 证书

如果你想让 Chrome / Edge 平时也走 Yakit，就得手动配。

第一步：设代理

• Yakit 侧：确认监听端口是 8083（默认）
• 浏览器/系统侧：把 HTTP 代理指到 127.0.0.1:8083

建议用 xxxxxxx-xxxxx 这类代理插件，按需开关，比改系统代理方便。

• 在欧米伽中配置如图所示的yakit代理，配置成功后更改代理为配置的代理即可正常监听。
  第二步：下载证书

两种途径任选：

• Yakit 里点 高级配置 → 证书下载
• 或者设置好代理后，浏览器直接访问 http://download-mitm-cert.yaklang.io

第三步：安装证书（关键）

1. 下载下来一般是 .pem 文件

2. 去掉 .pem 后缀，改成 .crt（或直接双击看系统认不认）
   

3. 双击 → 安装证书 → 存储位置选 「本地计算机」（需要管理员权限）

4. 证书存储必须选「将所有的证书都放入下列存储」→「受信任的根证书颁发机构」
   

5. 会弹安全警告，点「是」

第四步：验证

访问任意 HTTPS 网站，Yakit 的 History 里能看到明文，就成功了。这里我通过百度测试，结果如图所示，看到明文以及url等信息，就说明已经完成配置了

3.4 抓不到包？按这个顺序排查

现象	原因
History 里什么都没有	代理没生效（插件没开 / 系统代理没切）
HTTP 能抓，HTTPS 抓不到	证书没装，或装错位置（十有八九是这个）
浏览器提示「证书不受信任」	同上
只有部分网站抓不到	该站点开了 证书固定（Certificate Pinning），移动端 App 常见
一切正常但浏览器打不开网页	Yakit 的 MITM 没启动

3.5 劫持界面快速导览

点 劫持启动 后进入劫持界面，三个模式要分清：

模式	行为	什么时候用
手动劫持	每个包都暂停，等你改完再放行	学习和调试时用这个
自动放行	全放行，只记录	边浏览边收集流量
被动日志	只显示日志	排查问题

两个常用操作：

• 丢弃请求——这个包不要了
• 提交数据——放行，并记录进 History

History 是你的宝库：所有抓过的包都在里面，可以随时翻出来重放、改包。后面实操时，我们会大量用它。

四、SQL 注入理论基础

配置讲完了，下面是理论部分。这部分看着枯燥，但它是你后面所有注入操作的地基。

4.1 一句话说清什么是 SQL 注入

程序把用户输入的内容，当成 SQL 代码执行了。

正常的程序：用户输入是「数据」。
出问题的程序：用户输入变成了「代码」。

这就是注入类漏洞的共同本质——数据和代码的边界被打破了。

4.2 它是怎么发生的：一个最小例子

假设有个查询用户的 PHP 代码：

$id = $_GET['id'];
$sql = "SELECT * FROM users WHERE id = $id";

正常请求 ?id=1，拼出来的 SQL 是：

SELECT * FROM users WHERE id = 1

一切正常。

但如果我把 id 改成 1 OR 1=1：

SELECT * FROM users WHERE id = 1 OR 1=1

OR 1=1 恒为真，WHERE 条件失效，这条语句会返回整张表的所有用户。

注意发生了什么：我输入的 1 OR 1=1 被原样拼进了 SQL，数据库把它当代码执行了，而不是当数据。

这就是最朴素的 SQL 注入。

4.3 正确的写法长什么样

对比一下参数化查询（也叫预编译）：

$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?");
$stmt->execute([$id]);

区别在于：SQL 语句的结构先被数据库编译定型了，用户输入只能作为「值」填进占位符，永远无法改变语句结构。

所以防御 SQL 注入的根本方法是参数化查询，而不是「过滤单引号」——过滤是治标，参数化才是治本。

这一点很重要：理解了防御，才算真正理解漏洞。

4.4 注入的分类（三个维度）

维度一：按参数类型

类型	例子	判断特征
数字型	?id=1	参数没被引号包裹，直接拼进 SQL
字符型	?name=admin	参数在 SQL 里被 '...' 包裹

区别在于闭合方式：数字型直接拼 and 1=1；字符型要先闭合引号，比如 admin' and '1'='1。

维度二：按提交方式

GET 参数、POST 表单、Cookie、HTTP 请求头——只要进了 SQL，哪儿都能注入。很多人只盯着 URL 参数，漏掉 Cookie 和 Header，实际上这些地方一样危险。

维度三：按回显方式（最重要）

这个维度决定了你用什么手法打：

类型	特征	难度
联合查询注入（UNION）	页面直接显示查询结果	⭐ 最简单
报错注入	页面回显数据库报错信息	⭐⭐
布尔盲注	页面不报错，但真/假两种状态有差异	⭐⭐⭐
时间盲注	页面完全没差异，只能靠响应时间判断	⭐⭐⭐⭐
堆叠注入	能一次执行多条语句（;分隔）	看数据库
带外注入（OOB）	通过 DNS/HTTP 请求把数据带出来	⭐⭐⭐⭐⭐

从简单到难，就是这个顺序。 新手先从联合查询练起，把它吃透再往下走。

4.5 怎么判断一个地方能不能注入

手工测试的经典三步：

第一步：打个单引号，看报不报错

?id=1'

如果页面出现类似 You have an error in your SQL syntax... 的报错，基本可以确定存在注入，而且大概率是字符型。

如果页面正常，也不代表没有——可能是被过滤了，或者被程序吞掉了报错。继续第二步。

第二步：真 / 假条件对比

?id=1 and 1=1      → 页面正常（真）
?id=1 and 1=2      → 页面异常或为空（假）

两次结果不一样，就说明 and 后面的条件被执行了，注入成立。

这是最可靠的判断方法，因为它不依赖报错回显。

第三步：确定列数

用 ORDER BY 一点点试：

?id=1 order by 1    → 正常
?id=1 order by 2    → 正常
?id=1 order by 3    → 正常
?id=1 order by 4    → 报错

第几个报错，说明查询结果有几列。（上面这个例子就是 3 列。）这是 UNION 注入的必备前置。

4.6 注入成功之后，要拿什么

联合查询注入的完整数据获取路径，是从粗到细的：

1. 当前数据库名
2. 库里有哪些表
3. 表里有哪些字段
4. 字段里有什么数据

这四步全靠 MySQL 自带的 information_schema 库——它记录了所有库、表、字段的元信息，相当于数据库的「目录」。

要查什么	查哪张表
有哪些数据库	information_schema.schemata
某库有哪些表	information_schema.tables
某表有哪些字段	information_schema.columns

理解了这条路径，你就理解了联合查询注入的全部套路。下篇我们会把它一步步走完。

4.7 危害

SQL 注入长期霸占 OWASP Top 10，不是没道理的：

• 数据泄露——脱库，用户名密码全拿走
• 越权访问——绕过登录，直接以管理员身份进入
• 数据篡改/删除——UPDATE、DELETE 一样能执行
• 极端情况下 getshell——如果数据库权限够大，可以通过写文件功能往服务器上放木马

这也是为什么它一直是渗透测试里优先级最高的漏洞类型之一。

五、下篇预告

理论讲完了，但光看是不会的。

下篇我们回到 DVWA，把这一篇讲的东西全部实操一遍：

1. 用 Yakit 抓到 DVWA 的登录请求
2. 用「单引号 + and 1=1/1=2」判断注入点
3. ORDER BY 确定列数
4. UNION SELECT 找显示位
5. 走完 库 → 表 → 字段 → 数据 的全流程，把 DVWA 的用户表拖出来

全程手工，不借助任何自动化工具。 因为只有手工打过一遍，你才真正懂它在干什么——那时候再用 sqlmap，你会知道它每一步在做什么，而不是对着屏幕看它自己跑。

下篇见。

参考

• Yakit 官方文档 · 证书安装和免配置启动
• Yakit 官方文档 · 开始劫持
• Yakit 官网下载