丁茂华身边总有人问我：渗透测试入门到底该刷什么？我的答案一直很稳定——先把平台自带的起点序列打穿，其中这台叫 Appointment 的靶机，我非常推荐放在第一个。
它没有反人性的复杂拓扑，也没有需要猜半天的突破口，整个训练目标非常集中：让你亲手在一个真实Web登录页面上复现一次SQL注入认证绕过，并且理解它为什么会发生。对刚接触Web安全、想搞清楚“工具抛开到底还能不能打”的人来说，这台靶机像一道精心设计的开胃菜。这篇文章按我从拿到目标IP到拿到flag的完整过程来写，包括每一步的思考方式、Payload是怎么推出来的、Burp Suite和sqlmap怎么配合验证，以及打完以后从防御视角能带走什么。内容全部基于HTB平台提供的合法授权靶机环境，放心照着练。
1. 为什么 Appointment 值得成为你的第一台靶机
1.1 难度定位：一台只考一个知识点的靶机
先说结论：Appointment 的整体难度非常低，低到几乎不需要“猜”任何东西。它只开放了一个80端口Web服务，页面就是一个登录框，突破口也只有一个——登录参数存在可注入点。这和那些需要内网横向、提权、多重加密的靶机完全不是一个量级。
但这恰恰是它价值最大的地方。新手阶段最容易犯的错误是“信息一多就乱”，而Appointment把变量砍到了只剩一个，逼你专注思考“登录框到底怎么被绕过”。当你把这一条链路走通，后面再遇到复杂的登录认证逻辑，你会有一个非常清晰的基线认知。
有人可能会问：为什么不直接上更难的机器？我的看法是，网络安全学习最忌讳的就是跳跃式前进。如果连最基础的注入语法和判断逻辑都没吃透，就跑去打综合靶机，最后只会变成“跟着别人的攻略敲命令”，打完一点印象都没有。Appointment就是用来建立这个基线的。
1.2 开始之前，你至少需要知道这几件事
不需要你已经是高手，但有三项基础准备建议先做齐。
第一，懂一点HTTP请求的基本构成。至少要知道GET和POST的区别，知道一个请求里有URL、请求头、请求体，知道浏览器开发者工具的Network面板长什么样。因为后面抓包、改参数、看响应，全都围绕HTTP进行。
第二，会操作一款代理抓包工具。社区用得最多的是Burp Suite，免费版就够用。你需要知道怎么配置浏览器代理，怎么在拦截模式下修改请求，怎么用Repeater重放。这些是Web安全测试的基本功，Appointment非常适合用来磨合这套流程。
第三，有一点点数据库常识。不需要你会写复杂的SQL，但至少要知道SQL里有个单引号用于字符串边界，知道基本的SELECT语句大概长什么样，知道注释符号能“屏蔽”掉后面的内容。这些概念我会在后面用代码直接展示。
如果上面这些都还不会，也没关系，边打边补。我建议你打开靶机页面后，先把浏览器的开发者工具开着，把每一步请求都看一遍，这比任何教程都直观。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 信息收集不是走过场：确认入口与初见登录页
2.1 连上靶机后，从端口扫描开始
启动实例后，HTB平台会给出一个目标IP。我的习惯是拿到IP先做一次完整的端口扫描，虽然Appointment已知只开80，但这个习惯必须在入门阶段就养起来——因为后面打任何靶机，第一步永远是“确认服务暴露面”。
nmap 的命令非常简单：
bash复制nmap -sV -T4 目标IP
扫描结果通常是这样：
code复制PORT STATE SERVICE VERSION
80/tcp open http Apache httpd
看到只有一个Apache服务时，我心里基本有数了：这个靶机的攻击面就集中在Web上。接下来要做的事很明确，打开浏览器访问 http://目标IP/，看看这个Web服务到底长什么样。
2.2 初见登录页：看页面不只是看“表面”
访问过去以后，页面会呈现一个干干净净的登录表单：用户名输入框、密码输入框、一个Login按钮，下面还有一个“I forgot password”的链接。看起来非常普通，就像任何一个小型业务系统。
这时候不要急着拿工具乱试，先做两件细活。
第一，看页面源码。在页面上右键查看源代码，注意表单的提交方式。Appointment的登录表单是POST方式，字段名一般是 username 和 password，还可能提交一个类似 submit=Login 的按钮值。这些参数名后面构造注入Payload时都要用到，先记下来。
第二，看URL和目录结构。细心一点的人会发现站点里可能还有 phpinfo.php 之类的辅助页面，这些页面不一定关键，但多看一眼能帮你确认后端技术栈。比如真看到PHP版本和模块信息，就能推测后端大概率是PHP写的，SQL很大概率是MySQL系。虽然不影响打靶，但对判断Payload写法有帮助。
2.3 为什么信息收集阶段不能跳过
许多新手喜欢跳过信息收集，上来就开sqlmap对着IP猛跑，结果跑半天也定位不到注入点。这就像你到一个陌生小区找一户人家，不先看门牌号，而是挨家挨户敲门，效率极低。
正确的思路是把信息收集当成“读地图”。确认开放端口、确认服务类型、确认业务入口、确认表单参数，每一步都在缩小后续要测试的范围。Appointment虽然简单，但如果你能坚持用这个流程来打，收获的就不只是flag，而是一套可以套用到后续所有机器上的方法论。
3. SQL注入认证绕过原理：看懂登录框背后的逻辑
3.1 一句SQL背后的安全隐患
要理解这次攻击为什么能成功，得先把登录功能的代码逻辑还原出来。假设后端大概长这样（Appointment的后端流程和这个高度类似）：
php复制$sql = "SELECT * FROM users WHERE username='" . $_POST['username'] . "' AND password='" . $_POST['password'] . "'";
$result = mysqli_query($conn, $sql);
if (mysqli_num_rows($result) > 0) {
// 登录成功，跳转到仪表盘
} else {
// 登录失败，提示用户名或密码错误
}
问题出在哪里？问题出在 SQL语句中直接拼接了用户输入。数据库解析这条SQL时，它分不清楚哪段是开发者的逻辑、哪段是用户的输入。如果用户输入里含有特殊字符，比如单引号、注释符、逻辑运算符，这些内容就会“参与”到SQL语句的解析中去。
很多教材把SQL注入定义为“把用户输入变成了代码的一部分”，这句话你可能听过很多遍，但真正理解它，最好的方式就是看一次篡改后的SQL长什么样。
3.2 从正常查询到注入语句的演变推演
假设正常用户输入用户名 admin、密码 123456，后端拼接出的SQL是：
sql复制SELECT * FROM users WHERE username='admin' AND password='123456';
数据库拿到这条语句后，会去查用户名等于admin且密码等于123456的记录。查到就过，查不到就拒绝。目前为止一切正常。
现在攻击者把用户名输入成：
code复制' OR 1=1 -- -
密码随意填一个，比如 x。后端拼接出来的SQL就变成了：
sql复制SELECT * FROM users WHERE username='' OR 1=1 -- -' AND password='x';
我来逐步拆解这条SQL的解析过程：
username=''：用户名等于空字符串，这个条件通常是假的；OR 1=1：或者1等于1，这是永真条件。OR表示只要两边任意一边为真，整个条件就为真；-- -：这是MySQL的注释符，它把后面所有内容——也就是' AND password='x'——全部注释掉了，数据库根本不会解析它们。
于是数据库实际执行的语句是：
sql复制SELECT * FROM users WHERE username='' OR 1=1;
由于条件恒为真，这条查询会返回表中所有的记录。后端再用 mysqli_num_rows($result) > 0 判断时，只要表里有一条用户数据，登录就会被判定为成功。认证绕过由此完成。
3.3 为什么注释符 -- - 后面要有那个空格
这是新手最容易翻车的地方。MySQL的注释语法要求 -- 后面必须跟一个空格或控制字符，否则注释不生效。很多人写成 --' 或者 --x，导致后面的单引号没被注释掉，SQL语法报错，注入失败。
-- - 的写法就是在两个减号后加一个空格，再加一个减号。那个空格让注释生效，后面的减号是习惯性补充，确保在任何方言下都不会因为后面直接接字符而出问题。还有一些注入场景喜欢用 #，它在MySQL里同样可以注释到行尾。但跨数据库兼容性最好的还是 -- -。记住这一个就够了。
理解了这个原理，你就明确了为什么前面信息收集阶段要记录参数名，因为Payload最终要拼到参数值里。接下来进入实操环节。
4. 手工Payload与Burp Suite双路验证
4.1 第一步：先在页面上手工试一次
我习惯先用浏览器直接试，不用工具。在用户名输入框填：
code复制' OR 1=1 -- -
密码随便填 test，点击Login。如果一切顺利，页面会跳转到一个新的仪表盘页面，上面直接显示欢迎语和flag。我第一次打到这一步的时候，说实话心里还是很爽的——仅仅一句话，登录认证就形同虚设了。
如果页面没有跳转，先别急着怀疑靶机有问题。检查一下输入框里是不是被浏览器自动补全了奇怪的内容，再确认一下输入法是不是处于中文全角状态导致引号变成了中文引号。这两个问题我都在实际教学和带队过程中见过，每次都是“看起来对但就是无效”，非常恼人。
4.2 第二步：用Burp Suite抓包，理解请求细节
浏览器里试成功以后，建议再用Burp Suite完整走一遍。这一步的意义不只是“换一种方式打”，而是让你看清楚HTTP请求和响应是怎么交互的。
配置好Burp Suite的代理，浏览器流量走127.0.0.1:8080。在登录表单里输入任意账号密码后提交，Burp Suite的拦截面板里会出现一条POST请求。请求的大致结构如下：
http复制POST / HTTP/1.1
Host: 目标IP
Content-Type: application/x-www-form-urlencoded
Content-Length: 28
username=admin&password=test&submit=Login
看到这里，和之前信息收集阶段记录的表单参数对上了。现在右键这条请求，发送到Repeater。
在Repeater里把请求体改成：
http复制username=' OR 1=1 -- -&password=test&submit=Login
点击Send，观察响应。你会看到响应状态是302，Location头指向 /dashboard.php（或类似的业务页面），这说明后端接受了这次“登录”，并把我们重定向到了内部页面。
通过抓包重放，你能看到实际发生了两次请求：第一次是POST提交，服务端返回302；第二次是浏览器跟着Location去访问目标页面。手工注入成功靠的就是这个302跳转。这个分析过程会帮助你以后在其他靶机上判断“认证是否已经被绕过”。
4.3 第三步：用sqlmap自动验证并顺手取数据
手工验证成功后，再用sqlmap跑一遍，主要是为了两件事：验证漏洞类型，及看看能不能把数据库里真实存的账号数据导出来。
sqlmap的使用要点是必须告诉它POST的参数。命令如下：
bash复制sqlmap -u "http://目标IP/" --data="username=admin&password=test&submit=Login" -p username --batch
-p username 是明确指定要测试的注入参数。跑完以后，sqlmap会报告注入类型。在Appointment上通常能检测出布尔盲注或UNION注入，具体类型取决于后端代码的写法。你看报告的时候，重点不是“它注入了”，而是留意它判断的依据——页面在条件真假时呈现了不同的响应，这就是布尔盲注的判定原理。
接下来进一步枚举数据库：
bash复制sqlmap -u "http://目标IP/" --data="username=admin&password=test&submit=Login" -p username --batch --dbs
拿到数据库名之后，再指定当前库去列举表和字段：
bash复制sqlmap -u "http://目标IP/" --data="username=admin&password=test&submit=Login" -p username --batch -D 数据库名 --tables
表里会有一张用户表，比如是 users。把这张表dump出来，能看到管理员账号和密码的哈希：
bash复制sqlmap -u "http://目标IP/" --data="username=admin&password=test&submit=Login" -p username --batch -D 数据库名 -T users --dump
到这里，你不仅拿到了登录页面的flag，还顺带“看到了”后台存储的全部用户凭据。对新手来说，这个数据结果会带来一个很直观的认知冲击：原来数据泄露可以离得这么近。
4.4 手工与工具的关系：为什么两者都要会
这里必须说一句：工具能帮你省时间，但不能替你思考。
sqlmap很强大，但如果你不理解它背后判断注入的原理，不理解为什么 username 参数被选中作为注入点，不理解布尔盲注的判定逻辑，你就很难在它失效的时候自己找出问题。反过来，如果你只会手工注入了，却又会在大目标、多参数的环境下效率低下。Appointment就是测试“工具+手工”配合流程的绝佳练兵场。
我在实际带新人时常说：先用眼睛看懂流量，再用工具放大效率。这句话放在任何Web安全学习阶段都适用。
5. 从攻击视角切回防御视角：登录页安全设计清单
5.1 第一要务：参数化查询，让SQL和数据分开
看完攻击全过程，下一个必须思考的问题是：如果我是这个站点的开发者，该怎么修？
最优先级、最彻底的修复方案是使用参数化查询（Prepared Statement）。它的核心思想是：SQL语句的结构和用户数据在编译阶段就完全分离。无论用户在参数里填什么，数据库都只会把它当作一个纯字符串值，而不是SQL代码的一部分。
以PHP的MySQLi为例，正确的写法是这样：
php复制$stmt = $conn->prepare("SELECT * FROM users WHERE username=? AND password=?");
$stmt->bind_param("ss", $username, $password);
$stmt->execute();
注意 ? 占位符替代了原本直接拼接变量的位置。这样即使输入是 ' OR 1=1 -- -，它也只会被当成一个普通的用户名“字符串”去比对，永远无法改变SQL语句的结构。这是根除SQL注入最核心的一招。
5.2 第二道防线：输入校验与最小权限原则
参数化查询解决的是“代码层”的问题，但在安全设计里，我们提倡做深防御，也就是再多加几道防线。
输入侧可以加白名单校验。比如用户名只允许字母和数字，长度限制在一二十个字符以内，通过正则表达式提前拦截掉引号、括号、横线等特殊字符。需要注意，这种校验只能作为辅助，不能作为唯一防御——因为现实业务千奇百怪，有些合法输入本身就包含特殊字符，没有参数化查询兜底，单靠过滤迟早会有漏网之鱼。
数据库账号权限也要做最小化。Web应用访问数据库时，如果用的是最高权限账号，那注入一旦得手，攻击者就能拖走所有库的数据。正确的做法是给应用单独创建一个只拥有当前业务库增删改查权限的账号，别给它FILE权限，别给它跨库访问权限。Appointment这个场景里，攻击者能dump出整个表，本质上就是权限过大的结果。
5.3 登录页的其他隐性问题：报错信息与响应差异
登录页除了SQL注入，还有两类常见问题值得你顺带意识到，这个靶机上虽然没有重点考察，但以后在任何登录场景里都可能遇到。
第一类是错误信息泄漏。登录失败时如果页面提示“用户名不存在”，攻击者就可以用它做账号枚举。更糟的是如果后端把数据库报错直接显示到页面上，等于帮攻击者做注入测试。生产环境里错误信息应当统一模糊成“用户名或密码错误”，系统日志只记录在服务端。
第二类是响应差异。哪怕提示语句完全一样，只要“登录成功”和“登录失败”两个场景的响应体长度、响应状态码、跳转位置存在可观测的差异，攻击者就能据此做盲注判断。这也解释了sqlmap为什么能靠“看页面响应是否不同”来提取数据。作为开发者，除了修好漏洞本身，还要尽量避免在接口行为上留下这种可被探测的差异。
6. 复盘笔记：新手高频踩坑与我的下一步建议
6.1 我在这个靶机上见过的几次翻车
Appointment虽然简单，但每次看到新人卡住，卡点几乎都集中在几个非常琐碎的地方，这里统一写出来，大家能少走点弯路。
第一，单引号和空格问题。前面说过，-- - 中间那个空格至关重要。新人在网页输入框里填Payload时，经常被输入法自动纠正成全角字符，单引号不是ASCII的 '，SQL解析当然不会认。排查这类问题的最快方式，就是在Burp Suite里直接看请求包的原始内容。
第二，对POST数据的忽略。有些同学习惯用sqlmap只加 -u URL就开跑，结果跑不出注入点，原因就是登录参数在请求体里，不在URL里。必须用 --data 把POST参数给全。
第三，拿到flag就立刻撤退。打完就关靶机，也不回看漏洞产生的原因，也不看自己的扫描结果，这等于只做了“复制粘贴”而不是学习。我建议至少做到能在纸上把攻击链路完整画出来。
6.2 Appointment之后，下一步练什么
如果你已经能独立完成上面的流程，说明你对Web登录场景下的SQL注入已经有感觉了。接下来的学习路径我会建议从两个方向扩展。
第一个方向是继续加深对SQL注入本身的理解。你可以去平台的其他Web类靶机上练习UNION注入、布尔盲注、时间盲注、堆叠注入。原因很简单：同一个漏洞类型在不同代码逻辑下会有完全不同的利用姿势，早见早熟。
第二个方向是扩展新的攻击面。登录页不只是SQL注入的舞台，还可能出现暴力破解、弱口令、认证逻辑缺陷、验证码绕过等问题。建议接着练习XSS和文件上传这两类Web安全基础，它们和登录认证一起构成了Web安全入门最核心的几块拼图。
6.3 最后一个心得
我在带新人时最常说的一句话是：靶机不是用来“通关”的，而是用来“建立手感”的。Appointment这个靶机，看起来只是一个简单的登录绕过，但它串联起了信息收集、请求分析、注入原理、工具验证、防御设计这一整条链路。你在刷其他靶机时遇到的每一个登录页面，都会记得先想一想：这个参数如果拼进SQL会怎么样？
把这一台机器吃透，你就已经跑赢了大多数只在理论里打转的入门者。接下来，选下一台靶机，继续。