《零基础渗透实录：从SQL注入手工验证到SQLMap自动化脱库（含常见报错解决）》
大家好，我是一个网络安全的初学者。最近在学习OWASP Top 10漏洞时，SQL注入（SQL Injection）是绕不开的第一课。在这篇文章中，我将记录我这几天从最基础的手工检测，到使用SQLMap自动化工具，最后成功“脱库”的全过程。这其中遇到了很多坑，希望能给同样入门的小伙伴一些参考。
1. 第一步：手工注入的“数学题”逻辑
在使用自动化工具之前，师傅让我先用手工的方式来验证漏洞。这一步虽然简单，但让我理解了注入的本质。
我访问的靶场地址是：http://127.0.0.1:8787/user/id?id=1
验证过程：
- 我先输入了id=1 and 1=1，页面正常显示。
- 接着输入id=1 and 1=2，页面报错或数据不显示。
- 原理：这就证明了数据库在听我的“指令”，根据我给的“真”或“假”来决定是否返回数据，漏洞确认存在！
【
】
图片文件名：sql注入,sql注入,1and11=1...1and11=2...
图片说明：手工验证SQL注入的存在。通过and 1=1和and 1=2的对比，确认后端数据库存在逻辑判断漏洞。
在遍历ID的过程中，我发现了一些有趣的细节：
- 当ID=26时，是一个普通的用户。
- 当ID=1时，赫然显示着“admin”管理员账号！这让我意识到，通过注入可以直接定位核心数据。
【
】
图片文件名：sql注入，id=26.png
图片说明：ID=26显示为普通用户信息。
【
】
图片文件名：sql注入id=1.png
图片说明：成功遍历到ID=1，发现管理员账号（admin），确认了关键权限的存在。
【
】
图片文件名：sql注入id=27，不存在
图片说明：当遍历到ID=27时，页面报错unrecognized token。这其实是一个好消息，它证明了ID=27不存在，也侧面印证了后端数据库对输入参数的直接拼接处理。
2. 第二步：图形化工具（GUI）的“启动灾难”
手工太累了，我想偷懒，于是找到了 SQLMap-GUI 图形化工具。满心欢喜地点击 Start，结果却给了我当头一棒。
遇到的坑 1：SSL 连接报错
工具运行后，日志里疯狂报错：
[CRITICAL] can't establish SSL connection
我一脸懵，明明靶场是HTTP的，为什么要搞SSL？
解决过程：
经过排查，我发现是工具默认开启了“强制SSL”选项。因为我的靶场是http://127.0.0.1，并不是HTTPS，所以数据库拒绝了连接。
【
】
图片文件名：第一次使用图像化界面的工具扫不出结果
图片说明：第一次运行SQLMap-GUI时的界面。虽然遇到了SSL报错，但后来通过取消勾选“强制SSL”选项，终于成功识别出后端数据库为 SQLite。
3. 第三步：导出数据的“寻宝游戏”
虽然工具跑通了，显示“Vulnerable: Yes”，但我想要的数据（Data）在哪里？我在工具目录下翻了个底朝天，根本没有output文件夹。我以为工具坏了，甚至想放弃。
遇到的坑 2：找不到 Output 文件夹
后来我才知道，旧版本的 SQLMap 默认会把文件生成在系统用户目录下（C盘深处），而且如果遇到权限问题或者路径识别错误，它甚至可能根本没生成文件。
解决过程：
我不再依赖默认设置，而是写了一个简单的批处理脚本（run.bat），强制指定输出目录：
python sqlmap.py -u "目标URL" --batch --dump-all --output-dir=./my_results
加上--output-dir=./my_results这句话，终于让工具把数据“吐”在了我眼前！
【
】
图片文件名：sqlmap注入结果.png
图片说明：最终成功导出的数据结果！虽然日志中显示部分表（如user_carts）列名枚举失败，但成功导出了sqlite_sequence表，并且看到了vulin_users（漏洞用户表）的影子，证明自动化脱库成功！
4. 结语
回顾这几天的学习，从看不懂的unrecognized token，到令人头秃的SSL connection和No such file，每一个报错都曾让我想放弃。
但正是这些坑，让我明白了：
- 手工验证是理解逻辑的基础。
- 工具只是辅助，理解参数（如 --output-dir）比盲目点击按钮更重要。
如果你也在学习渗透，遇到报错别怕，那只是系统在和你玩“猜谜游戏”而已！